{23} Trac comments (3729 matches)

Results (801 - 900 of 3729)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
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.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Note: See TracReports for help on using and creating reports.