set-restrictions macro

1 Where to use it? | 2 Parameters | 3 Example | 4 All examples | 5 See also

Overview

The set-restrictions macro is similar to the add-restriction macro in setting Confluence View or Edit permissions to named users. However, before doing so, it removes any existing permissions of that type.

Restrictions don't give users permissions to content, but rather limit who has those permissions.

For example, if everyone has edit/view permissions for the space, adding edit restrictions to a page for two users - user A and user B - means that only these two users - user A and user B - can edit the page. Everyone else can view the page.

Where to use it?

Optional.

One or more set-restrictions macros can be put in a trigger macro.

Parameters

Parameter	Required	Default	Notes	Ver

Parameter	Notes	Ver
`type`	What type of permission to set? `view` – assign the user/group view permission `edit` – assign the user/group edit permission	4.5
`type`	The permissions are set using Confluence's content-level permission system and can thus be altered via the padlock icon.	4.5
`user`	One or more users to assign `type` permission to: comma-separated list of usernames supports Value References	4.5
`group`	One or more user groups to assign `type` permission to: comma-separated list of user groups supports Value References	4.5
At least one user or group must be specified. Both can also be used at the same time.
Invalid users/groups are ignored and the macro sets the restrictions for the valid users defined (from v6.16.14+).

Example

This is for a new page ...

{workflow:Restrictions}
   {state:Test}
   {state}
   {trigger:pagecreated}
      {set-restrictions:type=view|user=bob}
   {trigger}
{workflow}

... and is equivalent to:

{workflow:Restrictions}
   {state:Test}
   {state}
   {trigger:pagecreated}
      {remove-restriction:type=view}
      {add-restriction:type=view|user=bob}
   {trigger}
{workflow}

This is for a new blog post ...

{workflow:Restrictions}
   {state:Test}
   {state}
   {trigger:newscreated}
      {set-restrictions:type=view|user=bob}
   {trigger}
{workflow}

... and is equivalent to:

{workflow:Restrictions}
   {state:Test}
   {state}
   {trigger:newscreated}
      {remove-restriction:type=view}
      {add-restriction:type=view|user=bob}
   {trigger}
{workflow}

Using the set-restrictions macro (markup on the left) may help avoid permissions errors in the interim period between clearing permissions and adding new permissions (markup on the right).

If using a workflow for blog posts and pages, add both triggers to add the view restriction on creating a blog post or a page.

{workflow:Restrictions}
   {state:Draft|approved=Approved}
   {approval:Review|assignable=true}
   {state}
   {state:Approved|final=true|updated=Draft}
   {state}
   {trigger:newscreated}
      {set-restrictions:type=view|user=bob}
   {trigger}
   {trigger:pagecreated}
      {set-restrictions:type=view|user=bob}
   {trigger}
   {trigger:newsapproved}
      {remove-restriction|type=view}
   {trigger}
   {trigger:pageapproved}
      {remove-restriction|type=view}
   {trigger}
   {trigger:statechanged|state=Draft}
      {set-restrictions:type=view|user=bob}
   {trigger}
{workflow}

These examples use the newscreated and pagecreated events to limit the page-level permissions. They only work when the workflow is a space workflow and the workflow is enabled in the space at the time the page or blog post is created.

All examples

Page:

Add, remove and set page restrictions using a workflow trigger
Page:

Require Parameters on a state transition — Require workflow parameter values to be set before moving into a workflow state.
Page:

Restricting drafts to specific users using the add-restriction macro