Safe deletion of owner and container objects

[marcus]

Deletion of owner or container objects (groups & users) can cause problems for plugins which expect those things to be valid.

For example; deletion of initial admin (#522) causes site details and groups to be orphaned, deleting a group (#282) causes wsod on owned objects.

Closes #522, #282, #258, #435

[marcus]

Another related issue in pages:

1) User A creates group
2) User A creates page C
3) User AdminB bans A
4) User AdminB views all pages and creates subpage of C
5) Bang!

[marcus]

(In [svn:2545]) Refs #640: Renamed and moved entities.php:disable_entities to user.php:disable_user_entities

[marcus]

(In [svn:2546]) Refs #668, #640: Cleaner interface provided for banning.

[marcus]

I believe that the "GUID xxx was not a valid" exception was thrown when accessing a disabled user entity via get_user_by_name() - this is quite common.

This error was caused by the function not checking access controls - this has been fixed in [svn:2588] fixing #699.

An exception is also thrown if the entity uses a custom class provided by a plugin which is no longer installed. This too can be handled (which may be best done in a try catch in the views system.

The last error is a parsing error caused by code like:

$owner = get_entity($entity->owner_guid); Entity is valid, but owner is a disabled user
echo $owner->getURL(); Method call on non object

This is untrappable unfortunately and because of elgg's views system all output is suppressed (further experimentation being conducted) hence WSOD. The solution is to validate all objects, which is just good programming but is all to easy to forget!

[testbot]

what's the status on this. this is pretty huge.

[ciaphas]

Why not force the individual deleting the object to remove all child objects/entities prior to deletion of the parent object? This would be simply adding a delete button for the admin and owner..

[ciaphas]

and a few DB actions

[amias]

how about cascading through the objects and setting them to be set to private to move them out of the way and owned by the administrator who can then delete or reassign them as they see fit.

[marcus]

(In [svn:2690]) Refs #640, #282: Recursive deletion of owned and contained entities.

[marcus]

(In [svn:2695]) Closes #282, Refs #640: Group deletion enabled. TODO: Suggested enhancement #752

[marcus]

(In [svn:2696]) Refs #640: Entity disable now recursive

[marcus]

Given that a number of separate issues have been resolved relating to this, and we have now made deletion recursive as default (which handles group, user and site deletion) this should only leave one main failure mode:

That is that an entity has owner / entity information in metadata and trys to access a method on this entity after a get_entity call without first checking the return type. This is an edge case and is not something the framework can detect.

I am therefore closing this issue.