{23} Trac comments (3729 matches)

Results (1401 - 1500 of 3729)

← 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 →
Ticket Posixtime Author Newvalue
#534 1288002762000000 dread I fixed this a while back.
#826 1297417900000000 kindly I forgot to mention that he main advantage of the fixed fields, is that we can make them properly searchable i.e the values searchable. This currently does not work for package extra values as they are jsons. I have added this searchability for the sql backend.
#1229 1319639472000000 dread I found another direct use of the d.b. in the home controller.
#1597 1326821156000000 dread I found that adding facet:limit=200 does what we need.
#2445 1338473161000000 aron.carroll I generally take the approach that a form submitted via POST should always redirect to a page. This prevents accidental user resubmissions when hitting refresh as well as the annoying popup saying "are you sure you want to re-submit". http://en.wikipedia.org/wiki/Post/Redirect/Get Looking at the rest of CKAN it doesn't do this so I'll leave it up to you.
#2695 1343121866000000 shevski I got a server error once updating long tags, but can't reproduce. Look fine apart from slowness already mentioned - anything we can do about that?
#1077 1319797284000000 dread I guess this is not a priority now.
#1447 1330082636000000 nils.toedtmann I had forgotten to check s019 how well my cleanup script is working (and now s019 is gone), but at least it didn't destroy it :-) You might want to give it a try on s025/PDEU. (Tell me if you want me to do that).
#1709 1327620136000000 rgrp I have already fixed the issue with counts (in a branch to be merged) :-) Also this is opened in an already ended sprint :-) IMO we don't bother testing simple_search since intended to be hacky and unsupported. Worth documenting the option but highlighting non-supported nature.
#735 1292957248000000 dread I have been through looking for package names with a trailing underscore checking if they should indeed be separate package from those without. #872 and #873 cover creation of the duplicates in the first place.
#2223 1332246030000000 zephod I have been working overtime to try and get this change straightened out as it's suddenly on the critical path for something. Have a look here: https://github.com/okfn/ckan/tree/feature-2223-bootstrap It's 80% of the way there; some form CSS needs overriding because Bootstrap tends to make things very large so they spill over. But on the whole the markup is in a steady state, which is what we need.
#1709 1327659562000000 dread I have checked in a similar fix and with a simple test.
#1359 1329076613000000 rgrp I have completely overhauled the licenses repo (https://github.com/okfn/licenses), see https://github.com/okfn/licenses/issues/1 and new looking: http://licenses.opendefinition.org/ Next step is to ship the core set of licenses we need for CKAN as part of CKAN and remove the external dependency.
#698 1291858346000000 Stiivi I have created "proof of concept" implementation that will use external data proxy service when accessing: {{{ /api/data/PACKAGE_ID }}} like: {{{ http://127.0.0.1:5000/api/data/069c80f8-8476-452e-bfd4-0a9077666c14 }}} It just works and requires refactoring to match ckan standards. I would need help from soneone who knows ckan internals better.
#1339 1316010607000000 kindly I have fixed the isodata and made a slightly modified int_converter for this case. In the correct place and raises invalids on not being an int. cset:a4af115116bb The thinking was that the input of these fields would be through the api so the empty string case did not arise. These should clearly be converted to None (Null). What issues in general? Having done this lots of times before you always end up needing to write your own little validators as the standard ones never do what you want. Thats the point of them. Look in ckan/lib/validators if you need examples. So what you did was correct...
#1394 1320663304000000 dread I have half a fix for this at the moment.
#816 1312295371000000 johnglover I have implemented the resource autocomplete so am closing this for now. I agree that more information on the resource would be a good addition. It seems a bit of a different issue to just adding autocomplete though, with potentially far more changes to the codebase, so maybe it would be better discussed in a separate ticket/CREP. However, any new fields would presumably want to either be constrained or have an autocomplete and so can reuse the work done on this feature. Cheers, John
#1171 1347358705000000 ross I have implemented this on the datahub, but this change likely needs to be made to CKAN core. Probably as part of 2.0. The format on tdh is currently: ${TITLE}. ${AUTHOR}. Retrieved ${UTC time}. ${DATASET LINK} Best discuss and agree on what format should be supported. Mark, I've assigned this to you as it is tagged academia ;)
#876 1292891133000000 [email protected] I have looked into this already so I can give you a head start. I am working on a project that uses many backends so I have some experience. So here is what I have found so far. == nested transactions == VDM does not support sqlite, as it uses nested transactions. I do not think vdm needs nested transactions. It can use a flush instead. Here is the patch that works. All vdm tests pass. {{{ --- a/vdm/sqlalchemy/base.py Sat Sep 11 23:06:26 2010 +0000 +++ b/vdm/sqlalchemy/base.py Mon Dec 20 16:16:34 2010 +0000 @@ -40,9 +40,8 @@ self.setattr(session, 'HEAD', True) self.setattr(session, 'revision', revision) if revision.id is None: - session.begin_nested() session.add(revision) - session.commit() + session.flush() }}} == indexes == The index file 021_postgres_upgrade.sql in the migrate repository will not run as it uses syntax particular to postgres. Another will need to be made thats similar. sqlite does not support complex indexes like upper(text), so a work around will need to be found. == unicode == The harvesting returns utf8 encoded strings and pysqlite dbapi only supports python unicode objects (as far as I can tell). There will need to be a process in converting all strings that get into the database with string.decode("utf8") == dates == Have not looked into this one too much. However, as sqlite stores everything as strings the timestamps appear to be failing on conversion back into python. I have solved the above two issues before by adding attribute extensions to sqlalchemy mappers to do the conversions without effecting too much code. == in memory sqlite == Some tests need to change in order to make sure the database is created first because the database gets lost each time. In the tests that I have made pass, they run in about a seventh of the time as they do on postgres. == Other things to keep in mind. == * Need a new flag in test.ini to remove full text indexing completely, or always use it with solr. * There are enough incompatibilities between the databases that you would also want to test against postgres as well, at least before a release. * I would probably upgrade sqlalchemy first, so you will not have to the changes twice. The new versions are significantly faster too. * I have submitted a patch to #868 that makes the tests run about 2.5 times as fast and I think there are more low hanging fruit if the aim is test speed.
#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.
#876 1292939711000000 [email protected] I have read quite a lot of people having problems with savepoints with sqlite and thought they were not supported on sqlalchemy. They are at least not consistant with postgres ones. I may well be out of date on this. Here is an [http://groups.google.com/group/sqlalchemy/browse_thread/thread/dc9d1b61044bf730/65a62a33ec313842?lnk=gst&q=no+such+savepoint#65a62a33ec313842 example] even though its a bit old. I did get some non deterninistic errors, the above seemed to fix them. A failed subtransaction is not handled well by sqlalchemy and I think this causes knockon effects due to the unresolved transaction. I would stay well clear of them entirely if possible. What are the errors you are getting?? My 2 cents. ignore me at will... I would think about using a different backend for testing than production. [http://stackoverflow.com/questions/2716847/sqlalchemy-sqlite-for-testing-and-postgresql-for-development-how-to-port look here]. If you want to support both then you should test on both. There are simple ways to scrape a few more minutes off the tests. If you want real speed, then a multiprocess solution (with a database per core) would be sensible if a bit tricky.
#1792 1333037710000000 dread I have tracked down the changesets to: * branched off master at dff9f7a8 * merged master in for the last time (and became the 'new master'?) at 1a9227d9ff73c
#767 1296593504000000 thejimmyg I haven't heard this mentioned yet, but yes, let's try to implement it if possible. Appears to expose a CSW interface? http://webhelp.esri.com/geoportal_extension/9.3.1/index.htm#ext_csw_clnts.htm
#766 1294248066000000 thejimmyg I haven't heard this mentioned yet, but yes, let's try to implement it if possible. Appears to expose a CSW interface? http://webhelp.esri.com/geoportal_extension/9.3.1/index.htm#ext_csw_clnts.htm
#1217 1320663277000000 dread I haven't seen this for a while - could have been due to database corruption which has been fixed.
#1400 1328612209000000 johnglover I haven't written any docs for this. I'm also not sure what the status is, Ross was doing some work on it recently so he is probably the man to ask.
#2406 1337766385000000 toby I installed CKAN yesterday afternoon from source, using the instructions at http://docs.ckan.org/en/ckan-1.7/install-from-source.html Most things worked pretty smoothly and, luckily, when they didn't I was lucky enough to have David Raznick on hand to help sort them out. As a result I've made the following notes on where the doc could be improved. For some ghastly reason I am running Linux Mint, which is some variant of Ubuntu. It's not 10.04, so no package, hence the source install. Sec 2: Not wanting a mysterious file called 'pyenv' in my home directory, I created a directory ~/ckan and typed 'virtualenv pyenv' from there. Everything worked fine. But if I had needed the 'tip' it would have been a little confusing. It would also be worth reminding the user that the dubious package is one they've supposedly just installed, so if that went OK, they won't need to worry about this. The tip also isn't clear about under what circumstances I'd need to do the 'easy_install pip' - I didn't need to (is that also only when python-virtualenv is missing?) Sec 4: This worked, but the example command for installing a particular version is confusing. It says it is for 1.5.1, but replacing '1.5.1' with '1.7' fails because there is a rogue 'c' in the command. Probably it would be better to use the latest version (1.7) as the example anyway. Or is there a way of asking for the latest released version? I understand this checks out the whole Git repository with all history - I can't imagine why I'd need to do this to build a particular version. But David assures me it's very sensible. Sec 6: This worked, but it wasn't very clear what the purpose of the 'List existing databases' step was. Sec 8: So now I had to try to get Solr working using the instructions at http://docs.ckan.org/en/ckan-1.7/solr-setup.html This didn't work at all, in ways I can't now remember, to do with Java. In the end David suggested using Tomcat rather than Jetty (don't ask me what these do, but they have something to do with getting Solr to work ...) and this turned out to be much more straightforward to install and get working, with two caveats (below). David suggested maybe Tomcat should be the default suggested in this doc. - One problem with Jetty was to do with using the wrong version of Java, which seemed to be fixed using "sudo update-alternatives --config java". It didn't fix Jetty - not sure if it would also have been needed with Tomcat. - Soft linking the schema file didn't work - it seems Tomcat doesn't like soft links. We made a copy. After this everything worked, and I now have my very own CKAN. Hurrah! Mark
#1124 1304601771000000 nils.toedtmann I installed the python-ckanext-solr package rom http://apt-alpha.ckan.org/datanl-dev onto us10/DataGM too, and it seems to work just fine, see http://datagm.test.ckan.net/package?q=manchester
#200 1311176118000000 thejimmyg I know this is for datapkg but it is over 6 months old so closing in line with our current ticketing policy.
#2890 1346175867000000 rgrp I know this is tricky. The issue is that Datastore does not exist *just* to provided data views - it also provides a bunch of other stuff like a Data API and, well, a Datastore. I also think there are different audiences. Data view info is about publishers and (viewing) users, while the Data API is for (non-CKAN) devs and CKAN devs and the Datastore sysadmin section is for deployers. My feeling is therefore keeping things as is but with more stuff in the Data View seciton about it all works: * Data viewer: explanation for publisher, links to next 2 sections * Datastore page (as we have it) * Includes datastorer * Using Data API page (as we have it) So main change is a better data viewer page ...
#816 1312212782000000 dread I like rgrp's idea to change the model. But since it's complicated it would be good to have a UI. e.g. You might make format field simply a drop-down with only some common options: 'CSV, Excel, Zip, Other'. If you go for Other, then a more substantial UI appears, to cover more filetypes, APIs, services and a text box for Other. And if you select 'Zip' then another set of options appears to say what is in the zip. etc.etc. Another approach would be to have a background process downloading the data file and filling this in for you.
#2749 1343232304000000 toby I like the block page_title approach but not too fussed as long as this instance is working
#2630 1343392411000000 seanh I made another ticket (#2771) to encompass this and related work, closing this one as dup
#1050 1300458454000000 dread I may misunderstand how you intend to build the WUI Admin interface, but I think most of the stuff in authztool is just marshalling command line parameters anyway. The bits which do anything are factored out. For example, to list rights you just loop over obj_classes to call {{{model.Session.query(obj_class).all()}}} and then display the values: {{{type(subj).__name__, subj.name, role, type(obj).__name__, obj.name}}}. To change a right you simply call {{{model.add_user_to_role(subj, role, obj)}}} or {{{model.add_authorization_group_to_role(subj, role, obj)}}}. But of course if there is useful stuff to factor out then be my guest!
#868 1292921456000000 sebbacon I mean #876, of course.
#1435 1323168783000000 thejimmyg I personally can't see the benefit of switching to a generic paid service when we already have a highly customised and working infrastructure based on buildbot and buildkit - we do testing in VMs as well as continuous integration. What is the advantage? Suggest wont fix?
#1695 1327323309000000 dread I propose spending 2h on this.
#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?
#191 1323973116000000 dread I put the sort syntax example in the apiv3.rst table and moved the full curl example to http://wiki.ckan.org/Searching_CKAN I added tests for metadata_modified and prepared this branch for closure. Changeset: [origin/defect-191-modification-date bebf7a5] John, please review and close/merge if you think it is all ok.
#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
#2302 1343596669000000 shevski I reckon getting this live, esp with a easy to fill styled text header (see Sam's design) and a UI for changing About page text, featured dataset on homepage and welcome text is key
#1549 1324037471000000 dread I see a need for short links to any package or resource, so people can Twitter about them. As far as providing forwarding to a resource URL, even if that changes, then I'm not sure there is a need for it to be short - we could just use a long link with the resource-id. e.g. thedatahub.org/resource/c1e89abb-13cd-4e18-9078-03d15bf6f256/url-forward.
#698 1291742752000000 Stiivi I see two possible options: Option A: store only mirrors of source files, have file format based plugins for querying files Option B: store mirrors of source files, have plugin based loading scripts into "common structured format", have single query module. I would go with option B as it is: - easier to implement - file format based transformations are simpler than file format based queries - more transparent data management process - only one simple query module (see attached ckan-srcmirror.png) The Option B will fit better to the broader data architecture context: http://democracyfarm.org/f/ckan/data_arch.png Concerning API I would suggest to try to be compatible with google spreadsheet API: http://code.google.com/apis/spreadsheets/data/3.0/reference.html
#1456 1320930770000000 dread I see you've done this in cset:939e0e0809c1. Close now? BTW Take a look at the first suggestion from #1423 too, whilst in the area.
#76 1250175782000000 dread I spent 30 hours on this task.
#2265 1332865837000000 dread I started work on this and need to park it somewhere - here will do for now. I was using the 'MLT Component' http://wiki.apache.org/solr/MoreLikeThis : https://gist.github.com/2217684 But I think it would make more sense to use the 'MLT Handler' http://wiki.apache.org/solr/MoreLikeThisHandler which needs enabling by adding this to the config {{{/usr/share/solr/core1/conf/solrconfig.xml}}}: {{{ <requestHandler name="/mlt" class="solr.MoreLikeThisHandler"> </requestHandler> }}}
#446 1282423615000000 johnbywater I think "an admin writes to the CKAN API" is a mishearing.
#560 1285430085000000 [email protected] I think I'm seeing a variation on this behavior: I'm retrieving the packages in the lodcloud group (http://ckan.net/api/rest/group/lodcloud) and finding bibbase, and then fetching the package details (http://ckan.net/api/rest/package/bibbase) and getting a 403 Access Denied. If access to the package isn't available I would think it wouldn't be listed in the lodcloud group response.
#1044 1301304871000000 dread I think all that remains for this ticket is to add a paragraph to the authz documentation about SITE_READ. Pudo would you mind doing this? It's well worth noting where it applies and where it doesn't.
#277 1296470458000000 kindly I think generally this is a bad idea. I think in a few controlled circumstances some configuration is worth changing at runtime, however looking through the development.ini file I do not see hardly anything in there that does not require a restart anyway. It would be good to have some clear examples of things that would be in the extension.
#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?
#2852 1345103634000000 toby I think it should stay red but you can argue
#2785 1344243731000000 shevski I think it's a nice to have, esp if we give it an intuitive UI Rufus is keen for this also
#2681 1342512160000000 shevski I think just a file format, but want other perspectives. What do you think? & David: what do you think?
#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.
#2366 1336555441000000 ross I think the UI aspects have been removed in 1.7 with hopefully the rest of it going in 1.8 - assuming we have a clean migration script.
#1579 1338212496000000 ross I think the new datastore solves this.
#2669 1343597264000000 shevski I think they should be slightly greyed out. More importantly they should be hidden to everyone not a member of ownership group
#2601 1340723256000000 seanh I think this happens whenever you try to edit a dataset that has no organization
#1334 1319798961000000 dread I think this has been a problem since 1.3.3. Fixed in v1.5.
#269 1288036269000000 rgrp I think this has been long obsoleted by other work (e.g. more recent work on gov form).
#1553 1326288657000000 ross I think this is caused by the javascript xhr call getting redirected (quietly) to the login page, so the original javascript can't complete as it has a login form rather than the auth form it is looking for. Maybe we should change the JS to realise that it is at the login page and do something different than pretend to still be uploading?
#125 1257535181000000 rgrp I think this is done :) -- dread do you want to close this with linked cset?
#1373 1319542883000000 dread I think this is due to the etags cache not taking into account whether you are logged in. So the page is cached by squid (which is why it's not seen anywhere apart from thedatahub.org).
#277 1296340723000000 rgrp I think this is useful but there may be complexities giving the non-reloading nature of python apps. Have also converted to an extension
#2644 1344255836000000 shevski I think this requires some thought & probably a discussion. For example need to be clear on the purpose of a user dashboard vs say a publisher dashboard. I image a publisher dashboard would have the stats to datasets belonging to that group (e.g. views, downloads, comments, shares, ratings), issues reported (when we get that extension working), call to action to add a new dataset (that adds it to the group). User dashboards I'm less clear about. May be we can talk about this on Tues/Wed? Or skype today
#2698 1343378378000000 toby I think this would be really helpful/nice
#2619 1351531137000000 seanh I think we need a function that filters out all activities and activity details where the user doesn't have permission to read either the subject or object of the activity or any of its activity details. Each of the *_activity_list() functions can then use it.
#794 1300877517000000 thejimmyg I think we need to look at this again in relation to scotland.
#2550 1341833460000000 ross I think you've nailed the user stories already, but have added them to Description to be explicit.
#1400 1331543941000000 johnglover I thought that we had some sort of consensus that the official docs were aimed more at system admins and people using the CKAN WUI/API, with the wiki aimed more at developers? It would be easy to move of course, but there is no real "developers" section in the official docs that I can see, and it's even called "CKAN's Administration Guide".
#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.
#2751 1344240974000000 aron.carroll I tried {{{paster trans mangler -c datahub.ini}} I also had to {{{ pip install polib }}} and run {{{ python setup.py egg_inf }}} I find it hard to believe out coverage is that poor, I've just been through a random selection of templates and they all have appropriate calls to {{{_()}} or {{{ {% trans %} }}}. Will look once I get this running.
#1724 1328634433000000 johnglover I updated tag_list: https://github.com/okfn/ckan/commit/335535b646adf983d1d19bf19613712099db1f5e
#1489 1322138014000000 dread I updated the theme stuff in a75ca84. I've asked Ian to see if he can replace the form stuff with a new form (v. quick simple!).
#826 1297415095000000 pudo I want to strongly support david in his call for fully flexible extras: one of my use cases for them is to store the various bits of fallout from an archiving process, such as: * last-status * last-crawled * last-etag * last-expires * last-md5 * failure-count * fall-back-url These are things needed to really archive the data well, but they have nothing to do with CKAN core ops. Essentially, the archiver is a seperate concern and it need not appear in the CKAN config.
#948 1300271009000000 sebbacon I would propose a "trash can" model: a "deleted items" area where only deleted items can be viewed / searched. Deleted items should not appear anywhere else, but we could include a "also search deleted items" option in the search for admins. (In which case, deleted items should have a "div class='deleted'" or similar so they can be highlighted with CSS).
#2255 1332752936000000 rgrp I would say Public is default for Organization with Private being an option (or do we make this a config option?). What about ownership by users? > New datasets can be created from the organization form, in which case the organization will be set in the dataset form dropdown (with privacy set to private - see below) Does this mean like the setup on groups on the datahub (i.e. forward to new dataset but with some things hard-coded, organization/group?)? Or does it mean actual new dataset form on organization page.
#2785 1344256089000000 shevski I would say leave as phase 4 for now
#2204 1334218735000000 ross I'd be happier adding this to another ticket rather than moving the target for this ticket half way through so have created #2284 Should only be a short ticket in the next sprint.
#2256 1333620795000000 toby I'd like to remove all 'custom' icons and just use bootstrap ones - is this reasonable? they are added in different ways but h.icon() could be easily adapted for this. minimal .sj .css files
#2836 1344859911000000 toby I'd quite like some general css like this <span class="hover-for-help">[thing to hover over] <div class="help-text">Help text</div> </span> This is for the qa extension but seems like a general need .hover-for-help .help-text{ display:none; } .hover-for-help:hover .help-text{ display:block; position:absolute; padding:3px; }
#1654 1330863104000000 rgrp I'd vote -1 on SPARQL endpoint and doing the simple version of #1649 as proposed in my comment http://trac.ckan.org/ticket/1649#comment:2
#1123 1307374691000000 dread I'll change the architecture to "all" as per this article: http://linuxreviews.org/man/deb-control/
#442 1294661028000000 dread I'll close this now. Only thing to note is the importer code pudo wrote in ckanclient that could usefully be merged with the ckanext importer code.
#1804 1330000705000000 dread I'll fix this on release-v1.6 and then reassign to Toby to fix on feature-1653-i18n_url_rewriting too if the same issue crops up there.
#1400 1331544816000000 johnglover I'll have a look thanks. I'm +1 on using main docs instead (if we move everything), I was just trying to keep things consistent for now.
#954 1300217106000000 thejimmyg I'll look at this for a v3 API with kindly as part of the dictization. It also addresses some potential XSS issues in the API we've discovered.
#1329 1317118323000000 dread I'll take a look to see if I can do any more and then will close it.
#1246 1311885360000000 pudo I'm afraid to say I don't understand any of this: the faulty display of openness is triggered as removing the brackets turns the isopen() check into a check for the existence of the method. Reverting the changes on the server seems to work without generating exceptions. What exactly is the issue that was supposed to be fixed originally?
#2580 1342092353000000 toby I'm closing this as now you need to add at least one resource
#957 1314218701000000 rgrp I'm closing this as wontfix as we now have arbitrary metadata for resources so probably won't need a specific field. That said we probably will want a schema but that is not yet finalized and would be a separate and wider ticket. For current proposal of the attributes generally wanted for resources see http://wiki.ckan.net/Domain_Model/Resource (recently updated).
#2562 1352206599000000 johnmartin I'm closing this because I can't get context on this.
#2398 1337963342000000 seanh I'm closing this because we've got a whole bunch of tickets from the dev meetup about fixing the dependencies and requirements file that should deal with this problem
#2559 1342084940000000 toby I'm closing this now we can open tickets for bugs when we qa the add dataset
#929 1299840884000000 rgrp I'm closing this ticket as a) most systems should install the licenses package (and hence have the licenses locally) and b) licenses service has now moved to s3 so should be very robust (see ticket:973 and http://knowledgeforge.net/okfn/tasks/ticket/605)
#2256 1336046098000000 toby I'm closing this ticket now ckanext-datahub exists and is live - the other work is included in other tickets
#1412 1328226385000000 rgrp I'm completely unable to reproduce this issue in either FF (9.0.1) or Chrome 16.0.912.75.
#1387 1318429228000000 dread I'm generally against validation. When doing any bulk import, it either have to ignore validation errors or lose data. If you ignore the errors, you find you can't edit the dataset without correcting the validation error, and you often end up guessing, just to get your other changes in. All in all, I think it is better to nudge users, with javascript pop-ups in the form, or quality scores, rather than hard-and-fast validation.
#2514 1340959630000000 ross I'm going to close this as it is not safely in Aron's hands for the new demo theme.
← 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 →
Note: See TracReports for help on using and creating reports.