{23} Trac comments (3729 matches)

Results (2301 - 2400 of 3729)

← 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 →
Ticket Posixtime Author Newvalue
#838 1291721955000000 memespring Show welcome message: http://ckan.org/ticket/850
#838 1291729819000000 memespring Prompt users to enter missing info - http://ckan.org/ticket/863
#838 1291736461000000 memespring Search results changes: http://ckan.org/ticket/864
#838 1291812318000000 memespring Add download formats to search results (http://ckan.org/ticket/866)
#838 1295259773000000 rgrp I'm going to close this ticket as almost everything done and remaining ticket can be done on its own.
#836 1291851041000000 rgrp Fixed in cset:2f6d54341b47 and branch feature-286-siteurl
#836 1302882808000000 dread This has been a (minor) issue since release v1.3
#835 1291644820000000 pudo done in cset:d41b77099954
#834 1291633657000000 rgrp Alexander: Documentation is here: http://packages.python.org/ckan/api/version2.html#search-api Those queries should work but I do suggest you use the stable version of CKAN which is v1.2 and we suggest you use that. If you still have problems please reopen.
#833 1295263447000000 rgrp Have repo https://bitbucket.org/okfn/ckanext-admin
#833 1298889104000000 rgrp In progress now (sysadmin view and update nearly done).
#833 1302276855000000 rgrp Authz subsystem complete.
#833 1303236364000000 rgrp Two main tickets done so closing.
#832 1296334980000000 rgrp Done (~4w ago). See https://bitbucket.org/okfn/ckanext-stats and remove from core cset:311313e4afdb.
#831 1290760864000000 rgrp Done over the last week (finally fixed weird trac no __dict__ bug today and enabled user accounts on wednesday).
#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.
#829 1290697386000000 dread Some work towards this in cset:066b1b553595. No exceptions and test skip in place. Looks like formalchemy changed its interface.
#829 1303118864000000 thejimmyg Is this still relevant?
#829 1303122056000000 dread Rufus originally specified it. Reassigning to him to decide whether we still want it or not.
#829 1303838115000000 rgrp This is a wontfix for the present.
#828 1290696586000000 rgrp Closed in cset:66a3efe16ed4
#827 1290766239000000 rgrp Fixed in cset:63a0c0223da4
#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.
#826 1297415095000000 pudo I want to strongly support david in his call for fully flexible extras: one of my use cases for them is to store the various bits of fallout from an archiving process, such as: * last-status * last-crawled * last-etag * last-expires * last-md5 * failure-count * fall-back-url These are things needed to really archive the data well, but they have nothing to do with CKAN core ops. Essentially, the archiver is a seperate concern and it need not appear in the CKAN config.
#826 1297416879000000 kindly There is nothing to stop anyone from putting any extra attributes in the extra_info field dict. So any have the flexibility you need. The config option is to add some fields that act in exactly the same way as python attributes, having the same semantics as them. i.e if you have an extra field called alturl, you can do obj.alturl = 'fdsffs'. This is the best of both worlds as far as I can tell.
#826 1297417900000000 kindly I forgot to mention that he main advantage of the fixed fields, is that we can make them properly searchable i.e the values searchable. This currently does not work for package extra values as they are jsons. I have added this searchability for the sql backend.
#826 1297421022000000 dread Ah - I understand. I'd like it if you could make all the extra fields work as attributes and be searchable - is that possible?
#826 1297423342000000 kindly This would be too much of a hack. You do not want users overwriting any attributes on the object. If they called the attribute "__init__" it would write over the actual __init__.
#826 1297429910000000 dread Merged into default in cset:613d7bd5fc96. Future tickets in this area include: * #978 Full edit in Web UI * #979 Edit Resource extras in the API
#826 1306766057000000 dread This went into ckan release 1.3.2.
#825 1290624449000000 dread Added plenty of info in cset:627249a1c102
#824 1290595559000000 dread <[email protected]> Done on metastable for 1.2 release.
#823 1290506116000000 anonymous Fixed in cset:3845a501ed5f
#822 1290506354000000 dread Fixed in cset:045cab10aa1d Thanks for the patch!
#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.
#820 1311325226000000 dread This has been fixed
#819 1323171435000000 thejimmyg This issue is fixed. Further improvements to the UX of the autocomplete will be dealt with in other tickets.
#818 1305559442000000 dread 1.4 complete
#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.
#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
#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!
#814 1294411109000000 thejimmyg This is now done. It's the "About" link in the main application. Thanks!
#813 1294411047000000 thejimmyg This is now done. The text reads "Add a Package" in the main navigation. Thanks!
#812 1294658293000000 dread Just added stuff from duplicate #781
#811 1294415158000000 thejimmyg See also related extras field tickets #811 and #893
#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.
#809 1297075561000000 thejimmyg This is something to think about more in the future.
#808 1297783658000000 pudo implemented in cset:8200247e74e9
#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).
#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
#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
#804 1294233156000000 thejimmyg This is the document I drafted after discussions with each party which was approved by JF.
#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.
#802 1294233294000000 thejimmyg Merging with #801
#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.
#800 1289483682000000 johnbywater Referencing ticket #799 has changed sprint.
#800 1294245610000000 thejimmyg Discussion for this ticket is now at #728
#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.
#798 1289815658000000 johnbywater Moved from sprint 1.3.3
#798 1294916973000000 dread This was done a while ago.
#797 1289402982000000 rgrp Fixed yesterday night in cset:5b522c762e71
#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).
#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,
#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.
#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.
#791 1294409723000000 thejimmyg Duplicate of #736
#790 1289815658000000 johnbywater Moved from sprint 1.3.3
#790 1294409709000000 thejimmyg Duplicate of #736.
#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.
#788 1289815658000000 johnbywater Referencing ticket #786 has changed sprint.
#788 1294410007000000 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.
#786 1289815658000000 johnbywater Moved from sprint 1.3.3
#786 1294410004000000 thejimmyg Duplicate of #884.
← 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 →
Note: See TracReports for help on using and creating reports.