set-restrictions macro
Overview
The {set-restrictions} macro is similar to the {add-restriction} macro in that it sets either View or Edit permissions. However, before doing so, it removes any existing permissions of that type.
Where to use it?
Optional.
One or more {set-restrictions} macros can be put in a {trigger} macro.
Restrictions don't give users permissions to content, but rather limit 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 | Ver |
|---|---|---|---|---|
|
| What type of permission to set?
| 4.5 | |
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
| 4.5 | |
|
| One or more user groups to assign
| 4.5 | |
| ||||
Invalid users/groups will be ignored and the macro will set the restrictions for the valid users defined (from v6.16.14+)Example
This...
{workflow:Restrictions}
{state:Test}
{state}
{trigger:pagecreated}
{set-restrictions:type=view|user=bob}
{trigger}
{workflow}
...is equivalent to:
{workflow:Restrictions}
{state:Test}
{state}
{trigger:pagecreated}
{remove-restriction:type=view}
{add-restriction:type=view|user=bob}
{trigger}
{workflow}
Using {set-restrictions} (markup on the left) may help avoid permissions errors in the interim period between clearing permissions and adding new permissions (markup on the right).
All examples
-
-
Require Parameters on a state transition — Require workflow parameter values to be set before moving into a workflow state.
-
See also
External Links: