Hi, One of the biggest problems I am facing is a feature that happened somewhat accidentally in the old menu system. If you give administer comments right to someone and no other administer permission then you will see a 'Comments' link along with 'My account' and 'Logout'. This 'bubbling' just kills the new system. So, what about we get rid of it for good? admin, admin/by-task, admin/compact, admin/by-module, admin/logs, admin/help has access administration pages and their children have this permission, too. admin/settings, admin/content, admin/build and admin/user is currently set to administer site configuration . While it has logic in it, I would like to see a permission for the collection pages listed here which is not used anywhere else. Then you give your admin 'see admin pages' rights which in itself does not grant you any admin priviledges and also administer comments. However this comments admin user would see a very empty admin/build page, for example. With a nice message, probably. Is this acceptable? If not, then there are not one but two patches that are able to address this problem. However, the simpler one would slow down D6 to D5 speeds and the more complex one is, erm, a hell lot more complex and I have not yet benched it. See http://drupal.org/node/122876#comment-206669 #12 for the more complex approach, #15 for the simpler. If we find that a) the above is not acceptable b) the more complex one is needed then I will need help with explaining and commenting the code . Regards, NK
I don't think that "in order to access A/B/C you need permission to access A/B and A, too" is an unreasonable restriction. The magic flattening always bugged me from a UI perspective, honestly. --Larry Garfield On Mon, 05 Mar 2007 23:15:06 +0100, "Karoly Negyesi" <karoly@negyesi.net> wrote:
Hi,
One of the biggest problems I am facing is a feature that happened somewhat accidentally in the old menu system.
If you give administer comments right to someone and no other administer permission then you will see a 'Comments' link along with 'My account' and 'Logout'. This 'bubbling' just kills the new system.
So, what about we get rid of it for good? admin, admin/by-task, admin/compact, admin/by-module, admin/logs, admin/help has access administration pages and their children have this permission, too. admin/settings, admin/content, admin/build and admin/user is currently set to administer site configuration . While it has logic in it, I would like to see a permission for the collection pages listed here which is not used anywhere else. Then you give your admin 'see admin pages' rights which in itself does not grant you any admin priviledges and also administer comments. However this comments admin user would see a very empty admin/build page, for example. With a nice message, probably.
Is this acceptable?
If not, then there are not one but two patches that are able to address this problem. However, the simpler one would slow down D6 to D5 speeds and the more complex one is, erm, a hell lot more complex and I have not yet benched it. See http://drupal.org/node/122876#comment-206669 #12 for the more complex approach, #15 for the simpler. If we find that a) the above is not acceptable b) the more complex one is needed then I will need help with explaining and commenting the code .
Regards,
NK
On Mar 5, 2007, at 3:22 PM, Larry Garfield wrote:
I don't think that "in order to access A/B/C you need permission to access A/B and A, too" is an unreasonable restriction. The magic flattening always bugged me from a UI perspective, honestly.
agreed. i put some stupid code into signup.module to deal with weird UI problems that came from this magic flattening for users that have "administer signups" but not "administer site" (or whatever it's called) perms. i'd be happy to clean it all up in 6.x if the flattening went away. and yes, needing to have access to A and A/B to get to A/B/C seems totally reasonable to me, too, especially given the split of admin menu perms into "see admin pages" and "have admin rights" as described by chx's original message... my only minor quibble with that is that i'm not sure just having "see admin pages" should give you access to the logs. i could imagine wanting to give a role permission to admin comments, but not necessarily see all site logs. -derek
Derek Wright wrote:
On Mar 5, 2007, at 3:22 PM, Larry Garfield wrote:
I don't think that "in order to access A/B/C you need permission to access A/B and A, too" is an unreasonable restriction. The magic flattening always bugged me from a UI perspective, honestly.
If user has permission to see 'admin > foo' and only 'admin > foo' user does not have access to 'admin' (top level - main callback). So what would the user get when they click on 'admin' in order to make a second click to 'foo'? 'access denied'? That can't be good. Or do you display 'admin' as a non-clickable menu item - already expanded to display 'foo'? andre
I believe what chx is proposing (and he is free to thwack me if I'm wrong) is that if the user doesn't have permission to see "/admin", then they won't see "/admin" in their menu at all. If they have permission to see /admin/foo, they still won't see /admin in their menu and therefore won't see /admin/foo either. That makes the logic easier/faster/more sane. That necessitates the creation of some sort of generic "see admin section" permission that does nothing but grant permission to "/admin". A user with that permission and nothing else would get some sort of "Sorry, you're not a real admin, ha ha!" message if they went to /admin. Something similar would likely be required for the "Create content" page. Alternatively, I don't know how easy a "meta permission" would be to automate; eg, the permission for /admin is "you have permission on one of the children of this path". I've not really been keeping up with the new menu system, so chx will have to tell us why I just created 40 hours more work for him with that sentence. :-) --Larry Garfield On Tue, 06 Mar 2007 10:50:49 -0500, Andre Molnar <mcsparkerton@yahoo.co.uk> wrote:
Derek Wright wrote:
On Mar 5, 2007, at 3:22 PM, Larry Garfield wrote:
I don't think that "in order to access A/B/C you need permission to access A/B and A, too" is an unreasonable restriction. The magic flattening always bugged me from a UI perspective, honestly.
If user has permission to see 'admin > foo' and only 'admin > foo' user does not have access to 'admin' (top level - main callback). So what would the user get when they click on 'admin' in order to make a second click to 'foo'? 'access denied'? That can't be good.
Or do you display 'admin' as a non-clickable menu item - already expanded to display 'foo'?
andre
Karoly Negyesi wrote:
Hi,
One of the biggest problems I am facing is a feature that happened somewhat accidentally in the old menu system.
If you give administer comments right to someone and no other administer permission then you will see a 'Comments' link along with 'My account' and 'Logout'. This 'bubbling' just kills the new system.
So, what about we get rid of it for good? admin, admin/by-task, admin/compact, admin/by-module, admin/logs, admin/help has access administration pages and their children have this permission, too. admin/settings, admin/content, admin/build and admin/user is currently set to administer site configuration . While it has logic in it, I would like to see a permission for the collection pages listed here which is not used anywhere else. Then you give your admin 'see admin pages' rights which in itself does not grant you any admin priviledges and also administer comments. However this comments admin user would see a very empty admin/build page, for example. With a nice message, probably.
Is this acceptable?
I am not sure I am getting what you are saying, but if you that saying that if a user doesn't have access rights to foo he won't have access rights to foo/bar then I am all for it. Cheers. Gerhard
On Tue, 2007-03-06 at 00:26 +0100, Gerhard Killesreiter wrote:
Karoly Negyesi wrote:
Hi,
One of the biggest problems I am facing is a feature that happened somewhat accidentally in the old menu system.
If you give administer comments right to someone and no other administer permission then you will see a 'Comments' link along with 'My account' and 'Logout'. This 'bubbling' just kills the new system.
So, what about we get rid of it for good? admin, admin/by-task, admin/compact, admin/by-module, admin/logs, admin/help has access administration pages and their children have this permission, too. admin/settings, admin/content, admin/build and admin/user is currently set to administer site configuration . While it has logic in it, I would like to see a permission for the collection pages listed here which is not used anywhere else. Then you give your admin 'see admin pages' rights which in itself does not grant you any admin priviledges and also administer comments. However this comments admin user would see a very empty admin/build page, for example. With a nice message, probably.
Is this acceptable?
I am not sure I am getting what you are saying, but if you that saying that if a user doesn't have access rights to foo he won't have access rights to foo/bar then I am all for it.
Cheers. Gerhard
chx is actually talking about the presentation of menu in the Navigation menu, not actual access control, i think. I'm sure chx will correct me if I'm wrong. Right now if you have access to administer comments, but not to access administration pages, you see a Comments link at the root level of the menu. I think permissions to containers should be inferred if you have access to the children, just for consistency of navigation. The click trail to administer comments should be the same whether you have access administration pages or not. How hard will it be to support end users if you have all these possibilities to get to the 'administer comments' section? Developers and power users may realize its usually the same url, but not people who are used to desktop apps where 'edit >> preferences' consistently gets you to preferences. preferences doesn't get bumped to the root of the menu tree if you don't have access to the edit container. they just show you the container with the options you can access hidden or disabled. very much like the edit and revisions tabs. so chx. I very much agree with you, except it would be nice if admin/build were completely hidden instead of showing a page stating I don't have access to this section. .darrel.
so chx. I very much agree with you, except it would be nice if admin/build were completely hidden instead of showing a page stating I don't have access to this section.
That is not impossible, a simple access callback is needed which would determine whether there is more than one thing for you on the collection page. I am so very happy that I can lose the bubbling thing. Next time I will ask before wasting weeks struggling to implement something that ends up in the trashcan. Thanks, Karoly Negyesi
On 3/5/07, Karoly Negyesi <karoly@negyesi.net> wrote:
so chx. I very much agree with you, except it would be nice if admin/build were completely hidden instead of showing a page stating I don't have access to this section.
That is not impossible, a simple access callback is needed which would determine whether there is more than one thing for you on the collection page.
This is what MENU_ITEM_GROUPING does last I checked. It is used to show node/add if any children of node/add are visible. I tried to use this a long time ago, before the admin menu reorganization, to remove the 'access administration pages' permission. The problem I ran into was admin/help wanting to be visible if the parent is visible. I haven't looked at it recently. I'd like to see the 'access administration pages' permission removed, in favor of showing the top-level admin pages when someone has access to any sub-page. -- Neil Drumm http://delocalizedham.com
That is not impossible, a simple access callback is needed which would determine whether there is more than one thing for you on the collection page.
This is what MENU_ITEM_GROUPING does last I checked.
So true. But if you use that then you need to access check all it's children. No, thanks. I still prefer the custom access callback.
Op maandag 5 maart 2007 23:15, schreef Karoly Negyesi:
Is this acceptable?
I don't think so. This is not my personal opnion, its just a helicopter view thingy: What you are proposing is a hierarchical permission system (like that of LDAP) to replace our current node (NOT the Drupal node, the real thing) based permissions (like that in *nix systems). Our nodebased (NOT the Drupal node!!) permission system has worked very well so far. Moving this to a hierarchical system involves a LOT more then merely a menu refactoring. It is an architectural decicion with a great impact on how people (can) use Drupal. We should at least know more about the side-effects. But preferably we should really know about the underlying concepts and pitfalls. Especially because a hierarchical permission system, combined with group (Drupal calls them roles) based systems is generally considered no-go area; because: too complex in UI and concept. In general I would say: don't go in that swamp, unless you have a guide (permission expert) to guide you. Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
Bèr, I don't understand why hierarchical permissions and role permissions can't be mixed. Could you elaborate, and cite some of the sources of wisdom you're alluding to? Bèr Kessels wrote:
Especially because a hierarchical permission system, combined with group (Drupal calls them roles) based systems is generally considered no-go area; because: too complex in UI and concept.
-- * * * * * Lullabot's First Ever Advanced Workshops Are Here! Drupal API & Module Building - Advanced Drupal Themeing April 9th-13th - Providence, RI Early Bird Discounts Available Now http://www.lullabot.com/training * * * * *
Answering two at once :-) Op dinsdag 6 maart 2007 12:02, schreef Dries Buytaert:
Ber -- I can't grok your e-mail. Can you elaborate (based on facts rather than vague metatalk!), please? Thank
It is not vague. But the main point /is/ metatalk. Feel free to put on horeseflaps and focus on technical aspects, though. I am only trying to get the bigger picture right, first. Its my prefered way of working: to know where I am heading: to have the theory and architecture right (I am not saying this is not done in this case, I merely see a big potential problem, because of lack of knowledge from anyone on this point). SO: All I am saying (and really nothing more) is: Don't dive headfirst into a new/different access model for Drupal without knowing where you are heading! Op dinsdag 6 maart 2007 11:19, schreef Robert Douglass:
Bèr, I don't understand why hierarchical permissions and role permissions can't be mixed. Could you elaborate, and cite some of the sources of wisdom you're alluding to?
Basically there are three main security/permission concepts in use: ACL: en.wikipedia.org/wiki/Access_control_list http://www.suse.de/~agruen/acl/linux-acls/online/main.html RBAC: http://en.wikipedia.org/wiki/Role-based_access_control CAP: http://en.wikipedia.org/wiki/Capability-based_security Mixing these very often results in what is called "Confused Deputy Problem" http://en.wikipedia.org/wiki/Confused_deputy_problem More "wisdom" in this Must-read: http://www.cl.cam.ac.uk/~rja14/book.html Its written in a very accessible way, and it teaches you a LOT you should know if you are using machines (computers) for your work. Many times it is repeated in that book, that the *model* should be correct. And clean. And understood. Example chapter 4.4.6: « Mixing all these different models of computation together has resulted in chaos. Some of their initial assumptions still apply partially, but none of them applies globally any more. The Internet now has hundreds of millions of PCs and workstations, millions » And yes. Again: this /is/ fuzzy metatalk. But unless we get the architecture right this time The New Menu System[tm] will be only that: "new". It won't be "better" or "more secure". The old menu system had a good access architecture, not perfect: but in order to improve it, merely stirring everything upsidedown is not the solution. Improving it -- is. And sorry, no, I have not the slightest idea how to achieve that in Real PHP Code (or patches); luckily its a good thing that developing a CMS is not just about coding... Bèr -- Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal hosting: www.sympal.nl
On 06 Mar 2007, at 13:09, Bèr Kessels wrote:
Op dinsdag 6 maart 2007 12:02, schreef Dries Buytaert:
Ber -- I can't grok your e-mail. Can you elaborate (based on facts rather than vague metatalk!), please? Thank
It is not vague. But the main point /is/ metatalk. Feel free to put on horeseflaps and focus on technical aspects, though.
Eh?
I am only trying to get the bigger picture right, first. Its my prefered way of working: to know where I am heading: to have the theory and architecture right (I am not saying this is not done in this case, I merely see a big potential problem, because of lack of knowledge from anyone on this point).
I wasn't asking for a lesson on "horseflapping the bigger picture" -- although the cited book sounds fun. I just wanted you to clarify your writing in the context of Karoly's original message -- preferably using Drupal terminology. Here is the passage were you lost me: "What you are proposing is a hierarchical permission system (like that of LDAP) to replace our current node (NOT the Drupal node, the real thing) based permissions (like that in *nix systems). Our nodebased (NOT the Drupal node!!) permission system has worked very well so far." Thanks for taking a first step at clarifying your original message. It helped -- to some extend. I think I got your main point. -- Dries Buytaert :: http://www.buytaert.net/
Excellent references, Bèr. Thanks for posting them. I have a similar concern about our permission system becoming a muddied mixture of models, resulting in a system that is incredibly hard to grok by administrators and users -- and maybe by even some developers. Although it doesn't seem to really directly bear on chx's proposal, I can see how his proposed change may set a course for Drupal permissions which should be thought out first, as Bèr suggests.
On Wed, 2007-03-07 at 11:54 +0100, Chris Johnson wrote:
Excellent references, Bèr. Thanks for posting them.
I have a similar concern about our permission system becoming a muddied mixture of models, resulting in a system that is incredibly hard to grok by administrators and users -- and maybe by even some developers.
Although it doesn't seem to really directly bear on chx's proposal, I can see how his proposed change may set a course for Drupal permissions which should be thought out first, as Bèr suggests.
there is no proposal on the table to table to change the permission system or access control. so I'm lost. we were talking about a menu item visibility with accessible children. while there are some good references raised in Ber's proposal, we aren't planning on changing the role based access system as far as I can tell. please correct me if I'm wrong. .darrel.
On 06 Mar 2007, at 10:59, Bèr Kessels wrote:
What you are proposing is a hierarchical permission system (like that of LDAP) to replace our current node (NOT the Drupal node, the real thing) based permissions (like that in *nix systems). Our nodebased (NOT the Drupal node!!) permission system has worked very well so far. Moving this to a hierarchical system involves a LOT more then merely a menu refactoring. It is an architectural decicion with a great impact on how people (can) use Drupal.
We should at least know more about the side-effects. But preferably we should really know about the underlying concepts and pitfalls. Especially because a hierarchical permission system, combined with group (Drupal calls them roles) based systems is generally considered no-go area; because: too complex in UI and concept.
Ber -- I can't grok your e-mail. Can you elaborate (based on facts rather than vague metatalk!), please? Thanks! -- Dries Buytaert :: http://www.buytaert.net/
participants (11)
-
Andre Molnar -
Bèr Kessels -
Chris Johnson -
Darrel O'Pry -
Derek Wright -
Dries Buytaert -
Gerhard Killesreiter -
Karoly Negyesi -
Larry Garfield -
Neil Drumm -
Robert Douglass