[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-29 13:09) wrote:


> 1) There's too much logic in sources.php. This must be moved 
> somewhere else, maybe lib/base.php?

I thought that as well, but thought that since the logic was backend
specific (checking that the share representing the user's private localsql
share exists) it really didn't belong in lib/base.php.  The other thing I
thought of is to incorporate this check into Turba_Driver::factory(), but
then we would need a new method in each concrete driver that supports
shares.  Something like $driver->_createDefaultShare() ?  The only driver I
think that we would really need to worry about this code being in Turba is
the SQL driver, since it's really the only 'Horde-Only' source.  Other
backends could make use of the share hooks to do this checking, right?

> 2) Don't assume an SQL preference backend in the migration script. 
> Use the Prefs API to update the preferences. Ah, now that I read it 
> again, I see that you're updating all users' preferences. Maybe this 
> could be done like the filter migration script in Ingo.

Ah.  Good point.  I knew I'd overlook something that obvious...

> 3) It would be great if you could use Turba's API to update the 
> contact owners, but I don't know without looking at the code, if this 
> is possible. This would allow using the script with different 
> backends.
I'll take a look at this, but I thought that the localsql source was really
the only backend that had the potential for being used as either a single
public source OR as multiple private sources...and it's really only the
installations that are currently using public=>true that would need to run
this script.

> 4) Make the source (and table, if not using Turba's API) 
> configurable. Most people are using localsql for private adress books.

Yep, and those people won't need to run the update script...their localsql
books will work just as before whether or not they have 'use_shares' =>
true.  The only difference is they will be able to share their addressbooks
with other users and create new addressbooks...but I should make the upgrade
script configurable as far as the name of the source (and the table name if
not using the API)...Another one of those obvious things I knew I would miss
;)

Thanks for the feedback.