Wiki Page Staging and Approval

TikiWiki >=1.10



This is a feature to allow wiki pages to be "staged" or drafted before they are approved (published). This is useful, for example, to have a staging area where open contributions are welcome, but at the same time to have an official pr published knowledge base that is extremely stable, hence needing some kind of approval before page changes are shown there. This feature works with the groups and categories features to have customizable access to pages with different status.

Admin preferences and setup

The preferences under Wiki Config are explained here:

• Use wiki page staging and approval: If this is unchecked, the feature is completely off.
• Unique Naming convention: a prefix is used to indicate staging copy: This is compulsory for the feature to work. Basically staging copies of (approved) wiki pages are marked and recognized by having a prefix in front of their name. For example, if the prefix is set to "*", which is the default, the page "*Using Tikiwiki" will be the staging copy of the page "Using Tikiwiki". If you like, you can replace the prefix with something more meaningful, e.g. "On staging - ". Note, however, that if you change the prefix after initial configuration, you will need to rename the old staging copy pages in order to preserve the link between staging and approved versions. Otherwise, new staging copies based on the new prefix will begin to be used.
• Hide page name prefix: If selected, the prefix will be hidden in the page name that is shown on top of pages as they are viewed and edited (there is already will be a separate message on these pages to indicate to a user that he is viewing a page which is staging copy). The prefix is still shown on other pages, e.g. lists of pages, etc... as they will be relevant in those cases.
• Category for staging pages: It is highly recommended to select a category to put staging pages in. You can then set permissions for this category, for example, edit perms and view perms both for registered users only. When staging pages are edited, they are automatically placed in this category when a user saves the page. This happens regardless of what other/no categories are selected by the user.
• Category for approved pages: This is compulsory for the feature to work. You have to select a category to put all approved pages in. You can then set permissions for this category, for example, edit perms for system admins only, and view perms for everyone. The edit button of pages that are in this category will be redirected to the staging page, providing convenient access to edit the staging instead of the approved page. This edit button will be shown based on the edit perms the user has for the staging page, not the approved page. If the staging page does not exist yet, it will be created transparently. In the above example, if you click on edit while viewing "Using Tikiwiki", you will be sent to edit "*Using Tikiwiki". Note, though, that you can still edit the approved page manually by accessing tiki-editpage.php url directly, e.g. tiki-editpage.php?page=Using TikiWiki, unless you set the "Force bounce..." setting below. Approved pages will automatically be placed in this category when they are approved. This happens regardless of what other/no categories are selected by the user.
• Category for pages out of sync: It is highly recommended to select a category to identify pages that are out of sync. When a user saves edits to staging pages, they are automatically placed in this category regardless of what other/no categories are selected by the user. At the same time, when these staging pages are removed, they are taken out of that category. If this setting is off, staging pages are always considered "out of sync" and there will be no indication, so setting this is really useful. Moreover, you can review pages that are out of sync through browsing the category.
• Redirect of editing of approved pages to staging: As mentioned above, you can already limit edit permissions by user group under Category Admin. However, if you really want to, you can force redirect all requests of tiki-editpage.php for pages in the approved pages category to go to the staging copy. This may be useful to totally prevent direct editing of the approved version through direct tiki-editpage URL.
• Categorize approved pages with categories of staging copy on approval: If selected, the categorization of the approved page is set to that of the staging page upon approval, with the exception that auto-categorization of the special categories configured in this system are not affected (on approval, the approved copy will not have the category for staging pages set, and will continue to have the category for approved pages set).
• Replace freetags with those from staging pages on approval: If selected, this replaces the freetags set on the approved page to those in the staging page upon approval.
• Copy new freetags of approved copy (to tags field) when editing staging pages: If selected, when a user edits a staging page, freetags that are in the approved copy but not in the staging page will automatically be inserted into the freetags field. An editor/document reviewer will have a chance to change these tags before his final edit before approving.
• Delete staging pages at approval: As soon as a page is approved the stagged page is deleted
• If not in the group, edit is always redirected to the staging page edit: This allow you to create new pages in a staging status.

Sample use case

This is not meant to be definitive, but has been tested to work.

2 groups: author / approver
2 categories: staged / approved

