Sorry. What I mean is that there would only every be *one* address 
book (when using shares) that is removed from Turba's data store.  The 
address book that is removed is what (internally, anyway) we call the 
"default", or "personal" address book - the one that would get created 
by default when the user first logs in if there are no other address 
books visible to the user at that time.  It's that last sentence that 
may cause confusion...say you have a "global" address book setup that 
all users can see.  A new user logging in will, in that case, *not* 
have a "default" address book created...therefore, will not have any 
address book removed automatically when the user's account is removed.



This was done as a precaution against inadvertently nuking data that 
other users may be using in a shared environment.

Oops.. Sorry for the delay, I did not see your post
What do you mean?



in turba prefs.php



// Address books to be displayed in the address book selection widget

// and in the Browse menu item.  The address book name is stored using

// the source key from sources.php (e.g. "localsql").  Separate

// entries with "\n" , e. g. 'value' => "localsql\nlocalldap" (the

// double quotes are REQUIRED).  If 'value' is empty (''), all address

// books that the user has permissions to will be listed.

$_prefs['addressbooks'] = array(

     'value' => '',

     'locked' => false,

     'shared' => false,

     'type' => 'implicit',

);



// Default directory

$_prefs['default_dir'] = array(

     'value' => '',

     // 'value' => 'localsql',

     'locked' => false,

     'shared' => false,

     'type' => 'select',

     'desc' => _("This will be the default address book when adding or 
importing contacts."),

);



my setup:



default_dir has been commented out as it has side effect (If I 
remember, localsql was not good when in shared mode..). In imp, there 
is a prefs to say where to add contacts and I added also a hook for 
seaerch sources (imp or kronolith) in horde/config/hooks.php:

function _prefs_hook_search_sources($username = null)



Anyway leaving default_dir blank, everything is working perfectly

Currently the removeUserData api will only attempt to remove a user's 
*default* share to reduce the possibility of accidentally deleting 
shares that other users may have data in.  A default share is only 
designated as a default share if, when the user initially logs in, 
there is *no* other source that the user has access to.



So, my guess is that your 'localsql' shares that are not being removed 
are not defined as 'default' shares.

Hello Chuck



I understand that for ldap, but not for the sql side



In my sources.php



$cfgSources['localsql'] = array(

     'title' => _("My Address Book"),

     'type' => 'sql',

..

     'export' => true,

     'browse' => true,

     'use_shares' => true,

     'list_name_field' => 'lastname',

);



$cfgSources['localldap'] = array(

     'title' => 'Annuaire U2',

     'type' => 'ldap',

..

     'strict' => array('dn','mail'),

     'browse' => true,

     'export' => false

);



My localsql data should have been cleaned, no?



I've seen strange behaviour that can explain something, if I make ldap 
not browsable (I would), I can't browse localsql. Seems there is a 
single api for both sources



Just trying to debug:



in horde-webmail-1.2.1/turba/lib/api.php (line 234)

     /* Only attempt share removal if we have shares configured */

     if ($_SESSION['turba']['has_share']) {

         $shares = &$GLOBALS['turba_shares']->listShares(

             $user, PERMS_EDIT, $user);



         /* Look for the deleted user's default share and remove it */

         foreach ($shares as $share) {

                     Horde::logMessage('tracedom3 
'.$share->get('params'), __FILE__, __LINE__, PEAR_LOG_ERR);

             $params = @unserialize($share->get('params'));

             /* Only attempt to delete the user's default share */

             if (!empty($params['default'])) {

                 $config = Turba::getSourceFromShare($share);

                 $driver = &Turba_Driver::singleton($config);

                 $result = $driver->removeUserData($user);

                 if (is_a($result, 'PEAR_Error')) {

                     Horde::logMessage($result, __FILE__, __LINE__, 
PEAR_LOG_ERR);

                     $hasError = true;

                 }

             }

         }



  $share->get('params') returns nothing, so localsql is not cleaned



Data was in turba_shares

share_id         share_name         share_owner         share_flags         perm_creator 
        perm_default         perm_guest         attribute_name         attribute_desc 
        attribute_params

103          r9906146          r9906146          0          0          0          0          Carnet d'adresses de 
Emmanuel XX          NULL          NULL



Hope this helps

removeUserData isn't supported by the LDAP driver.

Jan 21 14:20:22 HORDE [error] [turba] Removing user data is not 
supported in the current address book storage driver. [pid 17683 on 
line 221 of "/var/www/perso/horde-webmail-1.2.1/turba/lib/api.php"]



I followed Jan instruction for using the api to remove users, but in 
turba I got that error. That should be nice to get it working!



I have one localsql source in share mode and one in ldap mode.



And in SQL, I kept all the data from invalid users



Is it enhancement or bug?



Thanks



Dom