[Tickets #2245] Horde Share implementation for Turba

[bugs@bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: https://dev.horde.org/horde/whups/ticket/?id=2245
-----------------------------------------------------------------------
 Ticket             | 2245
 Updated By         | Michael Rubinsky <mrubinsk at horde.org>
 Summary            | Horde Share implementation for Turba
 Queue              | Turba
 Version            | HEAD
 State              | Feedback
 Priority           | 1. Low
 Type               | Enhancement
 Owners             | Michael Rubinsky
-----------------------------------------------------------------------


Michael Rubinsky <mrubinsk at horde.org> (2005-07-17 20:07) wrote:

> The 'public' item essentially duplicates the 'user_shares' attribute 
> you added. Something like 'use_shares' would be clearer, but either 
> way there should only be one of these configuration items, and an 
> upgrade script should be created to convert current 'public' 
> addressbooks into having the appropriate permissions and share use.

I thought I *did* name the attribute 'use_shares', but will double check
when I get back to my dev. machine.

I put that attribute there in addition to 'public' for a few reasons...of
course, my reasoning could be (and often is) misguided ;)

1 -  This allows administrators to continuing using the "old" permissions
system after upgrading turba - in case the installation already has a fair
number of permissions set or they are using the 'public' localsql source.

2 - Setting 'use_shares' => true isn't really the same as setting 'public'
=> true.  In the first case, using shares allows the end user to decide to
share his/her address book and what level of permissions to give etc.  In
the latter case, everyone would have access to the same source...unless
maybe permissions were explicitly set against it, in which case it would
have to be an administrator making that decision.  Either way, the people
that had access to the source would see *all* the entries in the table,
essentially, all the users' sql addressbooks.  By using shares, only the
user's that choose to share would have their entries visible, and they would
appear as a seperate source...not grouped together in the same address book
as is the case with public => true.  

If we were to decide to go this route, and force the use of Horde_Shares on
those sources that will support it (localsql for now), an upgrade script
*would* be needed.  It would basically have to create a new share seperate
from individual user's shares, perhaps owned by an admin, and "copy" the
existing entries into this share, changing the 'owner' attribute in the
process.

Why is nothing ever as simple as it seems at first? ;)