[dev] Virtual address book permissions

Michael Rubinsky mike at theupstairsroom.com
Thu Nov 17 05:09:42 PST 2005


Quoting Jan Schneider <jan at horde.org>:

> Zitat von Michael Rubinsky <mike at theupstairsroom.com>:
>
>>> As far as the PERM_EDIT question, why would you give a user more
>>> permissions with a vbook, if they didn't have PERM_EDIT on the original
>>> source?
>>
>> What I was thinking of was the case where you had one, very large
>> 'global address book' across the organization - which may or may not be
>> available in it's full source to everyone on a read only basis.  As the
>> admin, I might wish to assign one person per, let's say department to
>> maintain the information for the people they are responsible for.  So,
>> let's say Bob is a department manager.  He has 100 employees he is
>> directly responsible for.  I could allow Bob to maintain the
>> information for only his staff so he could, for instance change Mary's
>> phone number without the ability to update information for people for
>> whom he is not responsible for.
>
> And how would you determine if a user is allowed to add a contact
> (which is a matter of PERMS_EDIT too)? Lookup which virtual address
> book it would end up in? I don't think this would work intuitively.
>
> Jan.

In my case we aren't allowing 'end users' to add contacts to the 
company-wide global address listing.  That would be the admin when 
someone new is hired/added.  We don't want to let end users potentially 
pollute the global address listing with their personal contacts.  This 
allows the entire global address listing to be read only while allowing 
certain people the ability to edit a subset that pertains to them.  
This feature was really an extension of the fact that the owner/creator 
of the vbook can set whatever permissions he/she wants on the vbook, 
independently of the original source.  Otherwise, the owner of the 
vbook must also be able to assign permissions on the original source to 
the users he/she wants to use the vbook.

I don't feel *that* strongly about this part of the vbook feature, so 
if you feel it would be too confusing or unintuitive then I'll just 
make the vbooks always readonly.  I would still like to discuss 
implementing the vbooks as shares though as I feel that it does add 
value.


Thanks,
mike

--
The Horde Project (www.horde.org)
mrubinsk at horde.org



More information about the dev mailing list