[dev] [cvs] commit: turba/lib Driver.php turba/lib/Driver sql.php

[Michael Rubinsky]

Quoting Karsten Fourmont <fourmont at gmx.de>:

> Hi,
>
>> yes. When I was logged in as user "admin" and deleted the account
>> "johndoe" in user mngmt., admin's address book got deleted, not
>> johndoe's...
>



> I looked into this again.  Version 1.90 of sql.php (before my  
> change) looks like this in removeUserData($user):
>
> ...[correctly identify johndoe's shares in $sources]...
> foreach ($sources as $source) {
>    if (!$this->_deleteAll($source))  {
>       return PEAR::raiseError(...)
>    }
> }
>



> However deleteAll is
>
> "function _deleteAll()" (line 303)
> and so completly ignores the $source argument.
> It uses   $this->share->get('uid') to identify the uid, but this is  
> not the right one.
>
> Cheers,
>  Karsten
>

Your absolutely right about the code changes...I guess I need to  
figure out why my installs *are* working and go from there...I just  
tested two of them again by adding a new user, logging in as that user  
and adding some address books, logging back in as an admin and  
deleting the user...my admin's address book is still there...

 From a cursory glance at the relevant code, it looks like the  
*proper* OO way to fix this would be to actually instantiate a driver  
object for each of the deleted user's sources and then call  
Turba_Driver::_deleteAll() on those objects, but that could be  
slightly slower / more resource intensive.  The question is, I guess,  
is the simpler code (the current implementation) the better solution  
in this case, or is it worth changing it to preserve encapsulation at  
the cost of slight performance hit for the relatively few times users  
will be deleted?







> Karsten Fourmont wrote:
>> Hi,
>>
>>> Hmm. I wonder if something else is going on then. I can't  
>>> reproduce this behavior on *any* of the three HEAD installs I have  
>>> running at
>>
>> I'll have a look on my machine again. Maybe it's something wrong  
>> with its installation...
>>
>> I'll let you know.
>>
>> Karsten
>>
>>
>> Quoting Michael Rubinsky <mike at theupstairsroom.com>:
>>
>>> Quoting Karsten Fourmont <fourmont at gmx.de>:
>>>
>>>> Hi,
>>>>
>>>>> Was this broken for you?
>>>>
>>>> yes. When I was logged in as user "admin" and deleted the account
>>>> "johndoe" in user mngmt., admin's address book got deleted, not
>>>> johndoe's...
>>>
>>> Hmm. I wonder if something else is going on then. I can't  
>>> reproduce this behavior on *any* of the three HEAD installs I have  
>>> running at the moment (before your change, of course).  Is anyone  
>>> else seeing
>>> this?
>>>
>>> I'm trying to avoid passing around the source name like that since  
>>> it's already encapsulated in the driver object...
>>>
>>>
>>>
>>>
>>> Thanks,
>>> mike
>>>
>>> -- 
>>> The Horde Project (www.horde.org)
>>> mrubinsk at horde.org
>>
>>
>>
>> --Horde developers mailing list - Join the hunt: http://horde.org/bounties/
>> Frequently Asked Questions: http://horde.org/faq/
>> To unsubscribe, mail: dev-unsubscribe at lists.horde.org
>
>
> -- 
> Horde developers mailing list - Join the hunt: http://horde.org/bounties/
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org



Thanks,
mike

--
The Horde Project (www.horde.org)
mrubinsk at horde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-keys
Size: 2013 bytes
Desc: PGP Public Key
Url : http://lists.horde.org/archives/dev/attachments/20070111/3b5bf150/attachment.bin