(1) Sally deletes an employee record
(2) Bob deletes that employee's department
(3) Sally tries to undo the deletion of the employee - will the employee be restored without a department?
I would argue that a good design would actually prevent you from deleting important records like these. i.e. when Bob clicks delete, it just marks the object as deleted and it stops showing up in reports/interfaces. Then maybe you have something clean it up 90 days later or something.
Similairly you don't make table ARTICLES with column AMOUNT and KIND. You make table CHANGES with DIFFERENCE and KIND, and only ever add rows to that table (possibly with negative DIFFERENCE).
Scenario: Laptop's price is initially $800 and then increases to $850 before dropping to $825
Design 1: with columns Amount and Kind will just have a single row which will get modified with the latest value
Design 2: Will have 3 rows in the above case
Difference | Kind | Time stamp
800 | 'Laptop' | ts 1
+50 | 'Laptop' | ts 2
-25 | 'Laptop' | ts 3
So this latter design has 'undo' builtin
edit: formating
Under complete presumption: Bob is an HR member while Sally is a Manager. Why? The ability to manage entire groups should be left to people higher up in the administration chain where individual users should be delegated to HR or other staff.
Bob should have permissions to manage users but not groups. Sally should have permissions to manage both. If Bob deletes a user, then Sally deletes the group, there should be no reason that Bob should be able to anything outside his domain. The group should not be restored and Bob should be given a clear, 'plain English' reason why he can't do such an action.
If both Sally and Bob are managers of a group and said situation occurs, no group should be restored when Bob restores a user. Only a readable error message should occur. In fact no data to be restored should be there in the first place unless it has been backed up or cached.
What is a possible solution to this logic?
1.) You could implement an optional backup system. All deletes are final in the context of the action. Think of a common tree structure: if no main branch is there to support a twig then no twig can hang. No restores via users can be performed until the group has been restored. The deleted data could be stored in a cache until certain parameters are met; once these are met the data is deleted (IE: Recycle Bin)
2.) Users could be restored belonging to a default group. If a recently deleted member of a recently deleted group needs to be restored, they could be assigned to a default 'holding' group or other similar group with restricted permissions. This retains all specific user data which is not lost and by default the user will not be given extraneous or extra permissions. They can then be assigned to an appropriate group.
3.) Removing a group does not affect users within it. This is the opposite of a tree structure. This is analogous to Linux group and user permissions. A group can be assigned to users so they can access a resource. They are not interconnected in any way other than their usage to control permissions. Users can be removed and restored at will and so can groups. No conflicts of hierarchy are incurred.
In summary, restoring an individual resource should never restore the controlling body without given consent. This would create a lot of problems if it did.
- git-style 3-way-merge
- Google Wave -style operational transform
If somebody is experienced on the topic, I'd love to learn more about different approaches. Also, it would be awesome to have these as an open source DB projects (well, we have git) or even offered as IaaS.
User confirmation dialogues are a UI smell, in the same way that a module of code stuffed with if statements and flags is a code smell. It's telling you that your design has a fundamental flaw that needs to be fixed in a non-trivial way. Just t hink about the basic question - should red be "delete" or "no". Either way, the question implicitly recognises that this situation is confusing, and that Sally has a good chance of making a mistake. Knowing that her problem has arisen because she clicked on the wrong button ("when it was clearly coloured red!") is not going to make Sally like your software. Make it so that she can fix her error, not so that she doesn't make the error in the first place.