{23} Trac comments (3729 matches)

Results (1301 - 1400 of 3729)

← 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 →
Ticket Posixtime Author Newvalue
#773 1294413400000000 thejimmyg Merging with #770
#774 1288190596000000 johnbywater Referencing ticket #770 has changed sprint.
#774 1288190682000000 johnbywater Referencing ticket #772 has changed sprint.
#774 1288190711000000 johnbywater Referencing ticket #772 has changed sprint.
#774 1289209650000000 johnbywater Referencing ticket #772 has changed sprint.
#774 1289815658000000 johnbywater Referencing ticket #772 has changed sprint.
#774 1294413412000000 thejimmyg Merging with #770
#775 1295260144000000 pudo fixed in cset:98c9997e80e8
#776 1297066840000000 rgrp Moved to https://bitbucket.org/okfn/vdm/issue/3/avoid-generating-vdm-warnings
#777 1289209649000000 johnbywater Referencing ticket #764 has changed sprint.
#777 1289815658000000 johnbywater Referencing ticket #764 has changed sprint.
#777 1292586843000000 dread James did this a while ago.
#778 1289209652000000 johnbywater Moved from sprint 1.3.2
#778 1289815658000000 johnbywater Moved from sprint 1.3.3
#778 1294416567000000 thejimmyg This is now done.
#779 1289209652000000 johnbywater Moved from sprint 1.3.2
#779 1289815658000000 johnbywater Moved from sprint 1.3.3
#779 1294416581000000 thejimmyg This is now done.
#780 1289209653000000 johnbywater Moved from sprint 1.3.2
#780 1289815658000000 johnbywater Moved from sprint 1.3.3
#780 1294416608000000 thejimmyg This is now done.
#781 1289209653000000 johnbywater Moved from sprint 1.3.2
#781 1289815658000000 johnbywater Moved from sprint 1.3.3
#781 1294415081000000 thejimmyg This is a duplicate of #812 so closing.
#782 1289218497000000 pudo This has existed for quite a while, but misses documentation. Has been documented in cset:db18a16a5b4d
#783 1294409399000000 thejimmyg Exact duplicate of #738.
#784 1289815658000000 johnbywater Moved from sprint 1.3.3
#784 1294410089000000 thejimmyg In order to have end to end testing for UKLII we need to: * Review document from PP with the different things we need to test * Set up a GeoNetwork instance with sample documents to be tested We may also want to test ArcGIS, see #767
#784 1304936251000000 thejimmyg The UKLP test manager is looking at a new test proposal, we have had approval to go live without this, we can re-open later if necessary.
#786 1289815658000000 johnbywater Moved from sprint 1.3.3
#786 1294410004000000 thejimmyg Duplicate of #884.
#787 1289295207000000 pudo Alternative: * The Drupal system will expose a resource at data.gov.uk/profile which wil contain the reqesting user's nickname, fullname, email etc. in JSON (or XML) form. * The Drupal system will also run an OAuth server (and provide /request_token, /access_token, /authorize). * CKAN's login form will be rewired to initiate a client OAuth request on the /profile resource. * Recognizing CKAN's callback URL at catalogue.data.gov.uk, Drupal will automatically grant the request if a user is signed in. * Upon return, a user is created, optionally using the OAuth access token as the users API key, thus making it known both to Drupal and CKAN. * The authorizer will be extended to check access to the /profile resource for OAuth accounts (slow but safe). Advantages: * Well-known protocol, does not depend on cookies (which are strange and never behave as defined, or even the same in multiple browsers) * Python code is available: http://oauth.googlecode.com/svn/code/python/oauth/example * Drupal seems to have very complete support: http://drupal.org/node/296205 * Can be fully implemented as a plugin, using an OAuthClientController for callback and adding hooks to the Authorizer (perhaps need to reconfigure who.ini)
#787 1289815658000000 johnbywater Moved from sprint 1.3.3
#787 1303118054000000 thejimmyg The AuthAPI now exists as an IMiddleware plugin, we really need the permission system moved into CKAN before it is useful though and this depends on a refactor of the Auth system. See #1094
#787 1315821118000000 thejimmyg The joint authentication was implemented a long time ago and is deployed on catalogue.data.gov.uk. We'll build the authorisation layer in ticket #1326 so marking this as fixed.
#788 1289815658000000 johnbywater Referencing ticket #786 has changed sprint.
#788 1294410007000000 thejimmyg Duplicate of #884.
#789 1294248289000000 thejimmyg Will, this means that we just get given a URL to harvest from and we need to determine whether it is a CSW or a WAF. Can you look at this please? The code may already do it, I'm not sure.
#789 1296593257000000 thejimmyg Covered by #736 now.
#790 1289815658000000 johnbywater Moved from sprint 1.3.3
#790 1294409709000000 thejimmyg Duplicate of #736.
#791 1294409723000000 thejimmyg Duplicate of #736
#793 1289815658000000 johnbywater Moved from sprint 1.3.3
#793 1294409836000000 thejimmyg Anyone else know what this means? I can't find changeset aa9aa32e00a9 in the repository so marking as invalid.
#794 1289815658000000 johnbywater Moved from sprint 1.3.3
#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,
#796 1291640040000000 rgrp We no longer have an alpha page due to refactor of search and usage of search for list view (see ticket:847 and subtickets).
#797 1289402982000000 rgrp Fixed yesterday night in cset:5b522c762e71
#798 1289815658000000 johnbywater Moved from sprint 1.3.3
#798 1294916973000000 dread This was done a while ago.
#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 1289483682000000 johnbywater Referencing ticket #799 has changed sprint.
#800 1294245610000000 thejimmyg Discussion for this ticket is now at #728
#801 1289483616000000 johnbywater Referencing ticket #728 has changed sprint.
#801 1289483682000000 johnbywater Referencing ticket #799 has changed sprint.
#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
#803 1289489024000000 dread I'm not sure a template is needed for the test script - surely repeated stuff can just be factored out? Creating the model dump file: * 'hg up' to ckan as it was at the last model migration * 'paster db clean', 'paster db init', 'paster create-test-data' * 'pgdump' * 'hg up default' * Check in the dumped file Do we really want a script to mess with our repo like this? Isn't it just safer to do manually with good instructions?
#803 1314031451000000 dread We now use nose to test migrations instead.
#804 1294233156000000 thejimmyg This is the document I drafted after discussions with each party which was approved by JF.
#805 1298379084000000 dread Migration tests added to buildbot using kindly's new nose option #965. Also removed legacy system of migration testing in: ckan/migration/tests and updated docs. cset:643673c7db3e
#806 1290071159000000 dread This is done now I think? Please list changesets, time taken vs estimate and close ticket.
#806 1291128886000000 rgrp Duplicate of ticket:827
#806 1291134978000000 dread This is not a duplicate of #827
#806 1294916284000000 dread This looks finished
#806 1324034356000000 dread This was introduced in CKAN 1.3
#807 1297075372000000 rgrp wontfix as with traffic we have this is not a massive issue and these are very minor items (we can reopen later if this comes up again).
#808 1297783658000000 pudo implemented in cset:8200247e74e9
#809 1297075561000000 thejimmyg This is something to think about more in the future.
#810 1297679091000000 pudo At the moment, this crashes the groups field for some mysterious reason. Since this is going to be redundant with the new forms and the ticket has a low priority, I'm bumping this back 2 weeks.
#810 1300093797000000 rgrp Moving back to backlog for v1.4 as should be dependent on forms overhaul and seems to be problematic (and not that urgent).
#810 1310128477000000 thejimmyg This ticket is over 6 months old so closing.
#811 1294415158000000 thejimmyg See also related extras field tickets #811 and #893
#812 1294658293000000 dread Just added stuff from duplicate #781
#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/
#816 1312192499000000 rgrp What about idea of 'model' refactor for resource, specifically to have: * format: human created format string with possible nesting e.g. zip:csv * kind: file | api | example | service * mimetype: standard mimetype (e.g. for zipped csv would be application/zip) * mimetype-inner: mimetype of innermost object (so for example would be text/csv) See http://lists.okfn.org/pipermail/ckan-discuss/2011-April/001139.html
#816 1312212782000000 dread I like rgrp's idea to change the model. But since it's complicated it would be good to have a UI. e.g. You might make format field simply a drop-down with only some common options: 'CSV, Excel, Zip, Other'. If you go for Other, then a more substantial UI appears, to cover more filetypes, APIs, services and a text box for Other. And if you select 'Zip' then another set of options appears to say what is in the zip. etc.etc. Another approach would be to have a background process downloading the data file and filling this in for you.
#816 1312295371000000 johnglover I have implemented the resource autocomplete so am closing this for now. I agree that more information on the resource would be a good addition. It seems a bit of a different issue to just adding autocomplete though, with potentially far more changes to the codebase, so maybe it would be better discussed in a separate ticket/CREP. However, any new fields would presumably want to either be constrained or have an autocomplete and so can reuse the work done on this feature. Cheers, John
#816 1319804698000000 dread John did this in cset:1697dfa2552c for release 1.5
#816 1319812324000000 dread And branch feature-816-format-autocomplete
#817 1289997628000000 cygri I'm not allowed to create attachments for some reason. Here's the screenshot: [[Image(http://richard.cyganiak.de/2010/ckan/ckan-resources-table-proposal.png)]] http://richard.cyganiak.de/2010/ckan/ckan-resources-table-proposal.png
#817 1297073724000000 thejimmyg This appears to be fixed now.
#818 1305559442000000 dread 1.4 complete
#819 1323171435000000 thejimmyg This issue is fixed. Further improvements to the UX of the autocomplete will be dealt with in other tickets.
#820 1311325226000000 dread This has been fixed
#821 1298486642000000 dread Investigating several of these packages, it works for me (and David Raznick). For example ni_013_migrants_english_language_skills_and_knowledge, one resource is seen created in the diffs, is displayed in CKAN, in the API and in the dumps. Yet looking at the dump from 17/11/10 when this ticket was created, the resource didn't have a URI, which by the current model is a requirement, so it suggests the data was fine underneath, but it had problems displaying this field, and is now fixed.
#822 1290506354000000 dread Fixed in cset:045cab10aa1d Thanks for the patch!
#823 1290506116000000 anonymous Fixed in cset:3845a501ed5f
#824 1290595559000000 dread <[email protected]> Done on metastable for 1.2 release.
#825 1290624449000000 dread Added plenty of info in cset:627249a1c102
#826 1297414412000000 dread It's great that the extras are added in-line with other Resource properties (as opposed to package extras which are a dict not off 'package' but off 'package.extras'). However, the resource extra field keys are defined in config option "ckan.extra_resource_fields". This config option should be removed - extras need to be entirely flexible for our purposes. (In the next ticket we should make it possible to add/remove both keys and values from the Web UI or API.) It would also be good to tidy things in this direction: http://wiki.okfn.org/Coding_Standards I've merged from default to the branch enhancment_826_resource_extra_fields ready for you.
← 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 →
Note: See TracReports for help on using and creating reports.