[dev] Application Permissions (was Re: appLinks() and Re:Aboutpermissions)

[Hans Lellelid]

> Forced you to? It could have "forced" you to come to the community
with
> what
> you needed, propose a solution, and submit it to the community.

Not on my timeframe, but your point is well taken.  

My needs were pretty specific. I don't think most people using Horde
need a project membership & project role combination.  I don't think,
therefore, that my solution is relevant for Horde.

However, I do believe that a Role object in Horde would greatly increase
flexibility -- and may result in design patterns that could achieve the
type of system that I, e.g., needed.  Basically it would make a lot of
sense to have a way to group permissions together into Roles and apply
those roles to people (or groups?) and have those roles determine the
access users have to content -- rather than granting explicit
permissions for each piece of content.

 
> > Also, Horde's Category driver didn't suffice for the pretty complex
> > user/group queries I needed to perform.  E.g. finding all groups
that a
> > user belongs to was way too inefficient -- not to mention needing to
> > find all the users who shared group membership with a specified user
:)
> 
> Some of us are working on ways to improve this. You could help.

Well, ok.  Again, my needs were specific -- and not role-based per se.
What I ended up implementing was a Group/Perm system that used a couple
tables (plus, of course, the group and user tables):

	- memberships
	- permissions

memberships:

[uid]	[unit_type] 	[unit_id] 	[perms]
hans	myapp.base.Group	12		60
(read,edit,add,delete)
joe	myapp.base.Group	12		12 (read,edit)

So users can be related to groups (myapp.base.Group is also the location
of the class that represents the 'Group' entity).  If I were to use a
role-based model I would have replaced [perms] with [role_id] and
created a [roles] table to map roles -> perms.

permissions:

[content_type] [content_id]  [grantee_type] [grantee_id] [perms]
myapp.base.Doc   12         myapp.base.Group    12         60
myapp.base.Doc   12         myapp.base.User    hans        12

Where myapp.base.Doc is a document [entity] (and the path that points to
the class that represents that entity).  Permissions can be assigned for
any content object and can be given to either a group or to a user.  In
my model, groups are always granted _PERMS_ALL to content -- so that the
only limiting factor is a users permissions in a group. 

Again, probably not going to be very widely applicable, but ended up
working very nicely for me.  I have SQL classes that export the
necessary JOINS so that I can accomplish all membership & permissions
functions in one query.

Hans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3549 bytes
Desc: not available
Url : http://lists.horde.org/archives/dev/attachments/20030328/78c2fcd5/smime-0001.bin