{23} Trac comments (3729 matches)

Results (2101 - 2200 of 3729)

← 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 →
Ticket Posixtime Author Newvalue
#1067 1302186503000000 dread Done in cset:d75ab5fc3311 for release 1.3.3
#1073 1302185825000000 dread Done in cset:9dfc60db90ed on default branch.
#1068 1302109505000000 dread The problem was the use of mktime which is localised. Also spotted a problem with the use of localised time stored in the datestamp created in migration script 29, when initialising the repo. Fixed in a2094932e5e4 in release 1.3.3 branch.
#1072 1302106474000000 dread Done in cset:2a97d2d9ba4a for release 1.3.3.
#1044 1302096155000000 dread I've added in the docs for this in cset:013da53052d1 ready for release 1.3.3.
#1065 1302081747000000 dread Great stuff Seb, cheers for that.
#1065 1302075994000000 sebbacon Re the point against my name, yes -- I think the fundamental principles of the current system are fine, but the implementation means asserting things for every single object, whereas we should be able to optimise it for the general cases -- something along the lines you suggest. I would be very happy to write up a full, detailed proposal for the system before we implement anything, if only as a proper straw man to have debates around.
#1065 1302033244000000 dread Wow, lots of solutions here, and not enough evidence of the problems encountered / difficult use cases. I have tried here to extract what John and Seb might be suggesting is difficult with our current http://en.wikipedia.org/wiki/Role-based_access_control system. 1. (Seb) It seems crazy to change the User-Object-Roles for every single package to 'lockdown' a CKAN instance. Instead of using Roles 'reader' & 'editor' we start using Roles 'logged_in_user' and 'anon_user'. Then, with only changing a couple of lines of the Role-Action table for these Roles, you can give or remove permissions to edit / create packages, groups etc. 2. (John) Actions are being added all the time by migrations and extensions. I'm not sure what the problem is here - can someone explain? The separation of Users and the new Actions by adding the Role 'join' means the migration/extension can add existing Users with the new Actions. For example when we added the 'Group' protection object, logged in users could previously create groups, so it is natural to add this action to the 'editor' role. If you get rid of Roles, as John suggests, then you end up having to add as many Rights objects as users. And you might end up trying to infer new Rights on the basis of old Rights, rather than a role, which would be more natural. (Is the only reason to denormalise the UOR and RA tables the sake of ease of understanding? I would think we can explain the concept better now...!) 3. (John) This Group Hierarchy description sounds a bit like earlier incarnations of the DGU requirements. "or any of his groups group-children (but not user-children)" I'm not sure I understand the user-children bit, and I'm wary of any difficult-to-grasp concept. This modelling seems to take the UserGroup/User hierarchy model and use that as a hard-coded interpretation of the Authorized permission. In contrast, in DGU Evan split the Organisation Hierarchy model from the Authorization model. Each User has explicit permissions for each Organisation he is allowed to add/edit packages for. This helps for these two use cases we have to contend with: when a user is an admin for unrelated branches of the Organisation hierarchy, and when an Organisation is actually in two branches of the Organisation hierarchy. It also seems more generally flexible.
#1071 1301943180000000 dread Done in cset:db9e2c4f65bb for release-v1.3.3
#103 1301943140000000 dread Didn't take this up in #1012 after all. Closing as wont fix.
#1012 1301943096000000 dread Changing this to 'Fixed' and #103 to 'Wont fix' to ensure this feature is noted.
#1066 1301932136000000 dread Done on branch defect-1066-reader-too-permissive and merged into release-1.3.3
#1066 1301930311000000 dread Migrations: * Default (open) CKAN instances will have visitor as a reader on the system, and will have to upgrade them to anon_editor. * DGU & DataGM instances have visitor as a reader on system and must stay like that. * Pudo's specially locked instance, where editor has been changed to only read can now use the 'reader' role (assuming he's happy for them to create users) Migration script (37) is designed to cope with the default (open) setup, and the other special cases must be dealt with using CLI at the time of upgrade: DGU & DataGM must run: {{{ paster rights remove visitor anon_editor system: paster rights make visitor reader system: }}}
#1061 1301922350000000 dread Backed out original change fc3bc103db8c here: 7ae9aff8bc68
#1061 1301922325000000 dread Actually there was a link at the bottom of the package edit form that my grep didn't pick up: h.url_for(str('/license')). So it is not orphaned at all.
#1065 1301914004000000 sebbacon To reflect further conversations: * We are parking this ticket until dictization is complete * We would prefer to see roles as asserted globally by default, with packages just storing exceptions. E.g. If I am a "reader" globally, then I have "read-package" permission on all packages new and existing, unless otherwise asserted locally on a package. * Also w.r.t. algorithm above, consider repoze.what's model; "possible" is analagous to "has_permission". See http://what.repoze.org/docs/1.0/Manual/Predicates/Builtin.html
#1012 1301909937000000 thejimmyg No-one really seems to have requested this part.
#941 1301909446000000 thejimmyg See also discussion on #1069 about stub datasets.
#1069 1301909423000000 thejimmyg This is what the new "Ideas" section in the ckanext-community extension is for. Marking as duplicate of #941, can we have discussion there please.
#945 1301909147000000 dread Moving super ticket to 1.4 milestone
#1066 1301904246000000 dread Need a new role 'ANON_EDITOR' which is the default role for Visitor, which can create packages, but not groups.
#1063 1301522483000000 rgrp This sounds absolutely sensible and suggest we even have a helper method such as lib.helpers.group_link(group) (as we do for user_link). (@Seb: apologies for misunderstanding your query on the list -- I was talking about the group listing table at /group)
#1061 1301397271000000 dread Fixed in cset:fc3bc103db8c ready for release 1.3.3
#962 1301364987000000 rgrp Closing as have now reworked to: * Support plain text previews for many formats (including xml based formats) * Try to handle everything else as html with an iframe ... * Do not show preview button where not useful * Normalize formats for better recognition (e.g. text/csv, application/xls) See: https://bitbucket.org/okfn/ckanext-datapreview/changeset/c1d672a6c368 and previous. Also re-updated the dataproxy so it works again (had got out of sync when mistakenly reverted the dataproxy a couple of weeks ago). Could still do api/sparql (using sparql js wrapper) and handle json (as plain text ...?) but these can be new tickets.
#1059 1301312516000000 dread Fixed in ckanext-importlib cset:f6d19129ac43.
#1060 1301312487000000 dread Fixed in ckan-importlib cset:bc52bba86d71 and ckan cset:2751f76fb17a in time for ckan 1.4
#1029 1301311643000000 thejimmyg This was fixed by kindly as part of the 1.3.2 release.
#1001 1301310351000000 rgrp This ticket did not include CSRF matters - please raise in a separate ticket if you wish. I looked in some detail at the testing options and nothing seemed simple to do that didn't duplicate code we already have (since no way to access the base controller halfway through a request). This can be tested as necessary as part of the development of the new js work.
#1001 1301307814000000 dread You mentioned writing tests? Also the CSRF question from James hasn't been addressed.
#1054 1301305615000000 dread This branch is now merged.
#1051 1301305079000000 sebbacon This has been completed in https://bitbucket.org/okfn/ckan/changeset/64a949990e0b
#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.
#1058 1301303221000000 dread Fixed in cset:8e1817ab8d1c on default, ready for 1.4 release.
#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.
#662 1301076463000000 dread license bug fixed in cset:00038ef33c45
#662 1301076443000000 dread Bug: license_id field is assigned the value of the 'license' parameter.
#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.
#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 1300989764000000 dread I've added some tests in the branch: defect-1054-resource-order
#1055 1300987241000000 dread This amounted to 14 tests. Fixed in cset:5bbd0005c57e ready for ckan release 1.4.
#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)
#1042 1300969265000000 dread Done in ckanext cset:7610512277bd and ckanext-importlib cset:7737716e0d7b.
#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.
#794 1300877517000000 thejimmyg I think we need to look at this again in relation to scotland.
#1045 1300793261000000 dread Fixed in cset:71621df50983 on default ready for ckan 1.4
#1045 1300787161000000 dread Want to identify groups by ID also in the Web interface.
#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
#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.
#999 1300707328000000 rgrp Done. See https://bitbucket.org/okfn/ckan-ckan.net and updated ckan.net.ini.
#1001 1300704249000000 pudo Wrote a WDMMG version of this yesterday: https://bitbucket.org/okfn/wdmmg/changeset/398ce0eb3901#chg-wdmmg/lib/authenticator.py
#1001 1300703779000000 rgrp First work in cset:6b8cbe465b61
#1048 1300702752000000 dread Done in changeset 9d7bfa124757 on default and expect it to go into 1.4 release.
#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.
#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.
#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!
#1045 1300457708000000 dread Fixed in cset:98eb8b8d063e on default, scheduled for CKAN version 1.4.
#1050 1300452200000000 johnlawrenceaspden there's already a file ckan/tests/test_authz.py, which looks like the appropriate place for new tests.
#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.
#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.
#948 1300385979000000 sebbacon Emptying the trashcan (which would amount to purging deleted objects) would probably be a function of the administrative dashboard #833
#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
#1032 1300380606000000 rgrp This is urgent for me as without upload does not really function.
#1006 1300372286000000 thejimmyg I'm updating the branching policy now. David has closed stable and closed metastable. Marking as fixed.
#664 1300371645000000 kindly fixed cset:a5f4a49190e2
#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)
#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 1300364620000000 thejimmyg The API part is now done. Bumping the view history part to 1.5
#996 1300364398000000 thejimmyg This is now fixed, the outcome will be used to inform #995 for the caching.
#841 1300364333000000 thejimmyg See #995
#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.
#103 1300363180000000 thejimmyg Closing, we'll take this up in #1012.
#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"}] }}}
#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 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.
#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.
#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.
#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.
#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.
#480 1300281551000000 thejimmyg This is complete (albeit with a different architecture).
#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.
#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 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).
#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?
#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.
#103 1300217647000000 thejimmyg See also #1012 Add package revision history to api
#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?
#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.
#920 1300217199000000 thejimmyg @David Should we implement this as a change to the way tags work or via a tidy up cron job?
#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.
#957 1300216958000000 thejimmyg Let's come back to this later. There are larger UKLP refactors going on. Sorry to mess you around.
#1040 1300213922000000 dread Fixed by James in 904f1f36a672 for 1.3.2
#1039 1300212856000000 dread Done in cset:97d563bbf01d for release 1.3.2
#1038 1300212841000000 dread Done in cset:0373737f0866 for release 1.3.2
#366 1300212171000000 dread changeset d7a8df888f44
#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
#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.
#801 1300196714000000 thejimmyg This will now be solved as part of the larger harvesting refactor. See #921.
#883 1300196622000000 thejimmyg Now complete.
#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.
#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?
← 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 →
Note: See TracReports for help on using and creating reports.