{23} Trac comments (3729 matches)

Results (1601 - 1700 of 3729)

← 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 →
Ticket Posixtime Author Newvalue
#1240 1316022145000000 rgrp add autocomplete
#1240 1324319119000000 rgrp assigning to kindly for review
#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.
#1240 1325473312000000 rgrp IMO this is non-urgent and can move out of v1.6 as we have enough more important stuff to do.
#1239 1311442163000000 rgrp Fixed in cset:adf254b7c507 (see https://bitbucket.org/okfn/ckan/changeset/adf254b7c507)
#1239 1312453156000000 dread Fixed in 1.4.2 release. Broken in UI in 1.4.1 and API in 1.4 & 1.4.1.
#1238 1311583876000000 kindly I cannot reproduce this, to me it looks like it does get the correct revision. If you for example look at the package a millisecond before i.e http://ckan.net/package/osm%402010-11-30%2000%3A21%3A49.627829 the tags are no longer there that were added in that revision.
#1238 1311759784000000 dread Apologies, I have a problem instead with the way I identify the revision in #1236.
#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
#1234 1311183328000000 dread Fixed in cset:1ed3fde56a61 for 1.4.3.
#1233 1315948668000000 rgrp Removing from v1.5 as not a priority atm.
#1232 1315948536000000 rgrp Removing from ckan-v1.5 as do not think any of this is top priority (correct me if I'm wrong!)
#1231 1315948921000000 rgrp @kindly: Does this fit in with current plans? If not suggest we close as invalid/wontfix or put into the backlog (though given lack of content not sure that is very useful ...)
#1231 1325474087000000 rgrp Closing as wontfix (or duplicate). We now have stats in footer as of #1576. googleanalytics (e.g. http://thedatahub.org/analytics/dataset/top) would be nice to have but should be part of stats
#1231 1325474447000000 rgrp See #1101 for other duplicate ...
#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
#1229 1312191530000000 amercader Done, except for Revision related stuff, which probably overlaps with work being done by David Raznick.
#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.
#1228 1311086612000000 dread Done in cset:88e47b68e42d for 1.4.3
#1226 1314029434000000 dread This appears to have gone away. No sign of it for two weeks on any OKF sites.
#1225 1310642407000000 dread Done in ckanext repo cset:70fb690a0769
#1223 1310573893000000 dread pudo did this in cset:1ab655b7b76a and cset:7a9c6b1060cf ready for release 1.4.2.
#1222 1310556618000000 dread Fixed in cset:4737c86d1d81 for release 1.4.2.
#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.
#1219 1310471415000000 dread This is a known issue and of low importance.
#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.
#1218 1310385419000000 dread This has been done in cset:bd0f83a2e287 for release 1.4.2. Deployed to ckan.net.
#1217 1320663277000000 dread I haven't seen this for a while - could have been due to database corruption which has been fixed.
#1215 1310335541000000 kindly fixed cset: 8a317eadbb36 If you delete the last row then it just clears it instead of deleting the row.
#1215 1310385485000000 dread This is now deployed on ckan.net (requires Ctrl-R to reload js).
#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.
#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 }}}
#1214 1314029628000000 dread This appears to have been fixed by version 1.4.3.
#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?
#1211 1315948703000000 rgrp Let's close and re-open (or open a new ticket) for future work.
#1210 1309974781000000 dread Fix in ckan for AssertionError in cset:8f6ba8ef63f3 lined up for CKAN release 1.4.2.
#1209 1310571715000000 dread Was fixed in cset:d959a70a19ea. Bug was introduced and fixed before a release took place.
#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.
#1208 1311525306000000 rgrp Propose this ticket can be closed as webstore is now functional and being used. Can open new tickets for specific improvements / adaptations as the need arises.
#1208 1312191646000000 pudo This should be closed: * https://github.com/okfn/webstore - See README for details * Python client lib: https://github.com/okfn/webstore-client * http://webstore.thedatahub.org/ - Demo install * http://wiki.ckan.net/Webstore - Overview
#1207 1311325343000000 dread This has been fixed.
#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.
#1205 1310568631000000 dread This worked - cheers David.
#1204 1311179980000000 thejimmyg Sorry, is this a CKAN issue or a datacatalogs.org one? If it is datacatalogs.org do you mean a catalog rather than a package? If so, can you give an example of the sort of change you've made? Marking as invalid until we get more information.
#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.
#1202 1315821804000000 rgrp This now irrelevant and relevant content has gone from thedatahub theme.
#1200 1311180218000000 thejimmyg This is a duplicate of #1108. Let's have the discussion there please.
#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).
#1199 1308922389000000 pudo merged to default with password reset forms
#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.
#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.
#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?
#1197 1340010256000000 toby personally I'm against these for 4 reasons a) The site should be self explanatory and if it is not this is a failure of design b) a cookie would be needed to prevent these happening all the time - cookies are bad as they interfere with caching proxies. c) I find stuff like this patronising/annoying for the user d) They are a maintenance burden for ckan as we do not have a single instance Therefore I'd suggest closing this as a won't fix - I agree this is just a personal view point and therefore am not going to actually close the ticket but just record my opinion.
#1197 1340018903000000 seanh Hi Toby, yes I think I agree with you, it reminds me of when I install new Android apps on my phone, some of them start off by bothering me with some sort of guided tour or long instructional text, I hate this and always skip through without reading it, expecting to be able to figure out the interface for myself. The one thing that something like this could be useful is, rather than showing someone how to use the site, showing them what the site is capable of so they can assess whether it meets their needs/is something they're interested in. However, we already have a good guided tour of this type on ckan.org/features, those pages are really pretty good. Close this as wontfix?
#1197 1340019675000000 toby Thinking horrible thoughts, there was a rumour of a ckan tour, for something like that this would be useful. Not sure where that plan is at? if there is a ticket for it maybe link to this one and close?
#1197 1340020357000000 seanh AFAIK there isn't a ticket for that, it was something originally requested as part of the demo site, but since the devs think it's a horrible idea I don't think it's going to happen, easiest way to make a CKAN tour would be a series of static pages like the one we already have on ckan.org, I think that combined with a real functioning demo site probably meets the requirement. Anyway, closing this as wontfix
#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
#1195 1311332049000000 dread Also this one: http://ckan.net/storage/f/file/
#1195 1311841763000000 rgrp Fixed in https://bitbucket.org/okfn/ckanext-storage/changeset/49734285f1ef
#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.
#1193 1309768960000000 kindly fixed cset:87d6140e06ad
#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
#1192 1310135468000000 thejimmyg This is now a child ticket of #1142
#1192 1312191462000000 rgrp Marking this as closed as Anna has completed and this is now deployed at http://docs.ckan.org/.
#1191 1308650930000000 dread Done in cset:c3822feffb38 for 1.4.1 release
#1190 1320143592000000 rgrp A very substantial portion of this got done as part of 0.5 including the webstore #1208 and the majority of automated conversion #1398. #1432 is currently deferred so we're going to close this ticket on basis that item (3) is now out of scope.
#1189 1323173227000000 thejimmyg Closing this ticket in line with ticketing policy since it is over 6 months old. If someone would like to develop an extension that uses spideroak as a back end we can look at it again.
#1187 1308143605000000 dread Also stopped creating revision for user edits. Done in cset:795ccd6405ba for 1.4.1 release
#1186 1310556519000000 dread This was done by pudo in branch feature-1198-mailer and went into default, lined up for release 1.4.2.
#1183 1311181719000000 thejimmyg Hi John, Can you have a look at this one too please? Cheers, James
#1183 1311771069000000 johnglover Fixed in new datapreview code (currently running on the test.ckan.net), which now gets the preview data from a webstore instead of the dataproxy API. It also only now shows a preview button for resources that were successfully archived and saved in the webstore.
#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.
#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>
#1178 1308045351000000 rgrp Fixed. This was due to incorrect config of bucket option.
#1177 1307360643000000 rgrp What revision of the CKAN code are you using (do hg id to get revision if installing from source). Have you modified the package template in any way? Have you restarted apache after upgrading?
← 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 →
Note: See TracReports for help on using and creating reports.