View Issue Details

IDProjectCategoryView StatusLast Update
0007146OXID eShop (all versions)2.5. Administer userspublic2020-06-03 13:25
Reporter[email protected] 
Status closedResolutionduplicate 
Product Version6.2.1 
Target VersionFixed in Version 
Summary0007146: Deleting User in the admin interface does not delete related data
DescriptionWhen a user is deleted in OXID related data (like additional addresses) should also be automatically deleted.
This is done in the User-Model when the delete() method is called, which calls additional methods like for example "User->deleteAddresses()".

"User->delete()" can receive an ID that should be deleted as an argument. Methods like "User->deleteAddresses()" do NOT use that passed ID, instead they always reference the ID of the currently loaded model.

This comes into play when a user is deleted via the admin interface.
 "AdminListController->deleteEntry()" will call "User->delete()" with the ID as param, without actually loading the user model.
This will delete the oxuser record, but not the related data, because the sub-delete-methods like "User->deleteAddresses()" do not respect the passed ID.

So the solution would be either to pass the ID to delete to "User->deleteAddresses()", "User->deleteNewsletterSubscriptions()", etc. or to load the ID in to the user model in "AdminListController->deleteEntry()".
Steps To Reproduce* Create a new user in the OXID admin interface (or in the shop frontend, doesn't matter)
* Add an additional delivery address to that user
* Note the OXID-ID of that user
* Delete that user in the OXID admin interface
* Look into the oxaddress table and search for the user OXID-ID in "OXUSERID" -> The database row of the address still remains
TagsNo tags attached.
ThemeNot defined
BrowserNot defined
PHP VersionNot defined
Database VersionNot defined


duplicate of 0007138 acknowledgedbenjamin.joerger Deleting users won't delete user references left in other tables 



2020-06-03 13:25

administrator   ~0013249

Hi and thank you for reporting the issue.
The same issue was reported a few days ago already. So I will close this entry, mark it as duplicate and link it to the older one.