[dev] Virtual address book permissions

[Michael Rubinsky]

Quoting "Kevin M. Myer" <kevin_myer at iu13.org>:

> Quoting Michael Rubinsky <mike at theupstairsroom.com>:
>
>> My original implementation did just that, very similar to the way IMP
>> does vfolders.  I had it running on a small test server with a handful
>
> This was my original thinking when I submitted the feature request, to
> essentially allow a user to save searches, but read on below.
>
>> of users. A number of the users had expressed interest in being able to
>> share the vbooks so I reimplemented it to use a share as the 'backend'.
>>  I thought it would be useful to have these vbooks available to people
>> without each user having to create his/her own vbook.  A new
>> employee/student whatever would just login to Turba/IMP etc and will
>> see a listing of all the people in the Support Deptartment etc...  If
>> the consensus is to not go that route then, I'll just re-reimpliment ;)
>
> I wasn't sure how I would like the implementation as a Virtual Address
> Book, but I found that it is actually potentially useful, at least from
> an admin's perpsective.  The reason this is so is because of the
> existence of Horde_Share in Turba now, because it lets me easily create
> a logical group of entries and share that with everyone, just by saving
> a search.
>
> So in the end, I see two potential uses, depending on the way you go
> (or both if you implement both).  First is a Virtual Contact List,
> which is mostly akin to the initial feature request.  This allows users
> to save a logical grouping of their choice, afix a name to it and use
> it for things of their choosing (most likely as a whole group of
> names).  The second is a Virtual Address Book, which allows an admin
> (or a user with appropriate permissions) to save a logical grouping of
> their choice and have it be available to other users as a logical
> grouping.  In this case, the admin makes the choice of the grouping and
> then provides it in a logical format to users, in the form of an
> address book.  I'd see the more typical uses of this not necessarily be
> having the whole address book be used, but instead, providing a limited
> subset of all available choices in a container that users can interact
> with.

Thinking a bit about this and Virtual Contact Lists vs Virtual Address 
Books, I'm trying to think through how the VLists could be implemented. 
  Lists exist within the address book container, and depending on the 
backend, we may or may not be able to store them in a sensible way.  
The only thing I can think of is storing the search criteria as a user 
pref, then when the source is loaded/searched, we'd have to perform 
additional search(s) of the source(s) then dynamically create a Contact 
List to be displayed. Of course, as always, I could be totally off base 
here...

> As an example, lets say you wish to work with users by Location, with
> an end goal of being able to email them.  If you want to work with
> *all* users in a particular Location, you can a) create a Contact List
> by hand, or b) save a Virtual Contact List that queries a source where
> LOCATION=blah.  Option b provides a logical grouping of entries in the
> format of a Contact List.  If you wished to send an email to just some
> of the people at a Location, you could a) find all the people at the
> Location and select the ones you want, from a source, or b) use an
> existing Virtual Address Book, which an admin has setup to select the
> users at one Location.  Both "B" options eliminate the need for a user
> to specify the initial search criteria.  Each helps winnow through
> potentially thousands of entries and make those entries available in
> logical subsets of the overall data available.

This is exactly what I was thinking in creating them as shares.  
Although in my implementation, *any* user can create these, not just an 
admin.

> 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.

Thanks,
Mike