{23} Trac comments (3729 matches)
Results (801 - 900 of 3729)
| Ticket | Posixtime | Author | Newvalue | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| #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? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1141 | 1318862183000000 | dread | What's the status of this now? The ckanext-moderatededits README still says you need a branch of ckan. Can you say which version of CKAN is required instead? I say we close this if ajax call is now in a better place in the API. (I expect it is now, with the logic layer). | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1141 | 1325352507000000 | dread | Closing, with remaining tidy up work for newer CKAN versions split off into new ticket: #1604 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1143 | 1307024681000000 | dread | All done in ckanext-stats cset:bc54790cacd4 (apart from "fix x axis to start at first revision" which was not a problem after all) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1154 | 1314177477000000 | dread | Looking at the changeset, it now does a connection check at start-up of CKAN. If it fails then CKAN runs but doesn't show any packages, apart from via the Tags interface, and the search page and widget on the front-page are removed. (BTW Is this a useful thing to do? Without search, perhaps CKAN should simply not start?) I believe the problem pudo is referring to is temporary periods when the SOLR server is slow/overloaded/down. During this time pudo and I get exception emails saying connection failed for request. e.g. {{{ Module ckan.controllers.home:29 in index << query = query_for(model.Package) query.run(query='*:*', facet_by=g.facets, limit=0, offset=0, username=c.user) c.facets = query.facets c.fields = [] >> limit=0, offset=0, username=c.user) Module ckan.lib.search.common:115 in run << self.query = QueryParser(query, terms, fields) self.query.validate() self._run() self._format_results() return {'results': self.results, 'count': self.count} >> self._run() Module ckanext.solr.backend:63 in _run << # this wrapping will be caught further up in the WUI. log.exception(e) raise SearchError(e) finally: conn.close() >> raise SearchError(e) SearchError: [Errno 111] Connection refused }}} (recently from nl.ckan.net) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1154 | 1314179290000000 | dread | Search requests - option one seems like a bad user experience, and option three seems too complicated. I should do option 2, explain it may well be a temporary problem, and let the user press reload, as per any normal web request. A more difficult problem though is what to do about a failed search indexing. Because of the try/except catch we've had until the patch yesterday, we get no exception emails for this, but I'm worried that this has caused packages to not be indexed, and hence are essentially lost in CKAN (unless someone realises there is a problem and does a reindex at some point). BTW I added paster command 'search-index check' for looking at this problem, but I don't think it was ever added to solr. Is it easy to add get_all_entity_ids for the purpose of checking for this problem? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1154 | 1314192324000000 | dread | Yes, forcing a retry may be possible, although I guess on these occasions you'd be looking at rolling back the creation of the package object too, which is not really in the spirit of the notifications system at present. This is why we had the queue for solr for occasions like this - is it here no longer? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1154 | 1314195684000000 | dread | Ok, I chatted to David about this and we feel it should go like this: notification to search indexer fails and raises an exception, this gets passed through the notification system back up to the code that creates the package, and you do a roll back. Does this tally with what you mentioned in the last comment or is what's there better? Thanks for the info on the queue and ckanext-solr. It sounds like this isn't deployed successfully anywhere (or does pudo know if it is?). In this case we should be clear that it is not what it says it is: "This extension adds support for package search using Apache Solr to CKAN" and maybe simply mark it as deprecated. Pudo what do you think? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1167 | 1307358318000000 | dread | debconf seems the preferred way to question the user post-install and run setup scripts. It seems a bit of a faff. The person that is able to spin up an EC2 instance is no doubt technically able enough to follow a couple of instructions in README.txt saying edit /etc/ckan/<instancename>/<instancename>.ini and add your Google Analytics credentials. So I don't think this ticket is the driver for a debconf setup. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #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. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1169 | 1306754833000000 | dread | Done on default. Will appear on ckan.net next time it is branched and updated. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1170 | 1306864422000000 | dread | Done in cset:4d2d0857281f on default | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1172 | 1312991332000000 | dread | I've started this on branch defect-1172-exceptions | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1172 | 1314118281000000 | dread | Is in cset:47225f03e2af and merged to default for 1.4.4. It now barfs instead of failing silently: * if the ckan config file has any errors * search indexing error There are some other "except Exception" statements | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1172 | 1314118883000000 | dread | I took out "raise" by mistake in ckan/lib/search/worker.py:26 but John has added it in in the corresponding place in ckan/lib/search/__init__.py on branch feature-1275-solr-search anyway. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1175 | 1307350866000000 | dread | Flavio, can you post here the exception that you get? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1175 | 1314030683000000 | dread | Hi Flavio, is this still a concern? I'd like to close this ticket unless you can provide details of the error from your logs or exception email. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1175 | 1325355170000000 | dread | This error (which will be in the apache or ckan log) must be unrelated. Stats extension runs fine elsewhere. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1176 | 1310557852000000 | dread | This is occurring several times a day now - James can you suggest what's happening? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1176 | 1314273012000000 | dread | This occurs when you browse {{{/error/document}}} directly, rather than being directed there on error. In this case there is no 'original_response'. Fixed in cset:c67d5934fb0b for ckan 1.4.3 and merged to default. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1177 | 1307374897000000 | dread | I think rgrp was suggesting you have mistakenly set has_commenting to "True" in app_globals or elsewhere. But either way, this should have no side-effects. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1180 | 1307544223000000 | dread | Both issues solved using a whitelist on anchor tags. Second issue was a link with unicode expression of the quote. e.g. <a href=\u201dsomelink\u201d>somelink</a> | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1181 | 1307532816000000 | dread | Fixed in ckan default in cset:72f7d48d7f31. Have left Package url and Resource url links though, as these are the key links we want google to see. So we need to check these carefully for spam. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1186 | 1310556519000000 | dread | This was done by pudo in branch feature-1198-mailer and went into default, lined up for release 1.4.2. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1187 | 1308143605000000 | dread | Also stopped creating revision for user edits. Done in cset:795ccd6405ba for 1.4.1 release | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1191 | 1308650930000000 | dread | Done in cset:c3822feffb38 for 1.4.1 release | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1192 | 1308337652000000 | dread | I really think forms are a key asset of CKAN, and keeping the docs about customising and integrating them is important - i.e. forms.rst and forms-integration.rst. There are ideas being suggested for replacing bits of front-end, but forms hard to do, and David's new system is a significant offering on top of the CKAN back-end, so it seems crazy to me to abandon it. forms.rst has been updated by David Raznick in the release_v1.4.1 branch. i18n.rst - include here the creation of the pot file, deploying a translation, transifex admin load-testing.rst - I think performance should be mentioned in the glossy guide (some sort of basic metrics of speed profile, to return web pages, run searches and API operations, for 100 or 1000 packages, on a given spec machine) and have it based on a report showing how we measured it. The report would look a bit like this file, and it might do as a stub, but it seems pretty lacking. distributed.rst - agreed, remove. design.rst - agreed, delete. loaders.rst / loader_scripts.rst - yes move to wiki feeds.rst - this should be split into a tutorial for the wiki and the reference page left in sphinx importer.rst - this should be moved to ckanext-importer/doc admin.html - this has already gone in 1.4.1 authorization.rst - This is a bit jumbled. We're talking about changes to the code, so maybe not worth working hard to make this good, so I suggest leaving it, but delete the boring section "Requirements and Use Cases". deb.rst - this is an administrator task, so should stay why move this to the wiki? buildbot.rst - ok to stay here? vm.rst - I assume there's no problem with this | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1194 | 1317043212000000 | dread | Suggest changing this to "Welcome, Rob" rather than "Welcome back, Rob", avoiding the problem. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1194 | 1317053674000000 | dread | Done in cset:49e2c05e69ea | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1194 | 1317053688000000 | dread | Will go into ckan 1.5. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1195 | 1311332049000000 | dread | Also this one: http://ckan.net/storage/f/file/ | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #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 | 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? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #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. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1202 | 1314030352000000 | dread | The CKAN package page links to datapkg at: http://blog.okfn.org/2010/02/23/introducing-datapkg/ (it has always been this link). I think Rolf is referring to the three links to knowledgeforge.net in the blog post itself. These need to be edited by Rufus. Note datapkg has moved again to github. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1205 | 1310568631000000 | dread | This worked - cheers David. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1206 | 1309450216000000 | dread | Fixed with cset:149be76faabc on default branch, aiming for ckan 1.4.2. Thanks for help from Eric Lemoine. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1207 | 1311325343000000 | dread | This has been fixed. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1209 | 1310571715000000 | dread | Was fixed in cset:d959a70a19ea. Bug was introduced and fixed before a release took place. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1210 | 1309974781000000 | dread | Fix in ckan for AssertionError in cset:8f6ba8ef63f3 lined up for CKAN release 1.4.2. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1211 | 1315910650000000 | dread | I've listed what was checked into this branch 6 weeks ago and is going into release 1.4.3. Is this ticket ready to close now or are there future plans? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #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 | 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. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1214 | 1314029628000000 | dread | This appears to have been fixed by version 1.4.3. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1215 | 1310385485000000 | dread | This is now deployed on ckan.net (requires Ctrl-R to reload js). | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1217 | 1320663277000000 | dread | I haven't seen this for a while - could have been due to database corruption which has been fixed. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1218 | 1310385419000000 | dread | This has been done in cset:bd0f83a2e287 for release 1.4.2. Deployed to ckan.net. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1219 | 1310471415000000 | dread | This is a known issue and of low importance. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1219 | 1310740534000000 | dread | Patch applied in cset:8c05d27db224 for 1.4.2 release. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #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' }}} | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #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. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #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 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1226 | 1314029434000000 | dread | This appears to have gone away. No sign of it for two weeks on any OKF sites. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1228 | 1311086612000000 | dread | Done in cset:88e47b68e42d for 1.4.3 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1229 | 1319639472000000 | dread | I found another direct use of the d.b. in the home controller. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1229 | 1319645778000000 | dread | Replace code in home in cset:f19f9c5bec94 on default for release 1.5.1. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1234 | 1311183328000000 | dread | Fixed in cset:1ed3fde56a61 for 1.4.3. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1236 | 1311351476000000 | dread | Working on it on branch enh-1236-view-package-revision | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1236 | 1311699843000000 | dread | This is merged to default (for rel 1.2.5) but isn't brilliant yet because of bug #1238. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1236 | 1311759816000000 | dread | The bug is in fact in the way I work out what revision I'm displaying - it just looks at the PackageRevision. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1236 | 1323090508000000 | dread | This feature is now released, but there is a remaining bug which I've put in this ticket: #1509 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1236 | 1330019788000000 | dread | Went into CKAN 1.4.3 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1238 | 1311759784000000 | dread | Apologies, I have a problem instead with the way I identify the revision in #1236. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1239 | 1312453156000000 | dread | Fixed in 1.4.2 release. Broken in UI in 1.4.1 and API in 1.4 & 1.4.1. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1240 | 1314180488000000 | dread | I basically agree, but just thought I'd add a couple of comments into the mix. > GET at root returns whole package set (a *bad* idea) Sure it has a cost, but I don't see what the problem with this is if the list is cached. Forcing developers to paging through the list of packages is putting unnecessary obligations. I'd say that the top two RESTful operations are listing objects and getting a particular one, and you'd be taking away one of those. > Unify on /api/v{version num}/... structure Where is it not currently unified? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1240 | 1324320107000000 | dread | Although I'm generally in favour of Action API over RESTful, Action API does need some sorting out wrt listing methods, advertising what params are allowed and checking those that are passed. Using the Action API is so hard without reading the code! The RESTful API is handy when you want to do something quickly in a browser. I'd not want to lose these two, for example: * to look at a package /api/rest/dataset/xyz * API version etc. at /api/util/status (coming with ckan 1.5.2) It's also really handy in demos and to send as links to people on the list. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1244 | 1323089995000000 | dread | No progress yet | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1246 | 1311863583000000 | dread | We have an unresolved issue with the display of the 'open data' icon that showed up when we upgraded ckan.net to the latest beta last week, but I didn't realise the search page http://ckan.net/package was showing all packages as open (the revision page and package pages seem fine). Last week when I upgraded from 1.4.1 to 1.4.2beta, there was an exception thrown when loading the home page. The exception was in doing the isopen call. It was solved by making some code changes directly on the ckan.net server to make it an attribute query instead of function call. It was strange because this behaviour didn't occur on my machine and all the tests passed. Here are the manual patches on ckan.net (the application.js change is unrelated, by someone else): {{{ diff -r adf254b7c507 ckan/public/scripts/application.js --- a/ckan/public/scripts/application.js Sat Jul 23 18:16:15 2011 +0100 +++ b/ckan/public/scripts/application.js Thu Jul 28 14:10:23 2011 +0000 @@ -2,6 +2,7 @@ $(document).ready(function () { CKAN.Utils.setupUserAutocomplete($('input.autocomplete-user')); CKAN.Utils.setupAuthzGroupAutocomplete($('input.autocomplete-authzgroup')); + // $('.resource-url').parent( }); }(jQuery)); diff -r adf254b7c507 ckan/templates/_util.html --- a/ckan/templates/_util.html Sat Jul 23 18:16:15 2011 +0100 +++ b/ckan/templates/_util.html Thu Jul 28 14:10:23 2011 +0000 @@ -43,7 +43,7 @@ standard package listing --> <ul py:def="package_list(packages)" class="packages"> <li py:for="package in packages" - class="${'fullyopen' if (package.isopen() and package.resources) else None}"> + class="${'fullyopen' if (package.isopen and package.resources) else None}"> <div class="header"> <span class="title"> ${h.link_to(package.title or package.name, h.url_for(controller='package', action='read', id=package.name))} @@ -60,7 +60,7 @@ </ul> </py:if> <ul class="openness"> - <py:if test="package.isopen()"> + <py:if test="package.isopen"> <li> <a href="http://opendefinition.org/okd/" title="This package satisfies the Open Definition."> <img src="http://assets.okfn.org/images/ok_buttons/od_80x15_blue.png" alt="[Open Data]" /> @@ -72,7 +72,7 @@ </a> </li> </py:if> - <py:if test="not package.isopen()"> + <py:if test="not package.isopen"> <li> <span class="closed"> ${h.icon('lock')} Not Openly Licensed diff -r adf254b7c507 ckan/templates/home/index.html --- a/ckan/templates/home/index.html Sat Jul 23 18:16:15 2011 +0100 +++ b/ckan/templates/home/index.html Thu Jul 28 14:10:23 2011 +0000 @@ -64,6 +64,7 @@ </py:if> <h4>Recently changed packages</h4> + <!-- ${c.latest_packages} --> ${package_list_from_dict(c.latest_packages)} <p><a href="${h.url_for(controller='revision', action='index', diff -r adf254b7c507 ckan/templates/layout_base.html --- a/ckan/templates/layout_base.html Sat Jul 23 18:16:15 2011 +0100 +++ b/ckan/templates/layout_base.html Thu Jul 28 14:10:23 2011 +0000 @@ -101,6 +101,7 @@ am_authorized_package_create = h.am_authorized(c, actions.PACKAGE_CREATE) ?> <li py:if="am_authorized_package_create">${h.nav_link(c, _('Add a package'), controller='package', action='new', id=None)}</li> + <li><a href="/storage/upload">Upload Data</a></li> <li>${h.nav_link(c, _('Tags'), controller='tag', action='index', id=None)}</li> <li>${h.nav_link(c, _('Groups'), controller='group', action='index', id=None, highlight_actions = 'new index')}</li> <li>${h.nav_link(c, _('About'), controller='home', action='about', id=None)}</li> diff -r adf254b7c507 ckan/templates/package/read.html --- a/ckan/templates/package/read.html Sat Jul 23 18:16:15 2011 +0100 +++ b/ckan/templates/package/read.html Thu Jul 28 14:10:23 2011 +0000 @@ -56,7 +56,7 @@ </py:if> <li class="widget-container widget_text"> - <py:if test="c.pkg.isopen() and c.pkg.resources"> + <py:if test="c.pkg.isopen and c.pkg.resources"> <h3> This Package is Open </h3> @@ -80,7 +80,7 @@ </p> </py:if> - <py:if test="not(c.pkg.isopen() and c.pkg.resources)"> + <py:if test="not(c.pkg.isopen and c.pkg.resources)"> <h3 i18n:msg="">This package is Not Open</h3> <p>Either because it is not openly licensed or is missing }}} | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1248 | 1319797763000000 | dread | Fixed in cset:188d27a56c89c35f97f3a79fdd0a6460223f86cf on branch release-v1.4.3. This was only seen in CKAN 1.4.3beta. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1251 | 1317315159000000 | dread | rgrp did this last weekend. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1252 | 1317315135000000 | dread | This is done now? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1256 | 1319812556000000 | dread | It sounds like this became an issue with CKAN 1.4.3 and the fix goes into CKAN 1.5. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1258 | 1319812452000000 | dread | I believe this was broken with the introduction of moderated edits in CKAN 1.4.3 and this fix went into 1.5. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1262 | 1314029150000000 | dread | Pudo - I'm not sure what's meant here. Are you talking about moderation for new users? Or some other sort of enforcement? Is it spam you want to target? The links you're concerned about - are they the spam ones in the User's 'about' field? If so, I think we *should* allow users to have links, although continue with applying them with 'nofollow' and attack spammers back in a concerted strategy across all editable fields - see ticket #1257. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1263 | 1314029279000000 | dread | This was fixed in cset:8d293393a9f2 for release 1.4.3. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1265 | 1312566052000000 | dread | Fixed in cset:a1b8dd169f4e on 1.4.3 release and merged to default. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1266 | 1312797477000000 | dread | Fixed in 987dc4fe078e on 1.4.3 branch and default. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1267 | 1312889130000000 | dread | John thinks it is a problem with WebOb 1.0.6 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1267 | 1312890962000000 | dread | This error has been occurring on at.ckan.net which has webob 0.9.7.1-1 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1267 | 1312894071000000 | dread | Running tests with WebOb 0.9.7.1, we see the error! Am now trying to fix. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1267 | 1312897724000000 | dread | Fixed in cset:db5bf5b45b4f for ckan 1.4.3. Later versions of webob add the charset header for unicode errors (webob/exc.py:generate_response): {{{ extra_kw = {} if isinstance(body, unicode): extra_kw.update(charset='utf-8') resp = Response(body, status=self.status, headerlist=headerlist, content_type=content_type, **extra_kw ) }}} This was fixed in webob cset:25fc14d49623 which went into WebOb 1.0. This problem affects versions from CKAN 1.4.2 back to 1.3.1. We had been avoiding this in CKAN previously by only doing abort() with a plain string. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1270 | 1312912188000000 | dread | Fixed in cset:ca5295c9c8cf and released as ckanclient version 0.9 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1275 | 1319812967000000 | dread | Going into release 1.5. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1280 | 1328786670000000 | dread | David tells me that this was fixed in CKAN when we moved to SQLAlchemy 0.7 #1433 which went into CKAN 1.5.1. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1281 | 1314021919000000 | dread | Done by pudo in cset:eaf342823caf on default branch, so headed for release 1.4.4. "Work around the fact that locale changes do not affect the running request and therefore led to an incorrect flashing message. Now manually changing language." | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1283 | 1326720891000000 | dread | Since we switched completely to SOLR, this has been true. SOLR doesn't index deleted packages so you can't search them, but they can be read/edited by admins. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1283 | 1330083933000000 | dread | This went into CKAN 1.6 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1284 | 1315212258000000 | dread | Fixed by rgrp in cset:1952445d2802 on release-v1.4.3 and default. Comment: do not create revision for changes to users as they are not revisioned. * This had already been removed in cset:8d6fde0e2196 (then in user controller) but Adria seems to have reinstated this when refactoring things into the logic layer. This 'bug' explains the huge number of empty revisions we have been seeing on ckan.net. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1284 | 1315212603000000 | dread | I've added tests for this (to prevent yet another regression!) in cset:1b77ce8ce560. Closing. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Note:
See TracReports for help on using and creating reports.
