{23} Trac comments (3729 matches)

Results (1501 - 1600 of 3729)

← 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 →
Ticket Posixtime Author Newvalue
#1021 1299518828000000 pudo fixed in cset:9f1b38add19f
#1025 1299598708000000 dread Done in enh-1025-config-default-authz and goes into release 1.3.2.
#1026 1299605128000000 dread Done in cset:2dde3bd563fd for branch 1.3.2
#1027 1299666326000000 pudo 1. home controller -> __before__ (check "site-read" on model.System) 2. user -> each individually (repoze-who pseudo action must not be blocked) * user-read (index/read/update pages for users) * user-create (register) 3. revision -> __before__ (check "site-read" on model.System) 4. tag -> site-read (__before__) functional/test_authz.py * denies site-read ... * checks for visitor / logged in user .. * checks you can still visit login
#1017 1299668555000000 pudo fixed in cset:86d49a775fd3
#1024 1299668648000000 pudo re-created this (#1027)
#1027 1299682082000000 pudo fixed in cset:532c3ad2743b
#1025 1299750097000000 rgrp (Link to changeset). Could you briefly clarify why this was needed in config -- we already have a process for putting things into a more restricted mode (see ticket:833) and have been working on creating a WUI to be able to do this automatically (see that ticket).
#1025 1299751045000000 dread Thanks for pointing this out. Although changing the definition of 'editor' to not allow edit (as you admit) is a bit hacky, and I think prone to confusion. James and I weren't aware there was a precedent for doing it this way, but if we had, we may well have followed it. I mentioned the branch for this cset, in preference to the csets.
#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.
#1028 1299760360000000 dread Fixed in cset 4d860a53fbad on 1.3.2 and merged to default.
#738 1299761436000000 thejimmyg This is now complete and on UAT.
#1015 1299788821000000 rgrp Today kindly applied the sql fixes and I can confirm this is now fixed. Well done kindly for all the great work here.
#904 1299840539000000 rgrp We're already now into improving the docs and ticket:927 is now reasonably detailed.
#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)
#927 1299841206000000 rgrp Major update including notes of what has been done (where not a separate ticket) and addition of a few items.
#913 1299841413000000 rgrp If at all possible this should uris from the OKF licenses registry at http://licenses.opendefinition.org/
#366 1299845116000000 dread I'm very pleased that this now works when you try to edit a package that is not allowed. Are there other circumstances we should cover or can we close this?
#366 1299845781000000 pudo You're right, that's done!
#1031 1299863222000000 rgrp Done, see cset:78d96b520679
#867 1299866685000000 rgrp This was a breaking change for loaders code. Obviously we don't have tests for that so would not have been noticed ... Fixed in cset:af81e54bd590/ckanclient
#810 1300093797000000 rgrp Moving back to backlog for v1.4 as should be dependent on forms overhaul and seems to be problematic (and not that urgent).
#1006 1300098217000000 dread Reassigning to rgrp for response
#1005 1300100085000000 dread Moved to dgu trac ticket 869
#1003 1300100411000000 rgrp Converted completely to backbone and now have fully-operational add dataset functionality. I'm closing this ticket now - further improvements can be in there own tickets.
#1030 1300103984000000 amercader This includes: * Take out all references to harvestsource, harvestingjob and harvesteddocument in the rest API * Move the harvesting bits of ckan/lib/cli.py into ckanext-harvest. * Move ckan/controller/harvesting.py and cknan/model/harvesting.py to ckanext-harvest as well * Update ckanext-csw to be able to find the code it needs in the new place.
#927 1300105638000000 rgrp Closing this ticket as #841 is minor. More work on docs can go in new tickets.
#1006 1300105927000000 rgrp Not sure when i described that other process but I'm definitely of the opinion that we should: * Deprecate and remove stable branch * Deprecate and remove metastable branch (going forward we can use release branches for what we did with metastable in the past) May want to update BranchingPolicy to reflect this (also should probably have some statement about closing release branches and tagging) Reassigning to David Raznick as he is our release guru now.
#1020 1300196215000000 thejimmyg This is now on DGU live.
#894 1300196388000000 thejimmyg All test CSWs have been successfully harvested from. CSW harvesting is disabled on that source so we can't harvest from it. I don't think we need a ticket for this now do we?
#887 1300196600000000 thejimmyg This is done. See https://bitbucket.org/okfn/ckanext-harvest At the moment we are not adding migrations to remove the harvesting tables. We are designing a harvesting refactor and will write migrations once the refactor is complete so that instances that use harvesting get upgraded, and those that don't get their harvesting tables removed. Also, see this #1030 for the moving harvesting out of the REST API.
#883 1300196622000000 thejimmyg Now complete.
#801 1300196714000000 thejimmyg This will now be solved as part of the larger harvesting refactor. See #921.
#921 1300197629000000 thejimmyg Seb started this, I completed it and the code is now live. Further refactoring will be done first in #1037 and then in #987.
#1030 1300209975000000 thejimmyg Also: * Delete harvest sources * Implement a Genshi template filter so that if there is an INSPIRE package_extra set to True, you can link to the XML and HTML generation API calls in ckanext-csw * Write tests in ckanext-dgu for all the API calls that Drupal is making
#366 1300212171000000 dread changeset d7a8df888f44
#1038 1300212841000000 dread Done in cset:0373737f0866 for release 1.3.2
#1039 1300212856000000 dread Done in cset:97d563bbf01d for release 1.3.2
#1040 1300213922000000 dread Fixed by James in 904f1f36a672 for 1.3.2
#957 1300216958000000 thejimmyg Let's come back to this later. There are larger UKLP refactors going on. Sorry to mess you around.
#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.
#920 1300217199000000 thejimmyg @David Should we implement this as a change to the way tags work or via a tidy up cron job?
#896 1300217375000000 thejimmyg Actually, I think this should be implemented instead by considering a different CKAN instance as a potential harvest source and then harvesting from it. By thinking of it this way in the first instance, we effectively get a read-only copy of other data in CKAN but one which will be kept up to date. Marking as duplicate. Discussion can now carry on via #987 Common harvesting framework.
#1012 1300217601000000 thejimmyg See also #103 which says: As a user I want to view a package at a given revision: * When I visit /package/read/xyz?rev=yyy I should be shown package at revision yyy * package history page should provide links to these pages Could you please investigate how doable this would be given the current package read.html page. I expect it could be very easy once the revision API is in place because we could build a c.pkg object from the revision data instead of the model data. Perhaps another case where we could try introducing the dictization?
#103 1300217647000000 thejimmyg See also #1012 Add package revision history to api
#371 1300217820000000 thejimmyg Marking as closed since http://knowledgeforge.net/okfn/tasks/ticket/600 now takes on this ticket. I will check nils has added the new DGU Bytemark servers are added to Nagios.
#972 1300219509000000 thejimmyg I don't really agree with this. In fact I'd rather move further away from auto-magic key value pairs stored in JsonTypes. Can we discuss on Skype please?
#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).
#948 1300271100000000 dread This sounds like a good solution to me. This should include not just packages, but groups and all other stateful objects.
#948 1300271268000000 dread There's also the API to consider. One edge case to consider too - currently we don't allow reuse of the name of a deleted package, which is confusing. The deleted package should be moved aside (renamed), unless the deleted package is entirely the same as the new or renamed package.
#480 1300281551000000 thejimmyg This is complete (albeit with a different architecture).
#1041 1300284809000000 thejimmyg Also, this means moving documentation out of the current CKAN dev wiki at trac.ckan.org and into the community wiki. Core developer docs should remain in the Sphinx-based .rst format in CKAN. Much-needed new tutorials go on the community wiki.
#941 1300295545000000 wwitzel3 https://bitbucket.org/okfn/ckanext-community/changeset/c26cc663fa00 I need to update the README to explain how to enable Edit and Delete now that I've integrated it with authorization in CKAN.
#920 1300319140000000 kindly The only issue here is that we are listing tags that relate to 'inactive' packages. We are already not listing tags that relate to NO packages. I have fixed this. cset:cd0347eed69f The tag in the example is related to a deleted package so should not be deleted. With this patch it no longer gets displayed.
#1043 1300321033000000 kindly cset:c894f92c5b9a Sesion.remove() needed to be run before configure as we want the original session made not to be used over the newly configured ones.
#1012 1300352334000000 kindly This is entirely not trivial at the moment. Hopefully after the dictization it will become more so. Simply putting in the package revision object in place of the package does not work. It will obviously work for changes to the package object itself. However, there are no mappers on that object for getting out the related package_tags, resources and extras at that revision. You will have to construct a fake pkg object with some messy and painful queries using dates.
#1044 1300359562000000 rgrp Think this would be resolved by refactoring implied in ticket:1001 (specifically checks for api key and remote user should lead to availability of same set of identification information).
#1012 1300362584000000 kindly cset:5649d6e761fc The basic revision history is merged. I will keep this ticket open if it is not sufficient. All it does is give a list with the most recent first of revision_ids, authors and timestamps. i.e {{{ [{"timestamp": "2011-03-16T15:55:19.941961", "author": "southampton-ac-uk", "revision": "202e9eb8-afaa-4bc9-b8a1-a317561547ea"}, {"timestamp": "2011-03-15T17:59:16.430804", "author": "southampton-ac-uk", "revision": "8235bd0a-d39a-49e0-887a-b0f231be8a92"}] }}}
#103 1300363180000000 thejimmyg Closing, we'll take this up in #1012.
#995 1300364316000000 thejimmyg Also, update the docs: Documentation article on caching / improving performance. (To complement configuration docs.) * Different sorts of cache - beaker style, etags, package_dict in search results(?) * How each one affects performance * How to turn them on/off and configure them * Is it possible to bypass each of them in the browser or with wget/curl? Therefore closing #841.
#841 1300364333000000 thejimmyg See #995
#996 1300364398000000 thejimmyg This is now fixed, the outcome will be used to inform #995 for the caching.
#1012 1300364620000000 thejimmyg The API part is now done. Bumping the view history part to 1.5
#1001 1300367555000000 thejimmyg Yes, I think the two should be consolidated, but as was noted elsewhere (I think) we don't want the API to ever be authenticated via a cookie, otherwise we open ourselves to CSRF attacks. Instead we could support the API key as a query parameter as an alternative to via the HTTP header if it is hard to set an HTTP header in JS libraries?
#1012 1300368449000000 dread As I understand it, the whole point to vdm is to make it easy to get old versions of not only the package, but its related objects (like tags, extras). David take a look at this function: Package.get_as_of(revision)
#664 1300371645000000 kindly fixed cset:a5f4a49190e2
#1006 1300372286000000 thejimmyg I'm updating the branching policy now. David has closed stable and closed metastable. Marking as fixed.
#1032 1300380606000000 rgrp This is urgent for me as without upload does not really function.
#1044 1300382367000000 dread I agree with leaving #1001 solving this issue. Centralising this is good. This ticket can instead focus on: * returning the correct 403 error (rather than the 302 currently) * creating some tests * documenting * consider renaming the SITE_READ variable and rethinking purpose
#948 1300385979000000 sebbacon Emptying the trashcan (which would amount to purging deleted objects) would probably be a function of the administrative dashboard #833
#954 1300447466000000 thejimmyg What would also be really nice is a `help` key in the response which was always returned unless a query parameter of `?help=False` was sent. The help text could explain what the response meant but more importantly would show examples of other calls you can make with the IDs returned such that the whole API is discoverable without anyone ever needing to read any docs! It also means the API documentation is more likely to be up to date since it will be obvious to developers when it isn't. With help=False, the JSON can have all whitespace stripped too for production use. I also think there should be no distinction between GET and POST so that people can easily link to API calls if they want to.
#1044 1300449905000000 dread I've added in tests for SITE_READ and corrected the 403 response - see branch bug-1044-site-read. The tests have uncovered some inconsistencies in the use of SITE_READ between reading/editing a package in the Web interface vs the REST API. Friedrich, do you want to take a look at ckan/tests/functional/test_authz.py:TestSiteRead.test_pkggroupadmin_read for details and have a think about how this should best work. How about making SITE_READ more widespread in the WUI, to protect read/editing/searching things, in addition to the READ and EDIT RoleActions. Once that is decided, it should be pretty easy to refer to the tests and document SITE_READ.
#1050 1300452200000000 johnlawrenceaspden there's already a file ckan/tests/test_authz.py, which looks like the appropriate place for new tests.
#1045 1300457708000000 dread Fixed in cset:98eb8b8d063e on default, scheduled for CKAN version 1.4.
#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!
#1001 1300625888000000 pudo My vote on this would be to enable "httpbasic" auth via repoze.who and to add an API key challenger to ckan/lib/authenticator.py that accepts API keys, from within repoze.who. This way we won't have to work around the framework at all and can retain compatibility to the existing mechanisms.
#1044 1300627007000000 pudo David, thanks for writing those tests - perhaps we should combine them with the ones below ("TestLockedDownUsage") which attempt to basically do the same. As for the inconsistency introduced by the global check in the REST API you're right: Of course it is strange that WUI access checks are more granular than the API checks. The alternative is that we either move authz checks into all relevant REST places (a major refactoring I would be suspicious of) or that we introduce duplicate checks on the WUI actions (I actually have performance concerns about that, authz is incredibly slow - and it introduces another level of special authz that I think we really should not have). Given the choice I'd opt for the REST refactor - there is no good reason to make SITE_READ a duplicate check where authz already applies. On the other hand, this is a function we really don't want to enable or even have and that was only added to satisfy some very specific user demands. Given that these are fulfilled, I'm actually OK keeping the inconsistency for now - nobody will see it in normal operations and in a locked-down environment, users will need to have API keys anyway. Regarding the naming, I'm pretty opionion-less: SITE_READ was proposed by rgrp and I think its pretty fitting, while OTHER_READ would just confuse me. PUBLIC_READ might work, though.
#1048 1300702752000000 dread Done in changeset 9d7bfa124757 on default and expect it to go into 1.4 release.
#1001 1300703779000000 rgrp First work in cset:6b8cbe465b61
#1001 1300704249000000 pudo Wrote a WDMMG version of this yesterday: https://bitbucket.org/okfn/wdmmg/changeset/398ce0eb3901#chg-wdmmg/lib/authenticator.py
#999 1300707328000000 rgrp Done. See https://bitbucket.org/okfn/ckan-ckan.net and updated ckan.net.ini.
#1044 1300712223000000 dread I'm happy to leave the inconsistencies in SITE_READ for now, since this will be resolved when authz is centralised between WUI and API in the dictization refactor. I'm also happy to leave both TestSiteRead and TestLockedDownUsage as they complement each other nicely actually. So 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.
#948 1300728602000000 dread We have a use case now for DGU where if a user requests a deleted package, he is 302 redirected to another package (specified in the deleted package's extras). This is for the API, but could also be done in the Web UI if deleted packages are hidden away in a trashcan. But this suggests we need a trashcan in the API too. i.e we should keep the data model really synchronised between the Web UI and API, (even if they are becoming divorced from the ORM Model - or maybe we should have a trashcan in the ORM model too?) Ideas: * GET api/rest/package - lists active packages * GET api/rest/package/traffic_data - active package * GET api/rest/trash/package - lists deleted packages * GET api/rest/trash/traffic_data_old - deleted package
#1045 1300787161000000 dread Want to identify groups by ID also in the Web interface.
#1045 1300793261000000 dread Fixed in cset:71621df50983 on default ready for ckan 1.4
#794 1300877517000000 thejimmyg I think we need to look at this again in relation to scotland.
#1052 1300895410000000 dread Fixed in branch feature-DGU#889-authorization-in-lockdown and merged to default at cset:e6643cf1324c. Only remaining issue is listing in Web interface of package relationships, which shows links to packages even to ones you can't read.
#1042 1300969265000000 dread Done in ckanext cset:7610512277bd and ckanext-importlib cset:7737716e0d7b.
#1042 1300969865000000 dread Remaining parts of ckanext are: * blackbox (rgrp, pudo, dread) * hammer (ww) * link_checker (ww) * solr configuration (pudo) & indexer (pudo) * amqp listener command (ww) * geo form field (rgrp) * GData Loaders: * aidprojdata (johnbywater) * norwaygovdata (johnbywater) * ordsurv (johnbywater) * Gemini2 (iso19139) (johnbywater, ww)
#1055 1300987241000000 dread This amounted to 14 tests. Fixed in cset:5bbd0005c57e ready for ckan release 1.4.
#1054 1300989764000000 dread I've added some tests in the branch: defect-1054-resource-order
#1054 1300992195000000 dread I've put in a potential fix for this into the branch - do take a look and see what you think.
#1054 1301002995000000 kindly Looks great. Had a look and changed a minor thing because I was not confident with the handling of the null values. I made a fake resource and did an asdict on that to make the identity. Part of my patch I reverted as I mucked up my version of the vdm, so it was not needed.
#662 1301076443000000 dread Bug: license_id field is assigned the value of the 'license' parameter.
#662 1301076463000000 dread license bug fixed in cset:00038ef33c45
#1001 1301229082000000 rgrp Completed and merged into default in cset:cb200f339dbb. At the moment have done the very simple option but pudo's approach seems better and we could refactor towards that going forward.
#1058 1301303221000000 dread Fixed in cset:8e1817ab8d1c on default, ready for 1.4 release.
#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.
#1051 1301305079000000 sebbacon This has been completed in https://bitbucket.org/okfn/ckan/changeset/64a949990e0b
#1054 1301305615000000 dread This branch is now merged.
← 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 →
Note: See TracReports for help on using and creating reports.