[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
+New Attachment     | turba.patch
-----------------------------------------------------------------------


Michael Rubinsky <mrubinsk at horde.org> (2005-08-07 10:27) wrote:

OK. Had some more time to spend on this - new patch and files attached.

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

I moved this logic into Turba_Driver.

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

I looked more closely at this.  The Ingo migration script actually is
written only against SQL backend (at least that's what it states in the
code).  Probably because of the fact the just about any other driver would
require  username AND password to access username's prefs.  So, even if we
got a complete list of users (either through an Auth driver or through a
provided list (as in the case of the Ingo script) and used the Prefs API, we
would still only be able to update the prefs on a SQL backend without user
passwords.  So, what I did was change the upgrade script slightly to allow
allow updating the prefs if we are using a SQL backend, and provide a notice
that this is not possible otherwise.  The pref is only adding the newly
created public source to the 'addressbooks' pref, so it's not a huge deal
(IMHO, of course).


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

Again, the problem of having user's passwords.  For some backends, we would
need to be logged in as the user who owns the source we are updating.  I'm
not really sure this is an issue though, as the script would only be needed
for people using a SQL backend with 'public' -> true anyway.

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

Made the script more configurable and moved most of the options to be
configured via $CLI->prompt().  Also, grab the table name from
$driver->db->dsn['table'] in case we aren't using horde default of
localsql.

Also-
    -Minor logic improvements
    -Actually delete the source instead of just removing the share info.
    -UI impovements to the My Addressbooks page.
    -Probably some other stuff I'm forgetting ;)