[#2117] Make Horde Permissions inheritable
Summary Make Horde Permissions inheritable
Queue Horde Framework Packages
Type Enhancement
State Accepted
Priority 1. Low
Owners
Requester kevin_myer@iu13.org
Created 2005-06-10 (5476 days ago)
Due
Updated 2008-11-09 (4228 days ago)
Assigned
Resolved
Milestone Horde 4.0
Patch No

Comments
kevin_myer@iu13.org 2005-06-10 11:15:54
If Horde Permissions are not explicitly set for a child element, have 
the permissions inherit those of the parent element.

kevin_myer@iu13.org 2005-06-11 21:23:14
As a followup, and which I think goes hand-in-hand with inheritance, 
would be the ability to recursively set permissions.  In fact, in my 
mind, allowing children to inherit parent permissions is a case of 
automatic recursion.

Chuck Hagenbuch <chuck@horde.org> 2005-06-13 02:35:20
I don't have a problem doing this. BUT: we need to think it through in 
terms of the ways it can affect all of Horde. For instance: what 
triggers inheritance? Lack of permission, or no permission at the 
level being checked being *set*? I'd vote for the latter.



This will probably mean that anyone with permission to use an app will 
by default get permission for all the subpermissions of that app - 
which will change existing installs. Especially if we go with my 
suggestion above I don't think that will be a problem, but it will 
change existing installs.

Jan Schneider <jan@horde.org> 2005-06-13 09:15:39
> This will probably mean that anyone with permission to use an app

> will by default get permission for all the subpermissions of that app

> - which will change existing installs. Especially if we go with my

> suggestion above I don't think that will be a problem, but it will

> change existing installs.



That would be a reason not to do this by default IMO, because it may 
change a lot of existing permissions unintentially. I think we should 
only do this case-by-case for example for the turba:sources perms 
where you're probably heading at.

Chuck Hagenbuch <chuck@horde.org> 2005-06-14 03:59:07
> That would be a reason not to do this by default IMO, because it may

> change a lot of existing permissions unintentially. I think we should

> only do this case-by-case for example for the turba:sources perms

> where you're probably heading at.



If you really think this is a deal breaker then I think we should just 
forget it completely; I don't want to have to keep track of where 
permissions are inherited and which aren't, and I can't imagine users 
do.



Then again, if we do it not case-by-case, exactly, but depending on 
how the function is called (include a $parentPerms parameter or 
whatever), then it'd match the group API... that may have been what 
you meant? I still feel uneasy about the inconsistency here, but maybe.



I don't think this is a deal-breaker, fwiw; I just think we need to 
think it through, do it carefully, supply upgrade scripts where 
appropriate, and announce it loudly.

Jan Schneider <jan@horde.org> 2005-10-24 13:15:54
How about a button in the prefs screen instead, that applies the 
settings of the current node to all child nodes?

kevin_myer@iu13.org 2005-10-24 13:46:38
> How about a button in the prefs screen instead, that applies the

> settings of the current node to all child nodes?



That would be helpful for doing batch permission changes for existing nodes.



Here's a thought - what about a flag on a node that makes the setting 
for that node a default?  When any child node is added, it looks up 
the tree through the parents.  If a parent node is encountered that 
has the default flag set, it inherits the permissions on that parent.   
If an admin has set no default flags, it assumes permissions like it 
does now.  That retains backwards compatibility, and allows for 
default values to be set (essentially enables inheritance, should an 
admin choose to set default values).

Jan Schneider <jan@horde.org> 2005-10-24 13:53:13
How about the opposite? Add a flag to a permission that it should 
inherit from the parent permission. Seems much easier to me for admins 
to wrap their heads around that.

kevin_myer@iu13.org 2005-10-24 14:12:30
> How about the opposite? Add a flag to a permission that it should

> inherit from the parent permission. Seems much easier to me for

> admins to wrap their heads around that.



Well, I see this as being two issues:



1)  How to make changes to existing permissions - I like the idea of 
an "Apply to Children" button.



2)  How to determine permissions for new nodes - inherit from parent, 
this is the way most permission systems operate (filesystems come to 
mind), so yes, I think admins would wrap their heads around this 
quicker.





Chuck Hagenbuch <chuck@horde.org> 2005-10-25 18:01:01
> 1)  How to make changes to existing permissions - I like the idea of

> an "Apply to Children" button.



Having this makes sense to me, though it's a different thing than this 
ticket (mostly).



> 2)  How to determine permissions for new nodes - inherit from parent,

> this is the way most permission systems operate (filesystems come to

> mind), so yes, I think admins would wrap their heads around this

> quicker.



I just want to say that I don't like the idea of some permissions 
inheriting and others not. I think we should either have no 
inheritance, or everything inherit. I know that going to everything 
inherit will cause some transition pain, but I think it's much saner 
in the long run.

Jan Schneider <jan@horde.org> 2005-10-26 07:50:57
>> 2)  How to determine permissions for new nodes - inherit from parent,

>> this is the way most permission systems operate (filesystems come to

>> mind), so yes, I think admins would wrap their heads around this

>> quicker.

>

> I just want to say that I don't like the idea of some permissions

> inheriting and others not. I think we should either have no

> inheritance, or everything inherit.



Just to make sure we're talking about the same thing. The proposed 
approach doesn't inherit parent permissions automagically based on 
some intransparent rule. The admin has to explicitely enable 
inheritence (through a checkbox or some such) when creating a new 
child permission.

Chuck Hagenbuch <chuck@horde.org> 2005-10-26 14:41:42
> Just to make sure we're talking about the same thing. The proposed

> approach doesn't inherit parent permissions automagically based on

> some intransparent rule. The admin has to explicitely enable

> inheritence (through a checkbox or some such) when creating a new

> child permission.



Right. I'm saying I don't like that approach. I think that permissions 
should automatically inherit from their parents, in a completely 
straightforward way: everything inherits. It's easy to understand that 
as long as it's consistent. But even with making admins select a 
toggle, people can forget they set it up that way... I think it's not 
going to be obvious what's going on.

Chuck Hagenbuch <chuck@horde.org> 2006-11-21 01:21:53
Where do folks stand on this these days?

Jan Schneider <jan@horde.org> 2006-11-21 10:05:17
I agree that using inheritence consistantly and unconditionally is the 
best solution, but it also changes current behaviour. I guess we 
should stall it for Horde 4 and implement it correctly then.

Chuck Hagenbuch <chuck@horde.org> 2008-11-09 16:17:05
Time to start figuring out what Horde 4 permissions look like, I guess.