[dev] [commits] Horde branch H4-Group updated. 840392473461fdde7040004a26bceac2a3cc3dcf

[Jan Schneider]

Zitat von Michael Rubinsky <mrubinsk at horde.org>:

>
> Quoting Jan Schneider <jan at horde.org>:
>
> <snip>
>
>> commit a45e4bb5980601ebeea3c3231e0f1afac9fcb944
>> Author: Jan Schneider <jan at horde.org>
>> Date:   Sat Mar 5 18:04:12 2011 +0100
>>
>>    Tweaks and fixes to the contact group API.
>>
>>    Michael, can we drop listUserGroupObjects(), because this seems  
>> to provide the
>>    same functionality like getGroupMemberships()?
>
>
> getGroupMemberships() returns a list group id => group names that  
> the current user is a *member* of (useful for checking if a user has  
> permissions on a resource to which the group has permissions to),  
> while listUserGroupObjects() returns an array of turba lists that  
> the current user has Horde_Perms::SHOW on, to be used e.g, in  
> listing the groups the user has available for assigning permissions  
> to his/her resources.  In other words, User "A" can be a member of  
> User B's contact list, but not have permissions to User B's list (so  
> should not be able to use User B's list to assign permissions to one  
> of User A's resources).

Hm, that doesn't align at all with the general group API (and how we  
use it in application, if I didn't miss anything), because there is  
only the destinction between listing *all* groups and only the groups  
the user is a member of.

With that approach we need to consider different group lists for  
permission checking and permission assignment. How did that ever work  
in the past? :) Ah, I guess because we had userIsMemberOfGroup() (or  
some such), which has been dropped in the rewrite.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/