My company's audit department requires that no sensitive information (usernames, passwords, etc) is stored in the Confluence WIKI. As a sledgehammer approach to crack this particular walnut, they are requesting page level access entitlements being introduced across the whole WIKI to guard access to this kind of information. This is against the whole ethos of an open information store, providing knowledge to all.
I am looking for an approach that allows pages to be created/amended by a submitter (the maker), but not be visible (or available in the page change history) until the page has been approved by a second individual (the checker)? This would then make the checker accountable and reduce the likelihood of occurrence to a reasonable level, satisfying the audit viewpoint.
The use case would be something like this:
The maker edits/creates the page and saves it - at this point the page changes are hidden from both the current page and its history. The checker receives an email with the link to the amended/new page, so that the checker can review it.
The checker should have two options approval/reject the page. Approving the page will make it visible and added to the page's history; Rejecting the page allows the checker to add a comment on why it is rejected, and emails the maker with a link to the (still hidden page) with the comments.
The maker either receives an email indicating the page was accepted, or that it was rejected. If rejected, the email contains the link to the (hidden) page, allowing them to revise it and resubmit.
The checker should be the immediate line manager of the submitter, as identified from say LDAP.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.