This article covers the full range of trunk and branch permissions possible. It is intended to complement the article here which explains high level concepts and processes around branching: in practice it is typical that there needs to be greater control around the branching workflow than that implied by that article and the article below explains how to set the permissions to match your particular requirements.
Quick set up
A basic, quick set up to get a trunk/branch combination working is as follows.
Tag the trunk with : -
branch:role edit:role
and tag the branch with
edit:role
Detail
The branch tag gives permission to perform branch actions on a node. By tagging the trunk with:
branch:role
you are saying that that role has the ability to work in a branch on that dataset, however, in addition, access to these branches has to be given explicitly.
Suppose there is a trunk dataset D with branches B1 and B2: consider the different impacts of the branch: tag
- If D is tagged with branch:user (only), the observable effect by a user is nothing.
- If D is tagged with branch:user and D is tagged with view:user then users can see D, not edit D, and create and save branches off D, but not push branches. Users cannot see B1 and B2.
- If D is tagged with branch:user and B1 is tagged with edit:user then users cannot see D. Users can see B1 and save and edit B1, but not push B1. B2 is not visible.
- If D is tagged with branch:user and D is tagged with view:user and B1 is tagged with edit:user then users can see D, create and save new branches on D and work in and save B1. B2 is not visible.
The above overview is to introduce the branch tag only, and as an example is still simplified at dataset level - see the relevant article - as view:user at dataset level is insufficient to permit pushback from branches.
Branch: syntax and meaning
In terms of a general approach to branching, if a dataset is tagged
branch: allocated_role_name
then the nodes inside any branches derived from the trunk can be edited (including delete) by any individual who is assigned allocated_role_name in the Users table
As a simplified case study, consider the hrbp role in the tags below:
The branch: tag is important on the Trunk in addition to the view: tag.
In the image above, the "update" tag is needed to extend permissions on the Trunk to the Branch.
Commentary
Note that the user must also be given explicit permission to view the branch over and above the trunk, otherwise they will not be able to see it on their screen.
Although it is implied that branch: tag could also be thought of as meaning "able to edit in branch" only loosely can we say this as:
- branch: on a trunk does not give access to branches without view
- the ability to change the name of the branch comes from edit: on the branch
- properties belong to the trunk, no matter the permissions on the branch
- the ability to push back is defined by the permissions on the trunk i.e. view: on trunk will not give push
Advanced use case
The objective here is to ensure:
• Some users to get view access to specific branches
• Other users to make changes within specific branches
Approach
Tag trunk with:
branch:canchangebranches view:cannotchangebranches
Tag a branch with:
view:branchname
Assign individuals appropriate role-based permissions via Users tab/dataset:
Role: user,canchangebranches,branchname
-> Effect: individuals with this role-set allocated can update the branch
Role: user,cannotchangebranches,branchname
-> Effect: individuals with this role-set allocated can view the branch
Comments