{23} Trac comments (3729 matches)

Results (1801 - 1900 of 3729)

← 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 →
Ticket Posixtime Author Newvalue
#1048 1300702752000000 dread Done in changeset 9d7bfa124757 on default and expect it to go into 1.4 release.
#1049 1323169424000000 thejimmyg This is over 6 months old. In accordance with wiki policy, closing.
#1050 1300452200000000 johnlawrenceaspden there's already a file ckan/tests/test_authz.py, which looks like the appropriate place for new tests.
#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!
#1050 1303118188000000 thejimmyg This should also feed into #1075 which will be being worked on this week.
#1050 1315394117000000 dread There's been no objections to my comment 6 months ago saying this is invalid, so marking it invalid. Feel free to reopen if there is indeed a case here.
#1051 1301305079000000 sebbacon This has been completed in https://bitbucket.org/okfn/ckan/changeset/64a949990e0b
#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.
#1053 1310125444000000 thejimmyg This is now fixed as part of the API refactor and revisioning updates David Raznick has done.
#1053 1310126546000000 dread Looks to me like DELETE always changed the state to Deleted, so an invalid ticket. We can deal with purging in another ticket if needed.
#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.
#1054 1301305615000000 dread This branch is now merged.
#1055 1300987241000000 dread This amounted to 14 tests. Fixed in cset:5bbd0005c57e ready for ckan release 1.4.
#1056 1302626373000000 dread Fixed in cset:a025b5b3293c on default.
#1056 1302882616000000 dread This was broken in cset:b681bbedfa62a68b71260ef48a0da6063109734 which was released in 1.3.2
#1057 1329150236000000 toby fixed in commit 3d7cbf0
#1058 1301303221000000 dread Fixed in cset:8e1817ab8d1c on default, ready for 1.4 release.
#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
#1061 1301397271000000 dread Fixed in cset:fc3bc103db8c ready for release 1.3.3
#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.
#1061 1301922350000000 dread Backed out original change fc3bc103db8c here: 7ae9aff8bc68
#1062 1311178145000000 thejimmyg Hi John, Can you please check that the new webstore+preview works correctly with this one please? Cheers, James
#1062 1311773731000000 johnglover The file is in Turtle format (serialisation format for RDF, which we currently don't archive and have no preview code for. The new preview code will not even create a preview button for this file type. Moving to the backlog for now, support for RDF and related formats should be added along with support for excel docs and google spreadsheets.
#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)
#1063 1302514033000000 sebbacon Fixed in https://bitbucket.org/okfn/ckan/changeset/145eaae3168a
#1064 1323169787000000 thejimmyg Marking as duplicate because #1464 will take it on.
#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
#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.
#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 1302081747000000 dread Great stuff Seb, cheers for that.
#1065 1303118756000000 thejimmyg This is now more urgent and I think we have enough consensus to go ahead. See #1094 too.
#1065 1311174208000000 thejimmyg Merging with #1094 so see the discussion there too.
#1065 1318528721000000 rgrp Reassigning to zephod as he is looking at this. I think most of this is wontfix or will become obsolete with other stuff but worth looking at. Also moving to v1.6 at the same time.
#1065 1324550041000000 dread All subtickets are done now, apart from #1198 which I've moved into superticket #1477 Group refactor Change name of AuthzGroup? to UserGroup? to reflect what it is for I think this is completely covered off in #1477 Group refactor Get rid of Roles, and replace them with direct assignment of actions, even though there are many actions, and extensions can add arbitrary ones. Debatable whether we should cut the number of actions to correspond to the three roles defined by the base system. This is not clear - please raise a ticket for this if still promising. Have a method of finding roles (or, in future, actions) relevant to a given protection object (e.g. FILE-UPLOAD(ER) not relevant to Packages) These three points I've moved into a new ticket #1596 as it was getting lost rather in this one. Change UserGroups? so that they can have a hierarchical structure, I think this is completely covered off in #1477 Group refactor Conclusion: closing this ticket as all points are covered or moved into tickets elsewhere
#1066 1301904246000000 dread Need a new role 'ANON_EDITOR' which is the default role for Visitor, which can create packages, but not groups.
#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: }}}
#1066 1301932136000000 dread Done on branch defect-1066-reader-too-permissive and merged into release-1.3.3
#1067 1302186503000000 dread Done in cset:d75ab5fc3311 for release 1.3.3
#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.
#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.
#1069 1302510609000000 rgrp Mistakenly assigned to this sprint.
#1069 1310133794000000 thejimmyg Yes, and this will be more important in thedatahub.org
#1069 1340632215000000 icmurray Assigned to @tobes as he's looking at publication workflows.
#1070 1310117129000000 rgrp Added link to http://wiki.ckan.net/Domain_Model and closing as work mostly done (and nothing clear remaining to be done -- agreement perhaps!)
#1071 1301943180000000 dread Done in cset:db9e2c4f65bb for release-v1.3.3
#1072 1302106474000000 dread Done in cset:2a97d2d9ba4a for release 1.3.3.
#1073 1302185825000000 dread Done in cset:9dfc60db90ed on default branch.
#1074 1314278296000000 rgrp johnlawrenceaspden did quite a bit on this in feature-1074-refactor-authz-wui branch (including implementing for package and group). However, did not implement for authzgroup and also repeated code a lot. Reassigning to me for completion.
#1074 1314283492000000 rgrp Also work on branch feature-1074-authz-wui (that is primary one in fact)
#1074 1314303581000000 rgrp Closed in cset:18a5b48bbee6. Note the templating isn't completely reused but rather uses common methods from _util.html. Likely that a bit more refactoring could be done to share common code but not worth it at present.
#1075 1303227982000000 johnlawrenceaspden closing ticket see http://wiki.ckan.net/Authorization and https://bitbucket.org/okfn/ckanext-admin
#1076 1302515674000000 sebbacon See also http://trac.ckan.org/ticket/948
#1076 1302731255000000 rgrp All main work done as of cset:556efcb91f19 in branch feature-1076-improve-purge-system (+ associated work in ckanext-admin trash bin management). All that remains is to add some tests.
#1076 1303236302000000 rgrp Test of trash functionality in ckanext-admin in https://bitbucket.org/okfn/ckanext-admin/changeset/e86c102a3c60 so now closing (could do with some functional tests in the main interface but can leave for later -- were none before so situation no worse ;0 ).
#1077 1319797284000000 dread I guess this is not a priority now.
#1078 1305828965000000 kindly complete: cset:843b78bae016
#1079 1302777496000000 kindly Complete see cset:35ba6ad033ae
#1081 1303332388000000 johnlawrenceaspden Actually it seems to be worse than that. If I add a user to an authz group then I get added too, and then there's no way to remove me.
#1081 1303489474000000 johnlawrenceaspden Fixed as part of feature-854-tests-for-authz-groups branch. Original behaviour was that creating/modifying user is explicitly added to the users in the authz group.
#1082 1315317825000000 dread The flash message 'Language set to: English' was always in the previous language, not the new one. Pudo fixed this in cset:eaf342823caf and I have transplanted this into release-1.4.3. I've also added/corrected translations for all languages for 'Language set to: English' so that it makes sense! "Set language back to English causes server error:" I can't reproduce this. The exception looks like a problem with the forwarding, which improvements were made in #1126.
#1082 1315917217000000 dread Language switch problem has been around since it was introduced in the 1.3.1 release.
#1083 1304975681000000 johnlawrenceaspden Current behaviour: from the web interface, russianfan can be added as an admin on warandpeace twice. and you can then delete the two roles separately. desired behaviour is that you can only add him once. from the command line, you can only add him once, but if he's in there twice, you can't remove him because the command line bombs desired behaviour is that he can be removed from the shell, you can add him twice but can't remove him if he's been added twice. if you try, it bombs. The desired behaviour in all cases is that adding and removing are effective and idempotent in all three cases.
#1083 1305051061000000 johnlawrenceaspden It appears to be possible to get into a state where you can't add or remove roles from the command line. Investigating.
#1083 1305058621000000 johnlawrenceaspden Fixed the problem where you can't delete a role if it's been added twice, but had to leave the add function as it was since putting a commit in it breaks many tests. It appears that the WUI doesn't call these functions anyway. Left that as it is since we're planning to replace it. The cli rights command doesn't appear to add the roles that it says it adds. Possibly because it's not doing the required commit? Reported this as a different bug.
#1084 1303894555000000 dread ww you did this didn't you? Perhaps you could update us with the branch/changeset it was in and close this ticket please.
#1085 1302621951000000 rgrp I don't think this is very useful output :) Most of this is test/demo/rdf and therefore not relevant. Also have you checked your ckan.site_url in your development.ini -- which configures where what is used as based for all external urls in the templates? IMO there is nothing to fix here.
#1085 1302624602000000 dread As discussed on IRC, the default ckan.site_url should be blank, rather than ckan.net.
#1085 1302625314000000 dread Fixed in cset:01b3de5d4e31 on default.
#1086 1303381200000000 johnlawrenceaspden There is no (obvious) way to delete an authzgroup.
#1086 1323346552000000 dread Authorization groups are deprecated with the incoming Groups Refactor #1477
#1087 1310134714000000 thejimmyg Child ticket of #954
#1087 1320866159000000 dread Implemented in cset:0b7e2b0bed44 as status_show logic action, heading for 1.5.1 release. Took 0.5h
#1088 1302630624000000 wwaites you use the negotiate function in autoneg.py with a cfg dictionary like this, {{{ cfg = { "mime_types": [ ("application/xhtml+xml", ["html"]), ("text/html", ["html"], ("application/rdf+xml", ["rdf", "owl"]), ("application/turtle", ["ttl"]), ("text/plain", ["nt"]), ("text/x-graphviz", ["dot"]), ] for content_type, exts in negotiate(cfg, accept_header): if "html" in exts: render page normally else: redirect to semantic.ckan.net } }}}
#1088 1303035487000000 wwaites fixed in 5c091fc08474 (bug-1088-autoneg-is-wonky) tip
#1089 1302631733000000 dread Done in cset:6d41ecc431e3 on default.
#1090 1302635699000000 dread Fixed in cset:e0af88edf0f0 on default.
#1091 1303746408000000 rgrp This is a well known issue (see some discussoin in #142). There is nothing directly we can do about it (this is what google gives us) but we could make usernames editable (this has been discussed but not ticketed I believe). Given our general "downer" on openids I'm not sure this is a big priority.
#1091 1323102767000000 rgrp wontfix plus we now requires usernames see #1386
#1092 1305570822000000 kindly completed cset: ca1ac4112ea2
#1093 1302865470000000 dread Fixed by this API call use the existing license cache. Done in cset:a95888ea39be on release-v1.3.4
#1094 1303129670000000 rgrp See also comments on the mailing list. Item 1 seems fine (what is difference from current extension mechanism?) Item 2: concerns here. What about list views? What about editing 'permissions'? I also think getting rid of System object isn't really a benefit (if anything may be a cost). Item 3: feel this may be better as part of big domain model change (also gives us time to really dig into this -- this is an important requirement/conceptual issue). Item 4: No objections but seems very minor gain for fairly significant migration work.
#1094 1304354036000000 johnlawrenceaspden UserGroup/PackageGroup might also be confusing. A PackageGroup is *just* a group of packages. A UserGroup is both a group of users, and a thing affecting authorizations. Perhaps PackageGroup and UserAuthorizationGroup? Or PackageGroup and AuthorizedUserGroup? I was quite confused by all this at first. I think I understand how the whole thing works pretty well now, and I still can't think of good names for the two concepts, although I can already feel the normal English meanings of the words changing to what I now know they are for. We should be a little wary of this. Things that are even slightly difficult to understand end up being understood by very few people. Would any of us be prepared to sit an exam on exactly how UNIX file permissions work, even though we all use them?
#1094 1311173649000000 thejimmyg Merging with #1065 and closing.
#1096 1307444626000000 nils.toedtmann See also http://ckan.okfnpad.org/multisite
#1096 1310125173000000 thejimmyg Renaming to CKAN Hosted because whether we introduce a site domain object for subdomain tenants or not is an implementation detail. As far as progress on CKAN hosted goes, we now have: * A build tool to package ckanext-dgu, ckanext-std etc into .deb files * The ability to apt-get install CKAN * A script that can set up multiple non-conflicting CKAN instances on the same machine What we need next is the ability to generate a ckanext-xxx repository for each new instance we want to host. At that point most of the underlying techniques for hosting multiple CKAN instances concurrently will be in place. Once we have that working and know what clients want, we can look at going further and speccing up a multisite solution off a single DB, rather than the multi-instance solution proposed here.
#1096 1311182262000000 thejimmyg Milestone ckan-v-future deleted
#1097 1303293476000000 dread Done in cset:5dec7eb609ab on branch release-v1.3.4.
#1098 1303387896000000 dread Fixed in b2b37e39de4d in release-1.3.4. Was only broken on this branch a few days before.
#1098 1303406017000000 dread Also found problem with some tests using delete_all. Fixed in cset:f9764dd43a0a release_1.3.4.
#1099 1324057106000000 dread Authorization groups deprecated with the Group refactor #1477
#1100 1303406103000000 dread Done in release_1.3.4 cset:580e2b11b4ef and release 1.3.3 cset:cac55b8a0bd9
#1101 1330082908000000 dread Stats already in site nav - adjusting title to just mention google analytics.
#1102 1303744552000000 rgrp (Same ticket created 3 times by accident I think -- see #1104).
#1103 1303744575000000 rgrp (Same ticket created 3 times by accident I think -- see #1104).
#1104 1303744486000000 rgrp You haven't done paster search-index rebuild I think. If you haven't the search index will not have been built (Create Test Data code creates data without indexing it). This could be considered a bug of Create Test Data but I'm not sure -- if you think so re-open this ticket and change description.
#1104 1303920492000000 dread I agree this should be fixed.
#1104 1303920791000000 dread Fixed on default cset:52a3fb230074 - create-test-data now indexes the package it creates.
← 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 →
Note: See TracReports for help on using and creating reports.