Deleting an item should also delete its children

[joepio]

Currently, when a Parent is deleted, its children will (in most cases) no longer be openable. That is because the authorization checks will look at parents, and then get a 404.

The proper solution is probably to remove all children when a parent is removed.

This also opens up the question of trashing items. Ideally, users can revert deletions if they make a mistake, but the deleted item should not clutter the UI.

How should trashing work?

Trashbin as parent of resource

• When a resource is deleted, we set its parent to the Trashbin
• The Trashbin is a Class. Every drive has one TrashBin as its child. The Trashbin cannot be removed.
• When a resource is inside the Trashbin for X days, it is removed.
• When a resource is reverted from the Trashbin to where it was, we look at the Commit that put it in the trashbin.

trashAt as property

• When a resource is deleted we add a trashAt: some_date property to it
• When iterating over items in a collection, we skip trashed items by default
• When some_date is matched, we permanently delete the resource.

[IcedQuinn]

marking for deletion and eventual pruning are something i was just looking for.

what all should be marked is probably highly dependent on use though.

for example i may want to expire intermediary events and versions created between releases of something, but not the releases. such as i don't want a record for every paragraph and character change in a markdown. those might be useful for cooperative editing, but after a month all we care about is the completed final version. (those final versions might be kept, though, since we actually might care about say a changing terms of service over time, just not the highly noisy updates between approvals.)

[IcedQuinn]

This should IMO be changed to a couple tickets.

• Slow deletes
• When the editor should cascade a slow delete
• Garbage collect nodes that can't be used?