{23} Trac comments (3729 matches)

Results (1901 - 2000 of 3729)

← 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 →
Ticket Posixtime Author Newvalue
#1214 1310072808000000 dread I've put the fixes onto test.ckan.net - repoen the ticket if there are any issues.
#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 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 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 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 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 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 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 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 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 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 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 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 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 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 1309982828000000 dread I'm working through these on branch defect-1214-api-improvements. "Server returns text/html for errors" - now fixed in cset:0a533a8da3df
#1210 1309974781000000 dread Fix in ckan for AssertionError in cset:8f6ba8ef63f3 lined up for CKAN release 1.4.2.
#1193 1309768960000000 kindly fixed cset:87d6140e06ad
#1205 1309768720000000 kindly fixed in default cset:5e2070688e54 The upgrade now works locally, so the upgrade should work now.
#1206 1309450216000000 dread Fixed with cset:149be76faabc on default branch, aiming for ckan 1.4.2. Thanks for help from Eric Lemoine.
#1199 1308922389000000 pudo merged to default with password reset forms
#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?
#103 1308828847000000 dread Now we have this working in #1141 we can add the links from the package history page suggested here.
#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 1308822557000000 rgrp Not sure we need exposure this via the API (at least at this point) as things like auto mass emailing could be in done in separate component (that talks to CKAN).
#1198 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.
#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
#1191 1308650930000000 dread Done in cset:c3822feffb38 for 1.4.1 release
#1164 1308647224000000 amercader Done. See it in action here: http://publicdata.eu/map
#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
#1142 1308326118000000 annapowellsmith List of new docs tasks agreed by APS and RGRP: * Tutorial on the wiki (long-term): Integration with Wordpress and Drupal and Javascript * Overview of domain model both for average users and for devs * 2-page glossy brochure * Vision for CKAN http://notebook.okfn.org/2011/04/27/data-hubs-data-management-systems-and-ckan/ * Comparison : use http://wiki.ckan.net/Related_Software as starting point - build on wiki - Socrata and OGDI * Renaming: separation between ckan.org and ckan.net * More documentation in the code ... * Config options generated from code or move this to WUI ... See also proposed overhaul at http://wiki.ckan.net/Documentation_Plans
#1033 1308310446000000 dread Fixed in 5c7caca30737 for v1.4.1
#961 1308230058000000 rgrp @kindly: can we close this ticket now. All the meat is done and the remaining related tickets are either low priority or possibly wontfix.
#1187 1308143605000000 dread Also stopped creating revision for user edits. Done in cset:795ccd6405ba for 1.4.1 release
#1178 1308045351000000 rgrp Fixed. This was due to incorrect config of bucket option.
#1123 1307795508000000 rgrp You can't get small amazon instances as 64 bit and many people's own machines are 32 bit. How costly is packaging no-arch exactly (it must be more than a simple 'switch' in the build if you are saying this is costly :-) )
#1123 1307790563000000 thejimmyg This isn't necessarily a trivial thing. Let's get the build system for the packages stable before we start changing it all to support alternative architectures. Once the packaging is working well it would be trivial to switch those servers to amd64. I'm sorry, but this isn't worth the investment in manpower at the moment.
#1173 1307615271000000 pudo Now available in ckanext-rdf and linked to from WUI.
#1174 1307615200000000 pudo wontfix as thejimmyg wants to turn REST API into RPC API and this doesn't fit in. Not an excellent plan in my idea but this is to be discussed elsewhere.
#1159 1307615133000000 pudo Rudimentary RDFa has been added with seeAlso to API.
#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.
#1165 1307444733000000 nils.toedtmann See also http://ckan.okfnpad.org/multisite
#1096 1307444626000000 nils.toedtmann See also http://ckan.okfnpad.org/multisite
#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.
#1123 1307374691000000 dread I'll change the architecture to "all" as per this article: http://linuxreviews.org/man/deb-control/
#1175 1307372833000000 fccoelho Thats the thing, I don't get any error message, no even in the logs. But I can't even load a page.
#1177 1307367923000000 fccoelho Ok it fixed it! thanks a lot!! Is there any side effects to the removal of this line, I should know of?
#1177 1307367354000000 fccoelho OK I did an fgrep on all package template and found the line on layout.html, I'll comment the block and test.
#1177 1307366621000000 fccoelho I have not modded the code in any way... I'll look for those lines in the template.which template is it? read.html does not have a line such as this.
#1177 1307365496000000 rgrp The issue here is that the line should never be reached because g.has_commenting should be False: https://bitbucket.org/okfn/ckan/src/5730c79db461/ckan/lib/app_globals.py @Flavio: have you modded your code in any way? is self.has_commenting False in your app_globals.py A quick fix would be to remove the template lines calling to remove the lines in the template: {{{ ${h.subnav_link(c, h.icon('comments') + _('Comments &amp; Questions'), controller='package', action='comments', id=c.pkg.name)} }}}
#1177 1307361157000000 fccoelho to upgrade I used the method describeb on bitbucket, after upgrading pip-requirements: pip -E pyenv install -r pip-requirements.txt after that I did a paster --plugin ckan db upgrade --config ckan.emap.fgv.br.ini the revision id on my pyenv/src/ckan is: 5730c79db461+ tip yes, I have restarted apached after upgrading
#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?
#1121 1307358426000000 dread We don't need to support JSON extras at the moment.
#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.
#1132 1307352675000000 dread Yes, these are apparently search-related and so are skipped when testing under sqlite. See README.rst for more info. Compare with this: {{{ $ nosetests --ckan --with-pylons=test-core.ini ckan/tests/functional/test_authz.py ............................................ ---------------------------------------------------------------------- Ran 44 tests in 69.287s OK }}}
#888 1307352537000000 thejimmyg I don't think any progress has been made on this for a bit so I'm assigning it to me.
#1152 1307352165000000 amercader Bumping to ckan-v1.5-sprint-3 and updating the CC email addresses so people actually get any updates.
#1175 1307350866000000 dread Flavio, can you post here the exception that you get?
#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)
#1173 1307000249000000 pudo I propose we do a bit of frameworkiness here: set up a two-part content type registry and refactor the API controller to use it. The idea would be to do the following things: 1. Create a registry mapping format extensions to mime types: RepresentationRegistry.add_format('json', 'application/json') 2. Create a registry of (mime types, entity types) -> converter functions that yield an appropriate representation of the entity. 3. Hook this into the _finish method of the API controller based on Accept: handling 4. Add support for /api/rest/ENTITY/NAME.{format} and /ENTITY/NAME.{format} to routing, use registry from (1) to rewrite accept headers. 5. Register converters in load_environment or via IConfigurable plugins 6. Document What do you think?
#1170 1306864422000000 dread Done in cset:4d2d0857281f on default
#1167 1306857750000000 thejimmyg Creating the AMI is really just the icing on the cake. The hard bit is getting the packaging right so that's where we need to concentrate first. Once the packaging works we just make sure apt-get upgrade is run regularly. +1 to the list above. I also agree we should install solr by default. Who has actually done a CKAN solr install? I haven't but together with whoever has I can try to package it up. Wrt to usernames and passwords, I'll look into how dpkg manages those blue pop-up screens for entering configuration options.
#1167 1306857142000000 sebbacon Another thing to consider: how do we ensure we keep a single, up-to-date version available? (I'm thinking wrt developer / sysadmin workflow)
#1167 1306856992000000 sebbacon Yes to all the above. Further question: which extensions should be installed as standard? I would argue: * ckanext-stats * ckanext-googleanalytics * ckanext-disqus * ckanext-solr (implies installing a running solr, too...) * ckanext-follower * ckanext-admin Note that googleanalytics and disqus both require user accounts set up at the corresponding service. Not sure how we would handle this in the instance setup.
#1156 1306855111000000 pudo Both are now implemented but may need further work to adhere to developing conventions wrt to location etc.
#1166 1306847326000000 thejimmyg Also, rather than INSPIRE=true we should probably have information about the harvesting mechanism and the harvest object type? This also relates to our use of the kind field on the resource.
#913 1306774962000000 pudo moving to CKAN, still need a resolver
#912 1306774876000000 pudo moving to ckan
#944 1306774766000000 pudo done at iati.ckan.net
#1155 1306773174000000 pudo Now implemented based on CSV export available on the catalogue page: * http://data.london.gov.uk/catalogue
#826 1306766057000000 dread This went into ckan release 1.3.2.
#1169 1306754833000000 dread Done on default. Will appear on ckan.net next time it is branched and updated.
#1122 1306747706000000 dread Changing this to "won't fix" just to be clear
#1122 1306662099000000 pudo I don't think there's really a nice way to do this with the current solr indexing library, but I've commented out the list handling code which should really make handling this cleaner.
#1165 1306413953000000 nils.toedtmann this is similar, but not equal to #1096
#985 1306408134000000 amercader Duplicate of #1155 and #1156
#1161 1306408026000000 amercader Duplicate of #1157
#985 1306407617000000 amercader Moving this to the PDEU (publicdata.eu) project
#1149 1306090663000000 kindly Failed dgu tests due to as_dict not working on deleted objects. fixed by cset:c9b9cf513e44
#1149 1305971672000000 kindly cset:b1634d405066
#1148 1305969925000000 kindly complete cset:96a43c9d8bd7
#1142 1305881244000000 lucychambers Replying to [ticket:1142 rgrp]: > Previous super ticket (from 3m ago): http://trac.ckan.org/ticket/927 > > * CKAN 1-page overview (for enterprise and for data hackers) > * Administrator's Guide (including install) > * Extensions Guide > * Separate CKAN.net info from Software Documentation (?) > > == Minor Items == > * Include guide on how to configure local filesystem storage, instead of Google storage. (http://lists.okfn.org/pipermail/ckan-discuss/2011-May/001235.html)
#1142 1305880901000000 sebbacon The guys at Wikimedia also produced this spreadsheet including notable users and features of other software. Could be useful.: https://spreadsheets2.google.com/ccc?authkey=CLWu1cgP&hl=en&key=tYiwc9kUVLLlALOQEzFqujw&hl=en&authkey=CLWu1cgP#gid=0
#1078 1305828965000000 kindly complete: cset:843b78bae016
#191 1305814900000000 dread Maybe allow searching by package creation date too? Suggestion from kindly: when indexing a package, have the search backend also store the metadata_modified value, to make it easy to search on it.
#191 1305732414000000 dread Do this after refactor #1129
#191 1305732285000000 dread Will's suggestion is to have "modified_since" param, just as we have for Revision Search. Maybe we don't need a range. 'Order by modification' should be on by default for queries with 'modified_since' param.
#1122 1305718009000000 dread This user is now storing his list as a string so is happy. But I'll leave this ticket open, for pudo to decide whether there is an issue with SOLR indexing tuples/lists, as per the previous comment.
#1134 1305623531000000 sebbacon Agreed with James that we should consider *from the start* how to provide for a nice UI -- my worry is if we start out with people editing raw JSON we'll end up keeping that for years :)
#1092 1305570822000000 kindly completed cset: ca1ac4112ea2
#818 1305559442000000 dread 1.4 complete
#1131 1305537897000000 dread Fixed on branch release-v1.3.5 cset:3461ed6bab0c
#1127 1305458489000000 rgrp one other thing: i think the plan is for CEPs to be in restructured text (for easy transfer to docs). This should be mentioned and the template in the wiki should be in ReST.
#1127 1305458020000000 rgrp I'm obviously a strong +1 but feel we should stick with the CEP name (we have PEP and DEP and CREP really does sound weird compared to CEP). Also I think we may need to do a bit more to clarify when you just do a good ticket and when one does a CEP (looking at what has occurred already). I think this may be one reason to keep CEPs separate in drafting from trac as will clearly distinguish CEPs from standard tickets.
#1136 1305217553000000 kindly Replying to [comment:2 kindly]: > This would be nice but it is not necessary. The current mapper implementation may be nice but not is battle tested.. I meant the mapper extension "IS" battle tested.
#1137 1305217449000000 kindly I am not sure this needs to be done. I think we should keep the continuity object always in the table, even if it is deleted. The querying should be done through the logic layer so the deleted state should not be an issue. The clients should be entirely state aware. The only thing that needs to be done is to remove all statefullness of relations. These are the only things that are complicated. This would make vdm just a simple copy on write mechanism, with the client controlling the state.
#1136 1305216218000000 kindly This would be nice but it is not necessary. The current mapper implementation may be nice but not is battle tested..
#1129 1305212467000000 kindly > * There seems some misunderstanding: change to have logic layer has almost nothing to do with being able to remove main stateful stuff in vdm. To be able to remove most of stateful stuff in vdm requires us to make some other changes (re foreign keys from revision objects to continuity) The logic layer does not automatically help out, however it makes our life easier if we want to handle state ourselves. For example take package tags, if we remove the stateful_m2m properties and just use normal sqlalchemy relations. We will still want statefullness (i.e active, pending, deleted) on the package_tags table. We should update those on the table ourselves in the logic layer. > * There are other simplifications we should make to vdm before embarking on this (e.g. move to SessionExtension from MapperExtension). This is easy as that work has been done in changeset branch and can be backported. I agree but event thought the MapperExtension way is not great, it is very well field tested.
#1137 1305211672000000 rgrp Most of this change has been implemented in the changeset branch [1] but could be backported reasonably easily to main. [1]: https://bitbucket.org/okfn/vdm/src/changeset/
← 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 →
Note: See TracReports for help on using and creating reports.