Spickinawich...
 
I've 
noted that when a doc is deleted, no record seems to be kept of when it was 
done, by whom, or what the document's former history was.  When I brag 
about XWiki's ability to track and undo changes, I have to sort of 
gloss over this little hole in the functionality.
 
I 
realize, of course, that permission to delete is separately controllable (though 
only as a part of the "admin" right) but I'd like not to have to forbid anyone 
deleting documents merely because I can't support an audit trail for them.  
Then again, the inability to recover space by means of wholesale deletion (with 
optional archiving) of obsolete documents would make admins pretty unhappy, 
so some ability to do complete deletions (without resorting to direct database 
manipulation) must remain as an administrative option.
 
So I think I'd like to see the following:
 - auditable, history-recoverable document 
deletion (and possibly renaming), granted as part of the "edit" right; 
and
 - auditable but non-recoverable (by ordinary users) deletion 
and renaming reserved for the "admin" right.
 
In 
order to accomplish this (and other refinements, foreseeable and otherwise), it 
might be a good idea to populate XWikiRightService.getRight()'s 
actions-to-required-rights map from a configuration file rather than directly in 
code as the default rights service implementation currently 
does.
 
Of 
course, this method does not map "delete" to "admin"; instead it maps "delete" 
to "delete", and checkAccess() deals with "delete" specially, succeeding 
immediately for the document's creator and changing the required right to 
"admin" for anyone else, before doing the check.  So this is another 
example of the unfortunate complexity of the rights system, which will probably 
require considerable effort to simplify, if it can be done at all, and I 
wouldn't blame the developers if they were reluctant to take it up; I certainly 
would be.  Thus the age-old conflict between "security is hard" and 
"complexity is the enemy of security" continues (though together they hint that 
complexity is part of why it's hard)...
brain[sic]