Hiding branches using security

How can I set up plastic security so that developers can only see their own branches plus the main one and the maintenance?
I was asked this a couple of days ago and now I’ll try to give a detailed answer and explain, step by step, how to set it up with plastic.
Secure your rep server
The first step will be securing the repository server. Do you know what the rep server is? Well, it is just the server which is handling all the repositories, and as you know, repositories are the ones which actually contain the data (branches, revisions, items, labels...)
Why is such a good idea to secure the rep server? Plastic implements a whole security hierarchy. Everything inherits from the repserver, then the repository, then the actual objects inside each rep. Take a look at the following diagram for more information:



The first thing we’ll do is to allow access to the repserver only to our allowed users. In our case I’ll be granting access to management, development and the special users named OWNER.
To set up repository server permissions from the GUI go to the repository view, right click on a rep and go to repository server permissions....



Please note both the owner and the management group have all the permissions granted, but developers will have the view permission not set. Check the following figure:



This way the developers won’t be able to view any object they don’t have created, but we’ll grant access to the right branches, items and labels so they can work correctly. The permission granted to the owner ensures they can work on the branches they create, as the initial question asked.
Note: check you set up permissions with a user belonging to the right administrative group, management in my case.
Grant access to the code!
Right now no developer can access the code because all items inherit from the repository, and the repository from the repserver, and the repserver doesn’t have view access set for developers.
So, as an administrator go to your item’s view, right click on the root item, and go to item’s permissions as the following figure shows:



Once you’re there make sure developers get the view permission set!



Securing the branches
Now it’s the turn for the branches. In the example we want all developers to view the main branch and the branches they create. The second requirement is already achieved due to the owner permissions at the repserver level.
To actually allow developers to view the main branch and the maintenance (and any other branches you want to make available) go to branch permissions and enable the view permission.



Check everything works
Check the following figure. The plastic instance on the left is run as a privileged user, while the one on the right corresponds to a developer. Note that the developer can only list the main and maintenance branches and the one he has created, but not the one created by the admin user (/main/task001pablo) in the sample.



Wrapping up, don’t forget the labels
If you remember the security hierarchy introduced above, you’ll notice that labels won’t have view permissions either. So after creating a new one, make sure you grant the right access.



The plastic security mechanism gives users huge flexibility. The purpose of setting permissions doesn’t always need to be related with preventing unwanted access but also being to enforce certain development policies. I’ll be talking about it on a future post.