Fri, 10 Apr 2026 13:36:26 +0000 https://bugs.horde.org/ticket/7877 removing user data 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 Wed, 21 Jan 2009 14:06:22 +0000 https://bugs.horde.org/ticket/7877#t51882 removeUserData isn't supported by the LDAP driver. Wed, 21 Jan 2009 15:19:24 +0000 https://bugs.horde.org/ticket/7877#t51884 > removeUserData isn't supported by the LDAP driver. 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 Wed, 21 Jan 2009 16:16:02 +0000 https://bugs.horde.org/ticket/7877#t51886 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. Sun, 01 Feb 2009 18:45:49 +0000 https://bugs.horde.org/ticket/7877#t52182 Oops.. Sorry for the delay, I did not see your post > 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. 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 Mon, 09 Mar 2009 07:57:26 +0000 https://bugs.horde.org/ticket/7877#t52961 >> So, my guess is that your 'localsql' shares that are not being >> removed are not defined as 'default' shares. > > What do you mean? 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. Mon, 09 Mar 2009 13:52:37 +0000 https://bugs.horde.org/ticket/7877#t52968