Overview
The {add-restriction}
macro is used to add View or Edit content-level permissions.
When using the add-restriction
macro 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
Where to use it?
Optional.
One or more {add-restriction}
macros can be put in a {trigger}
macro.
If you want to remove these restrictions you can use the {remove-restriction}
macro.
You can remove/add or add/remove restrictions using these macros in any order.
If you want to add restrictions immediately after removing restrictions of the same type, you can use the {set-restrictions}
macro instead†.
Restrictions don't give users permissions to content, but rather limit the users who have those permissions.
For example, if everyone has edit/view permissions for the space and you add edit restrictions to a page for user A and user B, only user A and user B can edit the page, and everyone else just view the page.
Parameters
Parameter | Required | Default | Notes |
---|---|---|---|
| What type of permission to set?
| ||
Note: The permissions are set using Confluence's content-level permissions system and can thus be altered via the padlock icon. | |||
| One or more users to assign
| ||
| One or more user groups to assign
| ||
† In some cases, due to Confluence permission threads, rather than using The |
Example
{workflow:Restrictions} {state:Test} {state} {trigger:pagecreated} {add-restriction:type=view|user=@user@|group=moderators} {trigger} {workflow}
All examples
-
-
Require Parameters on State Transitions — Require workflow parameter values to be set before moving into a workflow state.
See also
External Links: