{23} Trac comments (3729 matches)

Results (1001 - 1100 of 3729)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Ticket Posixtime Author Newvalue
#650 1286789277000000 johnbywater Moved from sprint 1.2.7
#650 1287391932000000 pudo included since cset:781ef73e61cc
#651 1311169144000000 thejimmyg This has been open for more than 6 months so closing it. It may even have been fixed in John's auth refactor.
#651 1311171097000000 dread Yes, John fixed this. Changing to fixed.
#652 1284998201000000 pudo Fixed in cset: 688cbd25b3f0 (ckan-authz2)
#655 1285252726000000 johnbywater Referencing ticket #654 has changed sprint.
#656 1285252726000000 johnbywater Referencing ticket #654 has changed sprint.
#657 1285252726000000 johnbywater Referencing ticket #654 has changed sprint.
#658 1285252726000000 johnbywater Referencing ticket #655 has changed sprint.
#659 1298379892000000 dread Smoketest scripts exist for exactly this in ckanext. It would be great to have this running on nagios. It is as simple as running: python blackbox/smoke.py -H ckan.net blackbox/ckan.net.profile.json See here for code: https://bitbucket.org/okfn/ckanext/src/default/blackbox
#659 1298424109000000 nils.toedtmann Good idea. Listed this in my nagios ticket http://knowledgeforge.net/okfn/tasks/ticket/600
#659 1311183031000000 thejimmyg Since there is already an implementation and already exists as a ticket in the OKFN tasks, I'm marking this as closed. If there is a reason this is still open, please add it to a more appropriate ticket, such as the API version 3 one.
#660 1311183115000000 thejimmyg This ticket is more than 6 months old so closing it in line with our ticketing policy.
#661 1288271266000000 dread Friedrich has done the main meat of this in ckanext/blackbox/smoke.py I've extended it to include http basic auth, testing wanted error statuses, checking API calls etc.
#662 1286991079000000 dread I agree we should not have the 'read-only' things like Ratings in the default returned Package Entity. What do you think of having a parameter to be able to get these if you want them though? Do you mean you *can* re-post the *entity* post response? Not sure what you mean by "An issue for CKAN too."? In addition to this ticket, what do you think about changing the behaviour of the Package Entity PUT/POST, so that you replace the entire Package, not just the fields you specify? So you don't keep left-over values, just because you didn't specify them as null?
#662 1286993727000000 johnbywater It might be natural for the locator of the rating for a package to be "/package/{id}/rating". I've got not idea what I meant by "An issue for CKAN too." I may have intended to log this againt ckanclient. Anyway, it seems to be just a CKAN thing. :-) I think I would like to do this: $data = c.package_register_post({'name': 'example'}) $data['title'] = 'Example' c.package_entity_put($data['id'], $data) and this: $data = c.package_entity_get('example') $data['title'] = 'Example' c.package_entity_put($data['id'], $data) I don't think either work. We could write a test for each. I think this does work: $data = c.package_entity_get('example') $data = c.package_entity_put($data['id'], $data) $data['title'] = 'Old Example' c.package_entity_put($data['id'], $data) Which is inconsistent. The reason is that the data returned by the update operation ("entity put") isn't given the same treatment as the read and create operations, which adds various read-only values. That's as far as I got. I inferred that one or several of the read-only values, when present in the update request data, cause the update to fail. I'm not sure how it fails. Rather than cutting down the response data, we could make the update call more robust. One fix would pick out from the request package data only the attributes that are permitted. A alternative fix would make what ever is choking on the extra values ignore them. I mean, ids are read-only, but we wouldn't want to reject an update because it has an id in the data. We do need to be careful about loading up the package entity data, but the 'id' is read-only and we aren't going to quible about that being present in the data of an update request (even if it doesn't match the referenced entity). I would rather not support "replace the entire package" with especial functionality and documentation. I think the model create/update/delete, where update is "set attributes" is sufficient, simple, and fairly optimal. To obliterate all registerd values without deleting, I would get the package entity data, loop over the keys and set the values to '', [] or {} depending on the type, and then PUT the entity. We could write a test for that.
#662 1288624137000000 wwaites Ran into this with RDF export (that then updates the CKAN package with LOD2-compatible extras from the results). Cannot use ckanclient.package_entity_put(ckanclient.package_entity_get("ckan")). Is this related to the modifications htat are showing up in the changelog with no apparent package (the package that should be appearing there is "ckan" itself)
#662 1288628902000000 dread Yes we all agree this needs fixing it. I'm tempted by John's 'permissive' suggestion of ignoring these 'read-only' values, but to avoid confusion we should except with a 400 error if the user has changed these values. Read only fields: 'id', 'relationships', 'ratings_average', 'ratings_count', 'ckan_url' Use cases for changes between GET package, PUT package: 1. package unchanged - 200 OK 2. user changes id, ckan_url, relationships, ratings_* expecting that value to change - 400 error. 3. just license changes (but not license_id) - 400 error 4. both license and license_id change in step - 200 OK Does that sound reasonable John and Will?
#662 1297344790000000 rgrp Now part of 'model/validation/forms' meta-ticket #961 so reassigning to Seb.
#662 1299755259000000 dread We want this fixed for CLG customer (DGU), so have put in a quick fix into branch 3.1.2 cset:0010a709edf0 (and merged to default) as a stopgap whilst new forms are on their way.
#662 1301076443000000 dread Bug: license_id field is assigned the value of the 'license' parameter.
#662 1301076463000000 dread license bug fixed in cset:00038ef33c45
#663 1294414953000000 thejimmyg This is still an issue. Who is best to look into it? Assigning to me for timebeing.
#663 1294660906000000 dread This is my domain, but I suggest you don't assign it to me until it becomes important.
#663 1298913603000000 kindly cset:76a77439ecd0
#664 1294413696000000 thejimmyg @pudo is this still valid?
#664 1300371645000000 kindly fixed cset:a5f4a49190e2
#665 1294247602000000 thejimmyg Duplicate of #884
#665 1297268097000000 thejimmyg The latest version of the DMS collection interface spec says that this should be a manual process. No work to be done.
#667 1285925476000000 dread This was done when caching was switched off for a few hours it seems. Still, it is worth investigating this.
#667 1294414834000000 thejimmyg This is something we'll shortly be looking into for DGU work anyway once we switch to the "thin" system so don't need a separate ticket for it here too. Also, the upgrade of SQLAlchmey and test performance improvements may also make this less of a problem now anyway. Marking wontfix.
#667 1297069121000000 rgrp Actually marking as wontfix!
#668 1294412060000000 thejimmyg Assigning this to myself but won't be looking at it any time soon, if anyone else wants to take it on I'd be very grateful.
#668 1311176649000000 thejimmyg This ticket is more than 6 months old so marking as invalid in line with our ticketing policy. The API v1 and 2 were completely re-written as part of the logic layer refactor so it is likely this issue is resolved anyway.
#669 1286789428000000 johnbywater Moved from sprint 1.2.7
#669 1287392123000000 johnbywater Moved from sprint 1.2.8
#669 1287776309000000 johnbywater Moved from sprint 1.2.9
#669 1288038146000000 johnbywater Moved from sprint 1.3.0
#669 1291715237000000 pudo Important sub-task: check in schema.xml from eu4 somewhere.
#670 1286789428000000 johnbywater Moved from sprint 1.2.7
#670 1287392123000000 johnbywater Moved from sprint 1.2.8
#670 1287776309000000 johnbywater Moved from sprint 1.2.9
#670 1288038146000000 johnbywater Moved from sprint 1.3.0
#671 1286789428000000 johnbywater Moved from sprint 1.2.7
#671 1287392123000000 johnbywater Moved from sprint 1.2.8
#671 1287776309000000 johnbywater Moved from sprint 1.2.9
#671 1288038146000000 johnbywater Moved from sprint 1.3.0
#672 1286789428000000 johnbywater Moved from sprint 1.2.7
#672 1287392123000000 johnbywater Moved from sprint 1.2.8
#672 1287776309000000 johnbywater Moved from sprint 1.2.9
#672 1288038146000000 johnbywater Moved from sprint 1.3.0
#672 1291715338000000 pudo This is fixed for Solr now, plus a decision not to support postgres facets has been made.
#673 1286786420000000 johnbywater Referencing ticket #568 has changed sprint.
#674 1286786419000000 johnbywater Referencing ticket #568 has changed sprint.
#675 1286786420000000 johnbywater Referencing ticket #568 has changed sprint.
#675 1287392122000000 johnbywater Referencing ticket #568 has changed sprint.
#675 1287776309000000 johnbywater Referencing ticket #568 has changed sprint.
#676 1294413641000000 thejimmyg There was discussion of this on the list a few months ago, was there a conclusion?
#676 1295869107000000 rgrp Closing as wontfix. For dev/sysadmin documentation people can follow the link in the CKAN footer to ckan.org where we are consolidating documentation.
#677 1286786420000000 johnbywater Moved from sprint 1.2.6
#677 1287392123000000 johnbywater Moved from sprint 1.2.8
#677 1287589651000000 dread Related to https://trac.dataco.coi.gov.uk/projects/datagov/ticket/645
#677 1287745278000000 dread Currently blocked, waiting for exact details of script.
#677 1287746221000000 johnbywater Just to say, in cases where something needs to be delivered by somebody else, it can be useful to create a separate task ticket (with undefined remaining time) to indicate what deliverable is being waited on, and in the sprint backlog to drag it above the ticket(s) that depend on the deliverable. That means we don't feel a need to factor unknowable waiting time into our own tasks. It also means impediments are more obviously displayed, so you don't lose track when waiting for a number of things. The two different objectives also well separated so there is no question that somebody is stuck and passing time on a task. I've done this a few times recently and it does help to keep things simple. :-)
#677 1287776309000000 johnbywater Moved from sprint 1.2.9
#677 1288038147000000 johnbywater Moved from sprint 1.3.0
#677 1292587315000000 dread Done a few weeks ago in dgu repo.
#678 1286786420000000 johnbywater Moved from sprint 1.2.6
#679 1286786420000000 johnbywater Moved from sprint 1.2.6
#679 1287392123000000 johnbywater Moved from sprint 1.2.8
#679 1287776309000000 johnbywater Moved from sprint 1.2.9
#679 1288038147000000 johnbywater Moved from sprint 1.3.0
#679 1292587426000000 dread James has started this, but still some things to add.
#679 1294166120000000 dread I added some extra bits in cset:1ca7ba29d409. Resource formats disagree between DGU and the FAQ - have sided with DGU for now as it's simpler. I think this ticket is complete now.
#681 1286786420000000 johnbywater Moved from sprint 1.2.6
#681 1287160548000000 dread Looks like integration with drupal is the problem here. I'm writing tests.
#681 1287392123000000 johnbywater Moved from sprint 1.2.8
#681 1287776309000000 johnbywater Moved from sprint 1.2.9
#681 1288036387000000 rgrp This has been fixed.
#681 1288036983000000 dread The code is fixed, but not yet deployed, which requires time.
#681 1290507180000000 dread <[email protected]> This has been deployed now.
#682 1286786420000000 johnbywater Moved from sprint 1.2.6
#682 1287392123000000 johnbywater Moved from sprint 1.2.8
#682 1287776309000000 johnbywater Moved from sprint 1.2.9
#682 1288038147000000 johnbywater Moved from sprint 1.3.0
#682 1297358266000000 dread Various improvements to ckanclient to enable this: cset:1bfefd7596d3 and cset:47fd07087547 and installed on buildbot now.
#683 1287142289000000 dread Done apart from ultrastable - not in use at moment.
#684 1286388346000000 dread Referencing ticket #683 has changed sprint.
#685 1286388345000000 dread Referencing ticket #683 has changed sprint.
#686 1286388346000000 dread Referencing ticket #683 has changed sprint.
#686 1287997047000000 dread Don't need this yet.
#689 1287392122000000 johnbywater Referencing ticket #572 has changed sprint.
#689 1287776309000000 johnbywater Referencing ticket #572 has changed sprint.
#690 1288013610000000 johnbywater This concern was resolved in favour of a converged set of attributes (#711).
#691 1294412765000000 thejimmyg This is more a long term idea, taking ownership for the timebeing but happy for someone else to take this on.
#691 1294412929000000 thejimmyg If we did implement this we'd need to link new sample package to previous sample package of continuous series. So closing #748.
#691 1294413010000000 thejimmyg We'd also fold up continuous series in search results behind newest sample package. So closing #749.
#691 1294413993000000 thejimmyg We'd also discuss package relationships ideas with JF so closing #444.
#691 1295610145000000 rgrp Most of package relationships was implemented in ticket:253 and its subtickets. Therefore closing this as duplicate.
#692 1294247841000000 thejimmyg CKAN doesn't need to implement this, Drupal does. Incidentally, the initial version is implemented on UAT anyway.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Note: See TracReports for help on using and creating reports.