{23} Trac comments (3729 matches)

Results (1801 - 1900 of 3729)

← 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 →
Ticket Posixtime Author Newvalue
#1164 1308647224000000 amercader Done. See it in action here: http://publicdata.eu/map
#1191 1308650930000000 dread Done in cset:c3822feffb38 for 1.4.1 release
#1196 1308743857000000 dread Reason here: http://www.freewisdom.org/projects/python-markdown/Tickets/000018 Using the suggested workaround. Fixed on default for 1.4.2 in cset:715212cd220c
#1198 1308821489000000 pudo This ticket is essential I think. I would propose we should be a bit more radical here, though: * Introduce an "Agent" SQLAlchemy object and derive both publishers and users via single table inheritance. * Make agent the central object of authorization, e.g. by introducing c.agencies including the user account, visitor, logged_in, etc. * Abolish AuthorizationGroups in favor of publishers. Yes, they are different but the use case for what AuthzGroups do and Publishers don't is just nerdery. * Restructure URLs to be /<agent>/<package_name> rather than /package/<package_name> and have /<agent> be a useful list of managed resources rather than a revision list (users current home page). * Make Agents a primary facet for all kinds of navigation. Of course this would be done incrementally but I think we should agree on some such scheme as a marching direction.
#1199 1308822557000000 rgrp Not sure we need exposure this via the API (at least at this point) as things like auto mass emailing could be in done in separate component (that talks to CKAN).
#1198 1308824870000000 dread I think it is a good idea to allow both users and publishers to be the object of authorization. The user_object_role table and all logic surrounding it would be simpler. I deliberately didn't suggest any detail on the authz front because I know other related changes are afoot so it would be useful for David Raznick to contribute here. I really like the url ideas - more like github. /<agent> having a list of packages and a search box, plus a link to the latest revisions would be great. /package/<package_name> would usefully redirect to /<agent>/<package_name>. I do think this should be split off into a separate ticket though. What do you think?
#103 1308828847000000 dread Now we have this working in #1141 we can add the links from the package history page suggested here.
#1141 1308828928000000 dread I've merged this into default in preparation for release 1.4.2, but there may be a couple of useful additions that could be done on this or another branch/ticket. Getting a package at a specified revision is really useful. This can be used: * links in the package history (#103) (while in there, the 'moderated' flag should be shown in the package history too if not already) * should also be added to the package API (as a replacement for the AJAX call?) The history_ajax call looks like an almost duplicate of the Package Revision API. Can these be merged and put just in the API?
#1199 1308922389000000 pudo merged to default with password reset forms
#1206 1309450216000000 dread Fixed with cset:149be76faabc on default branch, aiming for ckan 1.4.2. Thanks for help from Eric Lemoine.
#1205 1309768720000000 kindly fixed in default cset:5e2070688e54 The upgrade now works locally, so the upgrade should work now.
#1193 1309768960000000 kindly fixed cset:87d6140e06ad
#1210 1309974781000000 dread Fix in ckan for AssertionError in cset:8f6ba8ef63f3 lined up for CKAN release 1.4.2.
#1214 1309982828000000 dread I'm working through these on branch defect-1214-api-improvements. "Server returns text/html for errors" - now fixed in cset:0a533a8da3df
#1214 1310041083000000 dread Aron, I've fixed the second item (on my branch), so you can DELETE a package without Content-Length. But I'm not sure what you mean here: "Should be 405 Method Not Allowed?" DELETE should be allowed. Or is that a response you're getting? David
#1214 1310041605000000 dread "Tag returned as a JSON object when updating but as a string when requesting." I'm not sure what you mean. http://test.ckan.net/api/2/rest/package/reference-example gives tags: {{{"tags": ["country-uk", "example-package"],}}} Is it this - returning package names, rather than ids? Here is certainly a bug I'll fix. http://test.ckan.net/api/2/rest/tag/country-uk
#1214 1310042268000000 dread Fixed tag entity returning package names for apiv2 - it now gives IDs. The problem mentioned about "Extras" content - I'm not sure what's meant here. Package extras are just strings. You might choose to store a package name in an extra, but there is no magic to convert it to a package id should you retrieve the package via apiv2. Is this just a misunderstanding or have I missed your point?
#1214 1310044531000000 dread Deleting an extra using 'null' works for me: {{{ $ curl -d '{"name":"dtest2", "extras":{"1":"1", "2":"2", "3":"3"}}' http://test.ckan.net/api/rest/package -H "Authorization: tester" ... $ curl -d '{"name":"dtest2", "extras":{"1":"1", "2":"2", "3":null}}' http://test.ckan.net/api/rest/package -H "Authorization: tester" {"maintainer": null, "name": "dtest2", "relationships_as_subject": [], "author": null, "url": null, "relationships_as_object": [], "notes": null, "title": "dtest2", "maintainer_email": null, "revision_timestamp": "2011-07-07T12:57:18.454890", "author_email": null, "state": "active", "version": null, "groups": [], "license_id": null, "revision_id": "f0ff31c0-027b-49ce-9daf-94a73d96a913", "tags": [], "id": "fdeeb287-2783-4aac-9fc7-a6717e54e22f", "resources": [], "extras": [{"state": "active", "value": "\"1\"", "revision_timestamp": "2011-07-07T12:57:18.454890", "package_id": "fdeeb287-2783-4aac-9fc7-a6717e54e22f", "key": "1", "revision_id": "f0ff31c0-027b-49ce-9daf-94a73d96a913", "id": "d1937073-7bfc-48c5-b6ff-b00d90b451ae"}, {"state": "active", "value": "\"2\"", "revision_timestamp": "2011-07-07T12:57:18.454890", "package_id": "fdeeb287-2783-4aac-9fc7-a6717e54e22f", "key": "2", "revision_id": "f0ff31c0-027b-49ce-9daf-94a73d96a913", "id": "8147886f-9769-440c-8c35-b7d6a2f46de7"}]} }}}
#1214 1310045026000000 dread Ok I see the problem with extras. When you create a package you get back 'simple' extras: {{{ $ curl -d '{"name":"dtest3", "extras":{"1":"1"}, "tags":["australia", "barbeque"]}' http://test.ckan.net/api/rest/package -H "Authorization: tester" --trace log {"maintainer": null, "maintainer_email": null, "id": "33d75910-ae5e-45b0-a154-d00022555a43", "metadata_created": "2007-04-10T21:19:38", "relationships": [], "metadata_modified": "2011-07-07T13:06:06.228718", "author": null, "author_email": null, "state": "active", "version": null, "license_id": null, "resources": [], "tags": ["australia", "barbeque"], "groups": [], "name": "dtest3", "license": null, "notes_rendered": "", "url": null, "ckan_url": "http://test.ckan.net/package/dtest3", "notes": null, "title": "dtest3", "ratings_average": null, "extras": {"1": "1"}, "ratings_count": 0, "revision_id": "31cb22d4-3452-4adc-b572-cd173aea7d }}} i.e. "extras": {"1": "1"} and that's what you get if you GET the package: {{{ $ curl http://test.ckan.net/api/rest/package/dtest3 {"maintainer": null, "maintainer_email": null, "id": "33d75910-ae5e-45b0-a154-d00022555a43", "metadata_created": "2007-04-10T21:19:38", "relationships": [], "metadata_modified": "2011-07-07T13:06:06.228718", "author": null, "author_email": null, "state": "active", "version": null, "license_id": null, "resources": [], "tags": ["australia", "barbeque"], "groups": [], "name": "dtest3", "license": null, "notes_rendered": "", "url": null, "ckan_url": "http://test.ckan.net/package/dtest3", "notes": null, "title": "dtest3", "ratings_average": null, "extras": {"1": "1"}, "ratings_count": 0, "revision_id": "31cb22d4-3452-4adc-b572-cd173aea7d11"} }}} but if you then edit it you get them expressed much more verbosely: {{{ $ curl -d '{"name":"dtest3", "extras":{"1":"2"}, "tags":["australia", "barbeque"]}' http://test.ckan.net/api/rest/package/dtest3 -H "Authorization: tester" --trace log {"maintainer": null, "name": "dtest3", "relationships_as_subject": [], "author": null, "url": null, "relationships_as_object": [], "notes": null, "title": "dtest3", "maintainer_email": null, "revision_timestamp": "2011-07-07T13:06:06.228718", "author_email": null, "state": "active", "version": null, "groups": [], "license_id": null, "revision_id": "31cb22d4-3452-4adc-b572-cd173aea7d11", "tags": [{"revision_timestamp": "2011-07-07T13:06:06.228718", "state": "active", "id": "4aa0e776-ac2a-4a8b-82ba-d80237d35596", "name": "australia"}, {"revision_timestamp": "2011-07-07T13:06:06.228718", "state": "active", "id": "e890354d-e170-44c1-94b1-f0d8b38a49fc", "name": "barbeque"}], "id": "33d75910-ae5e-45b0-a154-d00022555a43", "resources": [], "extras": [{"state": "active", "value": "\"2\"", "revision_timestamp": "2011-07-07T13:21:02.220368", "package_id": "33d75910-ae5e-45b0-a154-d00022555a43", "key": "1", "revision_id": "61703821-a2f1-41f8-8f39-71130c5e6c1b", "id": "87d7d4fc-7eb7-4760-b199-e460ce505632"}]} }}} I'm going to ask David Raznick about what's best here. It would be good to make them uniform.
#1214 1310053225000000 aron Replying to [comment:2 dread]: > Aron, > I've fixed the second item (on my branch), so you can DELETE a package without Content-Length. But I'm not sure what you mean here: "Should be 405 Method Not Allowed?" DELETE should be allowed. Or is that a response you're getting? > David If I send a HEAD request to the server eg. {{{ curl -i -XHEAD http://test.ckan.net:80/api/2/rest/package/ec9cb930-d15f-441f-a1e1-36f4d5df19bf }}} I get the following in the Access-Control-Allow-Methods header {{{ Access-Control-Allow-Methods: POST, PUT, GET, OPTIONS }}} I've just realised that the "Access-Control" headers are for cross origin browser requests so I think you can ignore my comments about the correct response being 405 Method Not Allowed but perhaps DELETE should be added to the Access-Control-Allow-Methods list?
#1214 1310054305000000 aron Replying to [comment:3 dread]: > "Tag returned as a JSON object when updating but as a string when requesting." > I'm not sure what you mean. > > http://test.ckan.net/api/2/rest/package/reference-example > gives tags: {{{"tags": ["country-uk", "example-package"],}}} I'm getting back objects for each tag in the response body from a PUT request. For example "country-uk" would be something like. {{{ { "id" : "600dc72e-6127-4704-b801-bee00474ec0c", "name" : "country-uk", "revision_timestamp" : "2011-07-06T09:09:21.578034", "state" : "active" } }}} Hopefully this gist <https://gist.github.com/97447d0b28bf52f3e06b> will illustrate the issue. > Is it this - returning package names, rather than ids? Here is certainly a bug I'll fix. > http://test.ckan.net/api/2/rest/tag/country-uk That was the fifth point on the list.
#1214 1310054863000000 aron Replying to [comment:5 dread]: > Deleting an extra using 'null' works for me: Hmm, it works for me too when there are other keys remaining in the "extras" object. However I can't seem to delete the last one. Take the following example. {{{ curl -i -XPUT -d'{"extras": {"Tester": null}}' -H"X-CKAN-Type: application/json" http://test.ckan.net:80/api/2/rest/package/ec9cb930-d15f-441f-a1e1-36f4d5df19bf }}} Gives: {{{ { "author" : "", "author_email" : "", "extras" : [ { "id" : "88cc50ca-9e29-4499-a542-09d364f5f64f", "key" : "Tester", "package_id" : "ec9cb930-d15f-441f-a1e1-36f4d5df19bf", "revision_id" : "e5c3ca9c-1dae-4a86-837f-b8c19ac31964", "revision_timestamp" : "2011-07-07T16:01:05.696025", "state" : "active", "value" : "\"Test Value\"" } ], "groups" : [ ], "id" : "ec9cb930-d15f-441f-a1e1-36f4d5df19bf", "license_id" : "", "maintainer" : "aron", "maintainer_email" : "", "name" : "my-test-package", "notes" : "Heading\r\n===\r\nThis _is_ some text", "relationships_as_object" : [ ], "relationships_as_subject" : [ ], "resources" : [ ], "revision_id" : "688d33fb-5629-4ab3-9f59-a649fc7caa00", "revision_timestamp" : "2011-07-06T10:37:50.182894", "state" : "active", "tags" : [ { "id" : "600dc72e-6127-4704-b801-bee00474ec0c", "name" : "test-tag", "revision_timestamp" : "2011-07-06T09:09:21.578034", "state" : "active" } ], "title" : "My Test Package", "url" : "", "version" : "" } }}}
#1214 1310055169000000 aron Another edge case that popped up while verifying the above issues. A PUT request without a body throws a 500 Internal Sever Error {{{ curl -i -XPUT -H"X-CKAN-API-KEY: tester" -H"Content-Type: application/json" http://test.ckan.net:80/api/2/rest/package/ec9cb930-d15f-441f-a1e1-36f4d5df19bf }}}
#1214 1310057942000000 aron One more for today. Please do let me know if I should be filing these as separate tickets? For some reason performing a search query for packages with an underscore "_ " as a query string key fails to return any results. {{{ curl "http://test.ckan.net/api/2/search/package?q=osm" }}} Gives me 4 results. {{{ curl "http://test.ckan.net/api/2/search/package?q=osm&_=1310056826904" }}} Gives me none. The underscore is generally used by JavaScript libraries as a way of bypassing the browser cache when making JSONP calls. It's easily worked around but is odd none the less.
#1214 1310062570000000 dread Fixes have gone into the branch for "Tag returned as a JSON object when updating but as a string when requesting. Same with "extras" content." and "Doesn't return rendered_text property on package update.". I've added DELETE to the Access-Control-Allow-Methods on the server, so you can try that now. I've added a failing test for the problem of deleting the last extra. Am discussing with David Raznick how to fix that best. I think the only other ones left to address are: * Relationships use "object" key rather than id or package_id. * underscore in search parameters
#1214 1310062621000000 dread I believe "A PUT request without a body throws a 500 Internal Sever Error" was fixed yesterday in the code. (Not deployed to test.ckan.net yet though)
#1214 1310067327000000 dread Relationships use "object" key rather than id or package_id. I'm not totally clear on this one. The URLs for relationship editing can be package ids or names. When you GET a relationship packages are referred to in IDs for v2 API. When you create or update a relationship it returns package IDs for v2 API. Are you referring to the relationships listed in the response when you PUT a package? (If so that would be fixed by my previous fix.)
#1214 1310067831000000 dread underscore in search parameters I think its trying to filter search results by values of an extra field called "_", even though this probably doesn't occur. If it is not too ugly, I suggest using one of your other ideas for solving the cache issue. I suggest you bring it up with Rufus or the ckan-dev list to get opinions.
#1214 1310072808000000 dread I've put the fixes onto test.ckan.net - repoen the ticket if there are any issues.
#1070 1310117129000000 rgrp Added link to http://wiki.ckan.net/Domain_Model and closing as work mostly done (and nothing clear remaining to be done -- agreement perhaps!)
#1208 1310124599000000 thejimmyg Rufus and Friedrich are working on this at the moment so putting into the current sprint. I'm considering this as preliminary investigation to inform the wider project that David Raznick is leading on.
#728 1310124784000000 thejimmyg Isn't this already completed? Putting in the backlog but I think it is already implemented. Adria, could you please update accordingly?
#1096 1310125173000000 thejimmyg Renaming to CKAN Hosted because whether we introduce a site domain object for subdomain tenants or not is an implementation detail. As far as progress on CKAN hosted goes, we now have: * A build tool to package ckanext-dgu, ckanext-std etc into .deb files * The ability to apt-get install CKAN * A script that can set up multiple non-conflicting CKAN instances on the same machine What we need next is the ability to generate a ckanext-xxx repository for each new instance we want to host. At that point most of the underlying techniques for hosting multiple CKAN instances concurrently will be in place. Once we have that working and know what clients want, we can look at going further and speccing up a multisite solution off a single DB, rather than the multi-instance solution proposed here.
#1053 1310125444000000 thejimmyg This is now fixed as part of the API refactor and revisioning updates David Raznick has done.
#363 1310125872000000 thejimmyg This will eventually be fixed as part of braoder VDM changes. This work cannot be prioritised above other things we want to do.
#961 1310126100000000 shevski The main parts of this ticket are now done. The remaining parts can be dealt with separately as their own tickets.
#559 1310126313000000 shevski I don't understand this one. It is older than 6 months so marking invalid.
#1053 1310126546000000 dread Looks to me like DELETE always changed the state to Deleted, so an invalid ticket. We can deal with purging in another ticket if needed.
#559 1310127694000000 dread Makes sense to me... Works for me too, so leaving closed.
#810 1310128477000000 thejimmyg This ticket is over 6 months old so closing.
#910 1310128544000000 thejimmyg Not enough information and over 6 months old so closing.
#1108 1310128678000000 thejimmyg Now that we are using ckan.net as thedatahub.org we should go full steam ahead and create a brand new UI to reflect thedatahub.org's new role. See http://ckan.org/2011/07/08/ckan-vision-update/
#358 1310128782000000 thejimmyg Merging with #922 go there for latest updates.
#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.
#764 1310133334000000 shevski will be done as part of #1094
#1069 1310133794000000 thejimmyg Yes, and this will be more important in thedatahub.org
#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.
#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.
#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.
#1107 1310134646000000 thejimmyg Child ticket of #954
#1087 1310134714000000 thejimmyg Child ticket of #954
#1168 1310134901000000 thejimmyg This is now working on dgu-buildbot.okfn.org. The code that manages it is partly the repo.py script from http://hg.3aims.com/public/BuildKit/ and partly the fab code in https://bitbucket.org/okfn/buildbot-scripts
#1041 1310135309000000 thejimmyg Child ticket of #1142
#1192 1310135468000000 thejimmyg This is now a child ticket of #1142
#1215 1310335541000000 kindly fixed cset: 8a317eadbb36 If you delete the last row then it just clears it instead of deleting the row.
#1218 1310385419000000 dread This has been done in cset:bd0f83a2e287 for release 1.4.2. Deployed to ckan.net.
#1215 1310385485000000 dread This is now deployed on ckan.net (requires Ctrl-R to reload js).
#1214 1310396399000000 aron The groups property in the package resource is always empty (or is for all packages I have viewed). The following group lists one package. {{{ http://test.ckan.net/api/2/rest/group/0ac963e7-ba29-49bc-83c8-98f8c1991649 }}} But when viewing the package the groups array is empty. {{{ http://test.ckan.net/api/2/rest/package/758c26d4-5949-4347-8b4d-023374146d94 }}}
#1168 1310396585000000 dread This might run manually on the us7, but the buildbot is not running these automatically or any sort of testing, which is what this ticket is about.
#1219 1310471415000000 dread This is a known issue and of low importance.
#1221 1310475683000000 dread Exception details: {{{ Module ckan.controllers.user:194 in request_reset << h.flash_error(_('No such user: %s') % id) try: mailer.send_reset_link(user) h.flash_success(_('Please check your inbox for a reset code.')) redirect('/') >> mailer.send_reset_link(user) Module ckan.lib.mailer:69 in send_reset_link << def send_reset_link(user): user.reset_key = make_key() model.Session.add(user) model.Session.commit() >> user.reset_key = make_key() AttributeError: 'NoneType' object has no attribute 'reset_key' }}}
#1199 1310555589000000 dread This was done in branch feature-1198-mailer. No tests - ticketed here: #1222. Additional feature in this branch 'password reset' was ticket #1186.
#1186 1310556519000000 dread This was done by pudo in branch feature-1198-mailer and went into default, lined up for release 1.4.2.
#1221 1310556607000000 dread Other edge cases and error conditions do not work properly either. Fixed in cset:4737c86d1d81 for release 1.4.2.
#1222 1310556618000000 dread Fixed in cset:4737c86d1d81 for release 1.4.2.
#1176 1310557852000000 dread This is occurring several times a day now - James can you suggest what's happening?
#1128 1310567803000000 dread Loader in ckanext/bin/loadscotland.py. Done upload to ckan.net: {{{ (pyenv-ckanext)dread@dread-laptop:~/hgroot/ckanext$ scotland_loader -k xyz -H http://ckan.net/api /home/dread/ckan-local/data/scotland-2010-10-18.csv /home/dread/hgroot/pyenv-ckanext/lib/python2.6/site-packages/pylons/templating.py:610: UserWarning: Unbuilt egg for setuptools [unknown version] (/usr/lib/python2.6/dist-packages) Engine = entry_point.load() No handlers could be found for logger "vdm" 2011-07-13 15:29:17,983 INFO [ckanext.importlib.loader] Loading scottish_neighbourhood_statistics 2011-07-13 15:29:20,109 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:29:22,089 INFO [ckanext.importlib.loader] Loading traveline_scotland 2011-07-13 15:29:24,579 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:29:27,045 INFO [ckanext.importlib.loader] Loading sqa_qualifications 2011-07-13 15:29:30,869 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:29:32,561 INFO [ckanext.importlib.loader] Loading scotxed 2011-07-13 15:29:34,017 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:29:35,286 INFO [ckanext.importlib.loader] Loading iscjis_vocabularies 2011-07-13 15:29:36,592 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:29:37,782 INFO [ckanext.importlib.loader] Loading ecare_multi-agency_store_data_model_and_vocabulary 2011-07-13 15:29:39,043 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:29:40,267 INFO [ckanext.importlib.loader] Loading digital_archive_scottish_archive_network 2011-07-13 15:29:41,690 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:29:43,727 INFO [ckanext.importlib.loader] Loading the_scottish_register_of_tartans 2011-07-13 15:29:45,159 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:29:46,816 INFO [ckanext.importlib.loader] Loading scotlands_images 2011-07-13 15:29:48,563 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:29:49,983 INFO [ckanext.importlib.loader] Loading national_library_of_scotland 2011-07-13 15:29:51,709 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:29:53,122 INFO [ckanext.importlib.loader] Loading scottish_government_statistics 2011-07-13 15:29:55,857 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:29:57,118 INFO [ckanext.importlib.loader] Loading scotbis 2011-07-13 15:29:58,883 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:00,264 INFO [ckanext.importlib.loader] Loading historic_scotland 2011-07-13 15:30:02,086 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:03,609 INFO [ckanext.importlib.loader] Loading scheduled_monuments_in_scotland 2011-07-13 15:30:05,057 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:06,987 INFO [ckanext.importlib.loader] Loading scotlands_house_prices_service_consumer_information 2011-07-13 15:30:08,687 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:09,932 INFO [ckanext.importlib.loader] Loading air_quality_in_scotland 2011-07-13 15:30:11,278 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:12,637 INFO [ckanext.importlib.loader] Loading river_and_coastal_flooding_updates_for_scotland 2011-07-13 15:30:13,940 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:15,637 INFO [ckanext.importlib.loader] Loading public_contracts_scotland 2011-07-13 15:30:17,280 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:18,666 INFO [ckanext.importlib.loader] Loading scottish_government_consultations 2011-07-13 15:30:20,673 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:22,234 INFO [ckanext.importlib.loader] Loading scottish_public_health_observatory 2011-07-13 15:30:24,025 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:26,297 INFO [ckanext.importlib.loader] Loading scotlands_information_landscape 2011-07-13 15:30:28,308 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:29,758 INFO [ckanext.importlib.loader] Loading isd_scotland 2011-07-13 15:30:31,847 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:33,074 INFO [ckanext.importlib.loader] Loading scotlandspeople 2011-07-13 15:30:34,541 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:35,754 INFO [ckanext.importlib.loader] Loading general_register_office_for_scotland_statistics 2011-07-13 15:30:37,273 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:39,330 INFO [ckanext.importlib.loader] Loading baseline_scotland_-_groundwater_chemistry_data 2011-07-13 15:30:40,716 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:41,919 INFO [ckanext.importlib.loader] Loading the_centre_for_the_study_of_retailing_in_scotland_data_sets 2011-07-13 15:30:43,275 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:44,515 INFO [ckanext.importlib.loader] Loading growing_up_in_scotland 2011-07-13 15:30:46,215 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:47,582 INFO [ckanext.importlib.loader] Loading scottish_parliament_msp_allowances 2011-07-13 15:30:49,580 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:51,272 INFO [ckanext.importlib.loader] Loading scottish_government_ministerial_hospitality 2011-07-13 15:30:53,764 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:55,642 INFO [ckanext.importlib.loader] Loading scottish_government_expenditure_over_25000 2011-07-13 15:30:58,012 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:30:59,674 INFO [ckanext.importlib.loader] Loading scottish_local_government_financial_statistics 2011-07-13 15:31:01,869 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:31:03,382 INFO [ckanext.importlib.loader] Loading scottish_government_disclosure_of_high_earners 2011-07-13 15:31:07,086 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:31:11,493 INFO [ckanext.importlib.loader] Loading scotlands_places 2011-07-13 15:31:14,452 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:31:31,743 INFO [ckanext.importlib.loader] Loading scottish_national_heritage_facts 2011-07-13 15:31:36,223 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:31:37,830 INFO [ckanext.importlib.loader] Loading scottish_natural_spaces 2011-07-13 15:31:40,245 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:31:41,764 INFO [ckanext.importlib.loader] Loading scotland_national_address_gazetteer 2011-07-13 15:31:43,810 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:31:45,069 INFO [ckanext.importlib.loader] Loading scottish_environment_protection_agency 2011-07-13 15:31:47,975 INFO [ckanext.importlib.loader] ...creating package 2011-07-13 15:31:49,525 INFO [ckanext.importlib.loader] Loading traffic_scotland 2011-07-13 15:31:52,396 INFO [ckanext.importlib.loader] ...creating package }}}
#1128 1310568028000000 dread Note, I added a title column and made one or two minor corrections that I spotted - see attached CSV for the result.
#1205 1310568631000000 dread This worked - cheers David.
#1209 1310571715000000 dread Was fixed in cset:d959a70a19ea. Bug was introduced and fixed before a release took place.
#1223 1310573893000000 dread pudo did this in cset:1ab655b7b76a and cset:7a9c6b1060cf ready for release 1.4.2.
#1225 1310642407000000 dread Done in ckanext repo cset:70fb690a0769
#1219 1310670324000000 erilem The issue is due to IE7 (and IE6) not supporting {{{inline-block}}}. [attachment:patch-1219-A0.diff] works around the issue. I'm reopening this ticket in case you want to consider my patch. But note that I won't be offended if you close it as wontfix again. I agree this is pretty minor, and that working around old browsers' limitations isn't always a good idea.
#1219 1310740534000000 dread Patch applied in cset:8c05d27db224 for 1.4.2 release.
#1228 1311086612000000 dread Done in cset:88e47b68e42d for 1.4.3
#1230 1311154142000000 kindly The standard way to add tables in a plugin has converged upon putting the tables in the iconfigurable plugin. This runs at the correct point for when the application runs normally. For testing however there are issues due to the tables potentially being dropped, especially for the sqlite case. The fix is to make sure the iconfigurables are run at the start of each set of tests, hence adding it to the ckan_nose_plugin. This is not pretty, but good enough. cset:8531b9fc1ee2
#861 1311168845000000 thejimmyg This ticket has been open for than 6 months so I'm closing it.
#651 1311169144000000 thejimmyg This has been open for more than 6 months so closing it. It may even have been fixed in John's auth refactor.
#651 1311171097000000 dread Yes, John fixed this. Changing to fixed.
#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/
#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".
#1094 1311173649000000 thejimmyg Merging with #1065 and closing.
#1118 1311174062000000 thejimmyg We haven't ever come across this. Perhaps if you could provide an example we can re-open it. Cheers, James
#1065 1311174208000000 thejimmyg Merging with #1094 so see the discussion there too.
#103 1311175065000000 thejimmyg This is now implemented. Date parsing is fairly rudimentary but you can now do things like this: http://test.ckan.net/package/uk-crc-rural-services-data@2011-06-10
#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.
#103 1311175601000000 dread This isn't finished - see second point in description and comment 4: Now we have this working in #1141 we can add the links from the package history page suggested here.
#96 1311176063000000 thejimmyg This sounds like an issue with setuptools not CKAN. It has been open for more than 6 months and doesn't appear to have been an issue so closing.
#200 1311176118000000 thejimmyg I know this is for datapkg but it is over 6 months old so closing in line with our current ticketing policy.
#312 1311176173000000 thejimmyg This ticket is more than 6 months old so closing in line with our current ticketing policy.
#318 1311176497000000 thejimmyg Assigning to John so that he can see whether the QA code correctly flags these kinds of problems. If it does, we can close this ticket because although the API will serve invalid URLs, the publishers will be notified to clean up.
#362 1311176564000000 thejimmyg This ticket is more than 6 months old so marking as invalid in line with out ticketing policy.
#668 1311176649000000 thejimmyg This ticket is more than 6 months old so marking as invalid in line with our ticketing policy. The API v1 and 2 were completely re-written as part of the logic layer refactor so it is likely this issue is resolved anyway.
#460 1311176868000000 thejimmyg This is most likely fixed in the new logic layer refactor but is more than 6 months old anyway so closing in line with our new ticketing policy.
#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.
#355 1311177552000000 thejimmyg Our policy is to recommend the use of hyphens, but not to enforce it. The new package name suggestion autocomplete JavaScript uses hyphens.
← 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 →
Note: See TracReports for help on using and creating reports.