Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
Teams
, (opens new window)

Comala Document Management for Data Center
Results will update as you type.
  • Overview
  • Get started
  • User Guide
  • Workflow Authoring Guide
  • How to's and tutorials
    • Mini tutorials
    • Add an approval counter to fast-track an approval
    • Add parallel approvals in a state
    • Who can be assigned, or assign users to an approval
    • Use attachment events in workflow triggers
    • Use blog post events in a workflow trigger
    • Using comment events in workflow triggers
    • Customize approval decision buttons
    • Dynamic page header using a metadata value and triggers
    • Exporting to PDF with K15t PDF Exporter
    • How can I fast-track a single rejection or a single approval decision
    • Using different styles in a trigger message notification action
    • Using Read Confirmation events in workflow triggers
    • Select the workflow that is applied using content labels
    • Using labels when applying a workflow in space mode
    • State expiry dates
    • Use metadata to increment composite major, minor, patch content version on an approval decision requiring a parameter
    • Using set-message and metadata to display different information for the draft and published content
    • Updating a mandatory reviewer for an approval assigned using a workflow parameter
    • Publishing to another space in the same instance - different-space publishing
    • Require Parameters on a state transition
    • Publish to another instance using advanced remote-space publishing
    • Add, remove and set page restrictions using a workflow trigger
    • Using a CQL filter in the document states report macro to report on grandchildren of a page
    • Make tasks disable a review
    • Adding page activity to email
    • Add a label to child pages
    • Restricting drafts to specific users using the add-restriction macro
    • Use metadata to increment a content version
    • Add workflow review information to a header for inclusion in a page export
    • Tutorials ...
    • Using workflow parameters to create reviewer teams in a space
  • Reporting Guide
  • Administration Guides
  • Developer Guides
  • Integration Guides
  • Migrating to Confluence Cloud
  • Release notes
  • Support
    You‘re viewing this with anonymous access, so some content might be blocked.
    /
    Add, remove and set page restrictions using a workflow trigger
    Updated Nov 14, 2024

    Add, remove and set page restrictions using a workflow trigger

    1 Overview | 2 Add a restriction | 3 Remove a restriction | 4 Remove then Add restrictions → Set restrictions | 5 Blocking changes to content

    Overview

    These examples summarise the macros you can use to change page restrictions.

    • add-restriction

    • remove-restriction

    • set-restrictions

    These macros are used as part of a workflow trigger to set the content permission for the specified users and change the capability of these listed users.

    The Confluence user(s) or a user who is a member of a Confluence group listed in the macro will have the type of permission (view, or edit) specified in the macro.

    Other users who are not listed in the macro will have their permission for the content restricted.

    Add a restriction

    In this example, when the workflow transitions to the Review state, we use the add-restriction macro to restrict editing to the document creator and members of the reviewers group:

    {workflow:name=Edit restrictions} {state:Editing|submit=Review} {state} {state:Review} {state} {trigger:statechanged|state=Review} {add-restriction:type=edit|user=@creator@|group=reviewers} {trigger} {workflow}

    Action

    Type

    user / group

    Result

    Action

    Type

    user / group

    Result

    ​add-restriction

    ​view

    @creator@

    • only creator can see the content

    • no other users will be able to access the content

    add-restriction

    edit

    reviewers

    • only users who are members of the Confluence reviewers group will be able to edit the page

    • all other users will have view permission (unless separately restricted)

    Remove a restriction

    In this example, we use the remove-restriction macro to remove the page restrictions if the content review is approved.

    {workflow:name=Edit restrictions} {state:Editing|submit=Review} {state} {state:Review|approved=Published|rejected=Editing} {approval:Review} {state} {state:Published} {state} {trigger:statechanged|state=Review} {add-restriction:type=edit|user=@creator@|group=reviewers} {trigger} {trigger:pageapproved|approval=Review} {remove-restriction:type=edit|user=@creator@|group=reviewers} {trigger} {workflow}

    Using remove-restriction will simply remove the specified permission type for the named user(s) on the content.

    If you want to remove all added permissions of a specific type simply do not include users or groups in the remove-restriction macro. 

    For example, when the following two macros are used together in a trigger, one will remove all added edit permission restrictions, the other will remove all added view permission restrictions.

    {remove-restriction:type=edit} {remove-restriction:type=view}

    You must include a separate macro for each type of permission.

    The macro will not remove any page-level restrictions or other permissions that have been previously added.

    Remove then Add restrictions → Set restrictions

    If you remove restrictions of a certain type, then add restrictions of the same type, it can cause errors. This is due to the way Confluence works internally (database connections, long-running threads... reasons).

    To avoid this possible issue, it's sometimes safer to use the set-restrictions macro when you need to remove, then add, restrictions of the same type.

    In the example below

    • when the state changes to Review, only the content creator (Matilde Sipes in the example) and users who are members of the Confluence user group reviewers are able to edit the content

       

    • when the review is approved, using set-restrictions in a trigger on the pageapproved event we clear all existing edit restrictions and then only allow users who are members of the Confluence user group maintenance to edit the published content

       

    {workflow:name=Edit restrictions} {state:Editing|submit=Review} {state} {state:Review|approved=Published|rejected=Editing} {approval:Review} {state} {state:Published} {state} {trigger:statechanged|state=Review} {add-restriction:type=edit|user=@creator@|group=reviewers} {trigger} {trigger:pageapproved|approval=Review} {set-restrictions:type=edit|group=maintenance} {trigger} {workflow}

    The action of the set-restrictions macro initially removes all previously added restrictions on the content and then adds the permission for the maintenance group of users.

    Be aware that

    • a user with administrator permission will still be able to edit the content

    • an admin user and anyone who has been given edit permission using the macros will be able to change the page-level restrictions

    • a user who is not listed in the restrictions macro as having edit permission will be able to view the page-level content permissions. They will however not see the workflow state breadcrumbs on the page

    One problem with our example is that any transition back to the editing state will retain the permission restrictions.

    We can simply add the following trigger to remove the added content page permissions

    {trigger:statechanged|state=Editing} {remove-restriction:type=view} {remove-restriction:type=edit} {trigger}

    When using the add-restriction or set-restrictions the specified Confluence permission will be added to the users listed. If there are other users who have Confluence permissions for the content but are not listed in the macro, these users will have their permissions restricted.

    Blocking changes to content

    In this example, edits to the content are "blocked" in the final state. Effectively forbidding all changes in the content except by members of the confluence-administrators group.

    {workflow:name=Restrictions example} {state:Draft|approved=Published} {approval:Review} {state} {state:Published} {state} {trigger:pageapproved|approval=Review} {set-restrictions:type=view|group=confluence-users} {set-restrictions:type=edit|group=confluence-administrators} {trigger} {workflow}

    Need support? Create a request with our support team.

    Copyright © 2005 - 2025 Appfire | All rights reserved.

    {"serverDuration": 16, "requestCorrelationId": "f3a87471eff443faa1bfe48c8e1f02a2"}