Loading...
 
Skip to main content

History: Flagged revisions tab

Preview of version: 51

This old feature described below was removed in 2011 and replaced by a feature which is simpler to configure, uses less code and is a better and more future-proof approach: Flagged Revisions in Tiki8.


Wiki Staging & Approval tab

Overview
Use this tab to allow wiki pages to be "staged (drafted) before they are "approved" (published)
To Access
From the Administer Wiki page, click the Staging and Approval tab.
Note
You must enable and configure the necessary categories before enabling this feature.

Staging and Approval tab
Staging and Approval tab
Setting Description Default
Use wiki page staging and approval
Force bounce of editing of approved pages to staging
Delete staging pages at approval As soon as a page is approved the staging 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.
Page name
Unique page name prefix to indicate staging copy: A prefix is used to indicate staging copy: This is required.
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 Tiki" will be the staging copy of the page "Using Tiki". 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
Staging: 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. None
Approved (mandatory for feature to work): None
Out-of-sync: If "Delete staging pages at approval" is not activated, 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 approved, 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. None
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).
Freetags
Replace freetags with that of staging pages, on approval If selected, this replaces the freetags set on the approved page to those in the staging page upon approval.
Add new freetags of approved copy (into 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.

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 Tiki" will be the staging copy of the page "Using Tiki". 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 Tiki", you will be sent to edit "*Using Tiki". 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 Tiki, 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: If "Delete staging pages at approval" is not activated, 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 approved, 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.
  • Force 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. NOTE: Even WITHOUT this selected the edit icons will redirect the user to edit the staging copy - it just does not prevent direct URL access.
  • 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 staging 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.

If configuration of staging and approval appears not to work, try clearing cache in System Admin between steps















Wiki Page Staging and Approval

Requirements: This feature requires categories to be turned on and categories created before it will work (see below).


The information below may be a bit out of date now. For best results, see http://profiles.tiki.org/Staging_and_Approval

Introduced in Tiki2.

This feature is similar but different than the articles and submissions feature. Articles are like newspaper articles, once approved and published, they normally don't change. Whilst wiki pages are, by nature, always in flux.


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.

Example:

Documentation site has a policy that

  • approved pages are visible to the public, but are updated (approved) only by senior editors.
  • meanwhile any registered user can edit the draft version of the page, which is reviewed periodically and approved (or not) by senior editors.


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. Tiki 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

Limitations

  • Wiki page attachments are not handled
  • Structures are not handled

Profile

http://profiles.tiki.org/Staging_and_Approval

alias


History

Advanced
Information Version
Marc Laporte 55
Bernard Sfez / Tiki Specialist 54
drsassafras removed tiki 6 content 53
drsassafras migration to prefdoc plugin 52
drsassafras 51
Marc Laporte Edit restored by rescue script 2017-04-24T18:09:12+00:00 50
Marc Laporte Edit restored by rescue script 2017-04-24T18:09:12+00:00 49
Marc Laporte 48
Xavier de Pedro 47
Louis-Philippe Huberdeau 46
Rick Sapir / Tiki for Smarties 44
Rick Sapir / Tiki for Smarties 43
Rick Sapir / Tiki for Smarties Fancy Table Plugin modified by editor. 42
Rick Sapir / Tiki for Smarties 41
Rick Sapir / Tiki for Smarties 40
Rick Sapir / Tiki for Smarties 39
Rick Sapir / Tiki for Smarties 38
Marc Laporte 37
Marc Laporte 36
Marc Laporte cleanup 35
Nelson Ko 34
Nelson Ko 33
Marc Laporte adding some aliases 32
Marc Laporte 31
Nelson Ko 30
Marc Laporte 29
lindon 28
Nelson Ko 27
mlpvolt 26
Marc Laporte typo 25
Marc Laporte 24
sylvie 23
Marc Laporte 22
sylvie 21
sylvie 20
Xavi (as xavidp - admin) 19
Xavier de Pedro 18
Marc Laporte 17
dthacker 16
Xavier de Pedro thanks to sylvie for the example sent over tiki-devel list 15
sylvie 14
Nelson Ko 13
Nelson Ko 12
Nelson Ko 11
Xavier de Pedro some markup? 10
Nelson Ko 9
mlpvolt adding links, examples. (nice feature!) 8
Xavi (as xavidp - admin) added to the documentation structure as child of "Wiki config". Nice feature Nelson! :-) 7
nkoth 6
nkoth 5
  • «
  • 1 (current)
  • 2