1. An author creates a page XXXX in the staged category.
2. If category notification set, approver receives a message.
3. Anyone can edit the page while it remains in the staged category.
4. An approver approves the page for the 1st time by categorizing it to approved category.
5. TikiWiki automatically creates a page *XXXX with the staged category and without the approved category.
6. An author can see the page *XXXX and edits it again. If he tries to edit XXXX, tw redirects him to edit *XXXX. An approver is also redirected to edit *XXXX if he tries to edit XXXX.
7. If category notification set, approver receives a message whoever edits *XXXX. Alternatively, approvers can check the "Out of Sync" category for pages that have edits not yet approved.
8. When ready, an approver approves the page, by clicking on "approve" that appear on top of *XXXX. Moreover, if not ready, the authors/approvers/ etc.. can all conduct edit war on the *XXXX until they are happy, before approving.

Because no one edits the approved page directly, there is no chance of conflict, at the cost of a small inconvenience to approvers.

Features that will be apparent

• A link to approve a page appears while viewing staging pages if they are out of sync.
• A link to show page history? since the last approval (a diff) appears while viewing staging pages if the pages are out of sync. The determination of the version is based on the last edit date/time of the approved page, so it will not be correct if the approved page has been edited directly without going through the staging copy, another reason to use the "Force bounce option" above, but it is foreseeable that admins may want to be able to directly edit the approved page and consider that an "approved" version, so it depends on your needs.
• A note appears on the edit page screen indicating to a user that he is editing a staging page and if the page is out of sync.

Important notes about creating new pages

• When creating new pages as someone with permission to the approved category, place the page in the category for approved pages if this is a page that needs to be staged.
• When creating new pages as someone without permission to the approved category, it really doesn't matter in which category the page is stored. However, this page cannot be "approved" the automated way until it is approving for the first time by someone with permission to include it in the category for approved pages. For convenient locating of new items created by these users, it is possible (using another feature), to set the default category to a category you can create such as "New Pages", for the different groups/levels of contributors as you need.

Important admin notes

• Changing the categories settings explained above after initial install will require moving of pages to new categories to make sure that those specific features still work for those pages.
• Renaming or changing parent of categories have no effect (the system refers to categories by their ID, not name).
• Change the prefix setting after initial install will require Renaming the old staging copy pages in order to preserve the "link" between staging and approved versions.
• Direct Renaming of staging pages have been blocked in tiki-rename.php for usability reasons, and Renaming of pages now checks and renames staging copies as well (based on prefix) if this feature feature_wikiapproval is on. Admins that have custom code doing Renaming of pages should be careful.

See attached comment for an example of perms

---

Imagine a site where
* Anonymous see nothing
* Registereds see the approved pages and not the stagging pages
* Authors see the staging+approved pages. They can edit staging
pages. They see all the pages: They can categorized with other
categories the pages.
* Approvers see the staging+approved pages. They can approve
pages.
The groups are included in each other
Anonymous < Registered < Authors < Approvers

Group perms
* Registered
* tiki_p_view
* tiki_p_view_categories
* tiki_p_view_categorized
* Authors
* tiki_p_edit
* tiki_p_edit_categorized
* tiki_p_wiki_view_history
* Approvers
* tiki_p_remove
* tiki_p_rename
* tiki_p_rollback

2 categories
* Staging
* Approved

Categories perms
* Staging
* Authors: tiki_p_view_categories
* Authors: tiki_p_view_categorized
* Authors: tiki_p_edit_categorized
* Approved
* Registered: tiki_p_view_categorized
* Authors: tiki_p_view_categories
* Approvers : tiki_p_edit_categorized

Wiki staging setting:
* If not in the group, edit is always redirected to the staging
page edit: Approvers
* Delete staging pages at approval: yes
* Categorize approved pages with categories of staging copy on
approval: yes
* Force bounce of editing of approved pages to staging: yes
* Category for staging pages: Staging
* Category for approved pages: Approved
* Category for pages out of sync: none
* Unique page name prefix to indicate staging copy: *

What happens during the staging process with this configuration?
* For example a page named mypage. During the staging, 2 pages
will be able to coexist, mypage = approved version, *mypage =
stagging version
* An author clicks edit on mypage, the edit page pannel opens the
stagging page *mypage. When he saves *mypage, tikiwiki assigns
*mypage to the stagging category. If an author clicks edit on
*mypage, the edit page opens on *mypage
* An approver approves *mypage. tikiwiki copies all the history of
*mypage changes on top of mypage history and assigns the
category approved to mypage. tikiwiki deletes *mypage