History: Revision approval, Flagged Revisions
Source of version: 35 (current)
- «
- »
Copy to clipboard
! {{page}} Introduced in ((Tiki7)), Flagged Revisions (Tiki feature Revision approval) is a feature replacing the former ((Staging and Approval)). You can get quickly started using the feature when you apply the profile ((pr:Revision Approval)) in your tiki site. Flagged revisions rely on trusted users to mark revisions of a page as good or safe. Trusted users can see all revisions and flag/unflag revisions as needed. A notice at the top of the page will offer these options and allow to navigate to the latest version or the last approved version. More details are available from the ((Page History)). Untrusted users, likely guests of the site, will only be able to see the approved versions of the page. If they are allowed to view the history of the page, they will also only be able to see and diff between approved revisions. Depending on the permissions granted, they may also be able to view unapproved revisions, but they would get a clear warning that the content has not yet been approved and may not be suitable. {REMARKSBOX(type="warning" title="Plugin Include & Staging Approval")}If the page is a child included in another using ((PluginInclude|the INCLUDE plugin)), the approval feature is overriden. Meaning the content will be displayed, even if no version were approved and then it will show unapproved version (last version of the page). This behavior changes in Tiki 18.{REMARKSBOX} !!# Enable the feature To be used, Flagged Revisions must be enabled from "__Admin > Wiki > Flagged Revision__" as ''Revision Approval''. Multiple categories can be specified. Make sure to use the category ID, and not the category name, and separate multiple category IDs with the semicolon (";") character. Pages added to those categories will use the approval workflow. !!# Permissions involved Permissions: * Can view unapproved revisions of pages (tiki_p_wiki_view_latest) * Can approve revisions of pages (tiki_p_wiki_approve) !!# Example Let's imagine a case where: * we have user1 belonging to group1, and user2 belonging to group2. * group1 has been granted permissions to edit pages, view history, view unapproved versions, and to approve them. * group2 has only the permission to view and edit wiki pages, but no permission to view history, unnaproved versions nor to approve them. * HomePage had some content approved by user1: + {CODE()} Our organization is about X, Y and Z. {CODE} * HomePage was then edited and new content was added. + {CODE()} I am { {user}} (the one viewing this page right now) {CODE} !!!# Extend the information displayed with some Wiki Argument Variables You can extend the display of infomation related to flagged revisions in a specific page by means of using the ((Wiki Argument Variables)) related to Flagged revision, like in the examples shown in the screenshots below. !!!# View and actions of user1 (with perms) In this case and specific moment, HomePage shows this content for user1: {img src="display1089" link="display1089" width="600" rel="box[g]" imalign="center" desc="Click to expand" align="center" styleimage="border"} When user1 clicks to see the "__latest version__", that is the page shown: {img src="display1090" link="display1090" width="600" rel="box[g]" imalign="center" desc="Click to expand" align="center" styleimage="border"} When user1 clicks at "__Show changes since last approved version__", that is the content shown: {img src="display1091" link="display1091" width="600" rel="box[g]" imalign="center" desc="Click to expand" align="center" styleimage="border"} There is a box called "__Content approval__" at the top, which allows user1 to "__Approve revision__", in an equivalent way to what was shown in the previous screen when viewing the latest version, if user1 had clicked a the button "__Approve current revision__". Once user1 approves that revision, the new content will be shown when visiting the page: {img src="display1093" link="display1093" width="600" rel="box[g]" imalign="center" desc="Click to expand" align="center" styleimage="border"} !!!# View of user2 (without perms) Note that __before user1 approved the changes in that revision__, this is what __user2__ could see in the same HomePage: {img src="display1092" link="display1092" width="600" rel="box[g]" imalign="center" desc="Click to expand" align="center" styleimage="border"} And __after user1 approved that revision__, this is what __user2__ could see (the same as user1 by then): {img src="display1094" link="display1094" width="600" rel="box[g]" imalign="center" desc="Click to expand" align="center" styleimage="border"} !!# Managing the approval workflow Starting with ((Tiki11)), additional information is included in the ((Search and List from Unified Index)). The ((PluginList|List Plugin)) can be used to obtain lists of pages that need approval. __Note: PluginList requires that your Unified Index be up to date__ {CODE(caption="Simple list of pages pending approval")} {LIST()} {filter field=wiki_approval_state content=pending} {LIST} {CODE} {CODE(caption="List of approved pages")} {LIST()} {filter field=wiki_approval_state content=approved} {LIST} {CODE} {CODE(caption="List of pages not needing approval")} {LIST()} {filter field=wiki_approval_state content=none} {LIST} {CODE} You can also use the "allowed_groups" variable and filter so your results depend of the group allowed to approve. {CODE(caption="Simple list of pages pending approval for the group Approvers")} {LIST()} {filter field=wiki_approval_state content=pending} {filter field="allowed_groups" multivalue="Approvers"} {LIST} {CODE} In previous versions, a list of pending pages could be obtained in a less accurate manner. {CODE(caption="Simple list of pages pending approval (prior to 11)")} {LIST()} {filter categories="42"} {filter field=title content=latest} {LIST} {CODE} The LIST plugin has many more options to alter how to display the list of pages and more filters can be added. You are encouraged to create lists of pages needing approval for the different groups of people managing those pages. This can be done by using additional categories on your pages. If you are using ((Perspectives)), the global listing could be automatically filtered for the currently selected perspective. !!# Mass approval Using ((PluginListExecute)) {CODE(caption=Approve multiple pages at the same time - for activation on existing sites)} {LISTEXECUTE()} {pagination max="5000"} {filter field=wiki_approval_state content=pending} {ACTION(name=Approve)} {step action=wiki_approval} {ACTION} {LISTEXECUTE} {CODE} {CODE(caption="Mass approval of all pages in some categories")}{LISTEXECUTE()} {pagination max="5000"} {filter categories="40 OR 41 OR 97 OR 231"} {filter language="fr"} {sort mode=title_asc} {filter type="wiki page"} {ACTION(name=Approve)} {step action=wiki_approval} {ACTION} {LISTEXECUTE}{CODE} You also may want to increase "Lucene Maximum Results" and "Lucene Maximum Result Set Limit" from tiki-admin.php?page=search !!# FAQ #__Q:__ How do Approvers become aware of pending Flagged Revisions? +~~#06F:__A:__ --By monitoring email notifications. There is currently no status reporting.-- See Above~~ +%%% #__Q:__ Can emails be sent to different Approvers for different pages or sections? +~~#06F:__A:__ Approval permission can be assigned to a category. This won't work for sections, but you can assign different pages to different categories, and each approver needs to be in an approval group, then assign category approval permission to that group.~~ +%%% #__Q:__ Can certain users be permitted to just make approved edits directly? That is, an admin editing a page still needs to click Approve Edits; seems redundant. +~~#06F:__A:__ No. In fact, the purpose of revision approval is to review the content before making it public. Just because an administrator does it does not mean it should go live right away.~~ -=alias names for this page=- (alias(FlaggedRevisions)) | (alias(FlaggedRevision)) | (alias(Flagged Revision)) | (alias(Revision Approval)) | (alias(RevisionApproval))