While the short, official answer to how you can assign the same user different permissions on different Build Forge projects is “you can’t”, in truth, there is almost always a way that you can. All it takes is thoughtful use of different access group assignments to different parts of the project.
One example is to allow a user visibility to a large group of projects and job results, while allowing them to actually run only a subset of those projects.
This is useful when you have deployment or build projects in multiple environments. You may want developers to be able to run the projects in unit test environments, but limit this ability to only specially authorized personnel in more controlled environments. At the same time, you might want the developers to see the job output for a variety of reasons.
Consider the following example:
Set up 3 groups as follows:
|ViewA||View permissions only||Mary, James, Henry|
|ViewB||View permissions only||Mary|
|RunPermissions||All permissions needed to run projects||Mary, James, Henry|
Now create two projects, Project_1 and Project_2. For Project_1, assign the project, steps, server, selector and all other objects to the Build Forge access group “ViewA”
In Project_2, you will also assign all Build Forge objects to “ViewA” except for the selector. Assign the selector to the group “ViewB”
The result will be that Mary, James, and Henry will all be able to run and view Project_1. All three can see the project and all of it’s artifacts, and all 3 have permissions to run any project they can see.
Only Mary will be able to run Project_2, however, since she is the only person with access to the selector. James and Henry will still have access to view the projects and any associated job runs, but if they attempt to run it, will fail with the Build Forge error “unable to select a server.”
There are several other ways to achieve this same objective. I will leave it as an exercise for the reader to think of some variations on this theme.
A deeper discussion of Build Forge access groups may be found in the post titled: “Access Groups: A Practical Approach.”