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]