[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