{23} Trac comments (3729 matches)

Results (601 - 700 of 3729)

← 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 →
Ticket Posixtime Author Newvalue
#789 1296593257000000 thejimmyg Covered by #736 now.
#790 1294409709000000 thejimmyg Duplicate of #736.
#791 1294409723000000 thejimmyg Duplicate of #736
#793 1294409836000000 thejimmyg Anyone else know what this means? I can't find changeset aa9aa32e00a9 in the repository so marking as invalid.
#794 1294248216000000 thejimmyg This work is now underway in the underlying DGU implementation.
#794 1297686491000000 thejimmyg Actually, for the timebeing we will match but not do anything with that matched information, until there is a clear use case. Publisher is simply the publisher for which the source was registered. Closing this ticket.
#794 1300877517000000 thejimmyg I think we need to look at this again in relation to scotland.
#795 1296593361000000 thejimmyg This is a duplicate of #794 because if we needed to do this it would be because we need to support harvest sources registered on behalf of publishers by agents,
#799 1294232675000000 thejimmyg How can we tell a WAF document has changed, we simply need to re-harvest it to see surely? Moving the issue to ticket #728 to be dealt with together.
#800 1294245610000000 thejimmyg Discussion for this ticket is now at #728
#801 1294233386000000 thejimmyg Perhaps this should be implemented differently so that each harvest attempt creates its own database entry with a timestamp and a status attached. We'll need to move to this when we move to a queue based system.
#801 1296593735000000 thejimmyg I don't see why we'd really need to do this. Under the current system a job would be created just before the harvesting would be run so the creation date of the job is (give or take a few seconds) the date of the harvesting. If we moved to a queue system this would be done better anyway.
#801 1297686706000000 thejimmyg We do have a requirement for this now. The job model has changed so that it is hidden from the user. We therefore want to know the timestamp the job started and the timestamp it finished. We'll therefore need migrations adding too.
#801 1300196714000000 thejimmyg This will now be solved as part of the larger harvesting refactor. See #921.
#802 1294233294000000 thejimmyg Merging with #801
#804 1294233156000000 thejimmyg This is the document I drafted after discussions with each party which was approved by JF.
#809 1297075561000000 thejimmyg This is something to think about more in the future.
#810 1310128477000000 thejimmyg This ticket is over 6 months old so closing.
#811 1294415158000000 thejimmyg See also related extras field tickets #811 and #893
#813 1294411047000000 thejimmyg This is now done. The text reads "Add a Package" in the main navigation. Thanks!
#814 1294411109000000 thejimmyg This is now done. It's the "About" link in the main application. Thanks!
#815 1294410951000000 thejimmyg This is a duplicate of #234. Please have a look at existing tickets or re-open closed ones rather than adding new ones so that we can keep the old discussions. I've added your point to #234. Thanks!
#816 1311171466000000 thejimmyg John, could you have a look at this one please. We'd need an entry in the logic layer for it and then some autocomplete JavaScript on the format field. Can we standardise on jQueryUI going forward. http://jqueryui.com/demos/autocomplete/
#817 1297073724000000 thejimmyg This appears to be fixed now.
#819 1323171435000000 thejimmyg This issue is fixed. Further improvements to the UX of the autocomplete will be dealt with in other tickets.
#829 1303118864000000 thejimmyg Is this still relevant?
#830 1311180263000000 thejimmyg We can now implement themes via extensions or change them via config options. See https://bitbucket.org/okfn/ckanext-exampletheme/ for an example.
#841 1300364333000000 thejimmyg See #995
#842 1303474131000000 thejimmyg As a user I come to a package: Have a todo count at that top that takes you down to the todo list (which may say nothing todo) At the bottom is a section of the package display titled "ToDo" where I see a list of all toDos for the package most recent at the top If I am logged in see a form for "Add to do" at the top of the todo section and can add one straight away I see a "now resolved" button next to each which goes green when you hover. When clicked the todo fades away. Otherwise I see a button that says "login to add todo" expands out the form The form One of the fields is category -> autocomplete the category (not constrained) Add a description Submit, the todo gets added via AJAX to the list at the top as the most recent todo Model: todo id package_id todo_category_id (required) description (required) date=NOW() resolved=False todo_category id name Prepopulate with: broken-resource-link, no-author, bad-format
#842 1303474228000000 thejimmyg > Otherwise I see a button that says "login to add todo" > > expands out the form > Actually rather than expanding the form, you will go away to the login page and come back to see the expanded form (question: how does this redirect you back to the bottom?)
#855 1311176988000000 thejimmyg This ticket is more than 6 months old so closing it in line with our new ticketing policy. The auth code is in the process of a major refactor anyway.
#856 1311177066000000 thejimmyg This ticket is more than 6 months old so closing it in line with our new ticketing policy. We know that test coverage needs to be improved, particularly in the logic layer.
#857 1311177075000000 thejimmyg This ticket is more than 6 months old so closing it in line with our new ticketing policy. We know that test coverage needs to be improved, particularly in the logic layer.
#859 1311177461000000 thejimmyg This ticket is more than 6 months old so closing it in line with our new ticketing policy. We know that test coverage needs to be improved, particularly in the logic layer.
#861 1311168845000000 thejimmyg This ticket has been open for than 6 months so I'm closing it.
#865 1294414639000000 thejimmyg Isn't this in there now? Can we close? Thanks
#881 1294410574000000 thejimmyg Hello fccoelho, Could you please post the output you get from running pip? Thanks, James
#883 1300196622000000 thejimmyg Now complete.
#884 1294247654000000 thejimmyg Related to ticket #665, reopening so that I can close it once I've got it working with Drupal too.
#884 1296592140000000 thejimmyg OK, I've implemented an API call for this too now and all is merged into default.
#887 1300196600000000 thejimmyg This is done. See https://bitbucket.org/okfn/ckanext-harvest At the moment we are not adding migrations to remove the harvesting tables. We are designing a harvesting refactor and will write migrations once the refactor is complete so that instances that use harvesting get upgraded, and those that don't get their harvesting tables removed. Also, see this #1030 for the moving harvesting out of the REST API.
#888 1307352537000000 thejimmyg I don't think any progress has been made on this for a bit so I'm assigning it to me.
#893 1298293527000000 thejimmyg We don't understand the use case for this requirement. Closing for now until a use case can be demonstrated.
#894 1300196388000000 thejimmyg All test CSWs have been successfully harvested from. CSW harvesting is disabled on that source so we can't harvest from it. I don't think we need a ticket for this now do we?
#896 1300217375000000 thejimmyg Actually, I think this should be implemented instead by considering a different CKAN instance as a potential harvest source and then harvesting from it. By thinking of it this way in the first instance, we effectively get a read-only copy of other data in CKAN but one which will be kept up to date. Marking as duplicate. Discussion can now carry on via #987 Common harvesting framework.
#910 1310128544000000 thejimmyg Not enough information and over 6 months old so closing.
#920 1300217199000000 thejimmyg @David Should we implement this as a change to the way tags work or via a tidy up cron job?
#921 1300197629000000 thejimmyg Seb started this, I completed it and the code is now live. Further refactoring will be done first in #1037 and then in #987.
#922 1310128789000000 thejimmyg See also #358 which I'm closing because it gets merged into this ticket. The reason we were blockd on #358 was to do with issues around authorization.
#925 1323168588000000 thejimmyg This is fixed in CKAN 1.5
#929 1297686088000000 thejimmyg The licenses service was down, it is back up now. We should be able to cope with this situation better though. Renaming the ticket.
#934 1323171047000000 thejimmyg We have other ways of solving this problem now rather than a key value store for plugins. Marking as invalid.
#936 1298283172000000 thejimmyg Hi Wayne, I'm assigning this to you but it isn't a priority yet. We'll put it in a sprint when it is time to do it. Cheers, James
#936 1303117147000000 thejimmyg How is this coming on John?
#939 1323171158000000 thejimmyg This is now implemented, the notification links to the about page. We might want to update that page with better information, but that would be a different ticket.
#941 1297246005000000 thejimmyg This will be implemented in http://bitbucket.org/okfn/ckanext-community by Wayne.
#941 1297689750000000 thejimmyg The system will need some way of plugging in the model. See ticket #989 for progress on this. Other ideas: * The apps will need an image upload * We might like a voting system for apps and ideas, potentially that could be re-used later. Let's discuss the above ideas after the basic functionality is in place.
#941 1301909446000000 thejimmyg See also discussion on #1069 about stub datasets.
#941 1310134339000000 thejimmyg This is now implemented by pudo in publicdata.eu. For the portal case, apps and ideas will come from Drupal so we no longer need this ticket.
#948 1323172859000000 thejimmyg Re-assigning to me temporarily to investigate now that Seb has left.
#954 1300217106000000 thejimmyg I'll look at this for a v3 API with kindly as part of the dictization. It also addresses some potential XSS issues in the API we've discovered.
#954 1300447466000000 thejimmyg What would also be really nice is a `help` key in the response which was always returned unless a query parameter of `?help=False` was sent. The help text could explain what the response meant but more importantly would show examples of other calls you can make with the IDs returned such that the whole API is discoverable without anyone ever needing to read any docs! It also means the API documentation is more likely to be up to date since it will be obvious to developers when it isn't. With help=False, the JSON can have all whitespace stripped too for production use. I also think there should be no distinction between GET and POST so that people can easily link to API calls if they want to.
#954 1303118513000000 thejimmyg David Raznick has implemented JSON errors for the v1 and v2 API, we'll look at this over the next few weeks.
#954 1310134531000000 thejimmyg See also this proposal about "inlining" extras fields #972. David Raznick and I have also agreed that for API 3, each call to the logic layer will return an object (basically a dictionary) rather than using Exceptions. This means the return values from the logic layer can exactly mirror the JSON data strucutres returned via the API. The help values can come from the docstrings of the logic layer functions.
#957 1300216958000000 thejimmyg Let's come back to this later. There are larger UKLP refactors going on. Sorry to mess you around.
#963 1297850773000000 thejimmyg We will also remove all the different pip files as part of this fixing #982 at the same time.
#963 1298284252000000 thejimmyg You can now get CKAN from the repository http://apt-alpha.ckan.org/debian
#972 1300219509000000 thejimmyg I don't really agree with this. In fact I'd rather move further away from auto-magic key value pairs stored in JsonTypes. Can we discuss on Skype please?
#972 1310134129000000 thejimmyg Having thought about this more David Raznick and I have decided to stick with separate extras for the timebeing. Mainly because of internationalisation issues.
#985 1303118298000000 thejimmyg We'd like CKAN to CKAN harvesting this week if possible.
#987 1311177705000000 thejimmyg This has largely been implemented now for publicdata.eu. There is a CREP #1134 outstanding to take the harvesting to the next level so marking this one as duplicate for now.
#990 1311180850000000 thejimmyg This now works.
#995 1300364316000000 thejimmyg Also, update the docs: Documentation article on caching / improving performance. (To complement configuration docs.) * Different sorts of cache - beaker style, etags, package_dict in search results(?) * How each one affects performance * How to turn them on/off and configure them * Is it possible to bypass each of them in the browser or with wget/curl? Therefore closing #841.
#995 1311175353000000 thejimmyg The caching still isn't brilliant but there is less urgent need to refactor it. In the future our caching methodology should be to cache at the logic layer so we don't need to refactor the existing caching at this stage.
#995 1311179009000000 thejimmyg See also previous tickets: * #537 Caching and Performance improvement * #543 Investigate partial page caching and edge-side includes
#996 1300364398000000 thejimmyg This is now fixed, the outcome will be used to inform #995 for the caching.
#1001 1300367555000000 thejimmyg Yes, I think the two should be consolidated, but as was noted elsewhere (I think) we don't want the API to ever be authenticated via a cookie, otherwise we open ourselves to CSRF attacks. Instead we could support the API key as a query parameter as an alternative to via the HTTP header if it is hard to set an HTTP header in JS libraries?
#1002 1311173185000000 thejimmyg I've done this in my branch and it will get merged in.
#1004 1311173560000000 thejimmyg At the moment it says "Create a new group" and clicking it takes you to the login page. We want it to do the same thing but if you aren't logged in the label should say "Log in to create a group".
#1004 1323171375000000 thejimmyg The yellow box on the right is now back and you don't get taken to the login page. We'll write more detailed instructions once the group refactor is done.
#1004 1323174597000000 thejimmyg I don't understand. We just had a team meeting about this, all discussed it and agreed to close it. Yes, you get taken to the login page, but that is the correct behaviour. The problem in the past was that the link was in the yellow box and there was no explanation as to why you had to login. This time you click from the header bar and there is a clear message saying "Unauthorized to create a group" - exactly as a user would expect. Even if the exact text of the ticket description isn't fully implemented in the current release, the UX isn't broken anymore. Yes, it might be even nicer to have a message warning them in advanced but these improvements will be taken forward in the UX work - maybe there is an even better solution than a message? Since you are unhappy about closing it I'm marking it as "Duplicate" of #1521. As agreed earlier with the entire team, we'll take this forward as part of the groups refactor. See #1521 for more information.
#1006 1300372286000000 thejimmyg I'm updating the branching policy now. David has closed stable and closed metastable. Marking as fixed.
#1012 1300217601000000 thejimmyg See also #103 which says: As a user I want to view a package at a given revision: * When I visit /package/read/xyz?rev=yyy I should be shown package at revision yyy * package history page should provide links to these pages Could you please investigate how doable this would be given the current package read.html page. I expect it could be very easy once the revision API is in place because we could build a c.pkg object from the revision data instead of the model data. Perhaps another case where we could try introducing the dictization?
#1012 1300364620000000 thejimmyg The API part is now done. Bumping the view history part to 1.5
#1012 1301909937000000 thejimmyg No-one really seems to have requested this part.
#1020 1300196215000000 thejimmyg This is now on DGU live.
#1029 1301311643000000 thejimmyg This was fixed by kindly as part of the 1.3.2 release.
#1030 1300209975000000 thejimmyg Also: * Delete harvest sources * Implement a Genshi template filter so that if there is an INSPIRE package_extra set to True, you can link to the XML and HTML generation API calls in ckanext-csw * Write tests in ckanext-dgu for all the API calls that Drupal is making
#1032 1303117292000000 thejimmyg Rufus, I think this is potentially quite a big change and needs to be done as part of the entity refactor rather than as a quick hack. I'd like David Raznick to work on timeseries this week so I'd like to understand a bit more about this ticket. Could you flesh it out please or let's discuss in the catch up?
#1032 1303118226000000 thejimmyg See related ticket #922
#1035 1323172908000000 thejimmyg Re-assigning to me temporarily to investigate now that Seb has left. It may be that this should be deleted given that it is over 6 month's old.
#1037 1303117000000000 thejimmyg We spent last week integrating the new harvesting architecture and testing the code but there are still some areas that need looking at * The source type and label should be part of the plugin, not named in DGU. * Need warnings if a document changes but its date doesn't -> do we have these? * I noticed there are some tests in DGU, should these perhaps be in ckanext-harvest? * If active is False, the job should not be put on the queue * Log if the wrong type of URL is entered as an error the user can see * Deny if the source is already registered * Overwrite all extras, not just merge new ones. * During the import stage use iswms.py to add an extra during import if it is a WMS so that we can add a link to the WMS later https://gist.github.com/900878 * Can errors/warnings be logged in the import stage? Do all fetched documents get passed to import in one go?
#1037 1304937601000000 thejimmyg Closing this now, any outstanding small issues will be logged in new tickets.
#1041 1300284809000000 thejimmyg Also, this means moving documentation out of the current CKAN dev wiki at trac.ckan.org and into the community wiki. Core developer docs should remain in the Sphinx-based .rst format in CKAN. Much-needed new tutorials go on the community wiki.
#1041 1310135309000000 thejimmyg Child ticket of #1142
#1049 1323169424000000 thejimmyg This is over 6 months old. In accordance with wiki policy, closing.
#1050 1303118188000000 thejimmyg This should also feed into #1075 which will be being worked on this week.
#1053 1310125444000000 thejimmyg This is now fixed as part of the API refactor and revisioning updates David Raznick has done.
#1062 1311178145000000 thejimmyg Hi John, Can you please check that the new webstore+preview works correctly with this one please? Cheers, James
#1064 1323169787000000 thejimmyg Marking as duplicate because #1464 will take it on.
← 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 →
Note: See TracReports for help on using and creating reports.