[Tickets #10241] Re: removing user data doesn't work

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/10241
------------------------------------------------------------------------------
  Ticket             | 10241
  Updated By         | Michael Rubinsky <mrubinsk at horde.org>
  Summary            | removing user data doesn't work
  Queue              | Horde Framework Packages
  Version            | Git master
  Type               | Bug
  State              | Resolved
  Priority           | 2. Medium
  Milestone          |
  Patch              |
  Owners             | Michael Rubinsky
------------------------------------------------------------------------------


Michael Rubinsky <mrubinsk at horde.org> (2011-09-03 18:01) wrote:

> Should shares in *_sharesng tables still exist after user data  
> removal? Because currently they still do.

Shares that the user is the owner of, in the currently active share  
driver should be removed. So, if you are using the ng sql driver, then  
no, they shouldn't still exist. If you are using the legacy sql share  
driver, then the ng table would not be touched. If you *are* using the  
ng driver, then check your log for any errors and post back. I've  
tested locally with both sql drivers and all user-owned shares are now  
properly removed.

> I have also grepped database for the user in question. Entries in  
> horde_history

horde_history is purposely not deleted since it is, well, a history of  
what has happened. They are necessary e.g., If some other user (User  
B) had rights to the deleted user's (User A) address book, and User B  
has it set to synch to one of his devices, then the history entries  
are necessary to ensure User A's entries are properly removed from  
User B's device(s).

> and imp_sentmail persist too.

The IMP_Sentmail table's garbage collection is managed by the sentmail  
driver itself. The API doesn't contain any facility for deleting a  
specific user's entries in that table. Instead, it deletes all entries  
that are older than a configurable time-period.