Audit trail for deletions (was: Re: Strange behaviour on xwiki.org)

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]