You should separate your AccessGroup definitions between "Visibility" and "Permissions.

Create a "Visibiliy" group for your Project, say "Project A Visibility". Assign all users to this group who should be able to see this. You could subgroup other groups to accomplish this. Associate "Project A Visibility" with "Project A".

Next, create your Permission group. For your scenario you'd need two. Build Engineer and Guest. Ensure these Access Groups have the necessary permissions to accomplish the tasks you need. Obviously, the Guest group will have limited permissions. You can use the default Build Engineer and Guest groups after reviewing the currently assigned permissions. Now, assign users to each grop based on which they need to be in. If using LDAP, you can do this via an LDAP group DN which the users belong to. The LDAP group DN for Build Engineer should contain only the users who should have those Permissions. If you use "Map Access Groups" in your LDAP domain, these assignments will occur at login time automatically, thus allowing you to manage your groups from LDAP.

Finally, one important thing to note. Permissions are GLOBAL. If you give user A the permissions in the Build Engineer group, that user will have them for any project that they have visibility to. That's important as it prevents you from being able to allow a specific user from having Read access to Project A and Edit access to Project B.

Hope this helps.

Regards,
Pete
Build Forge/Team Build Developer

Hi,

I have a few projects that build engineer group has access permissions.

I want to give the guest group read permissions to all projects even if they are not the access group of the project.

Is there a way to do it?

Thanks,
shiran

Hi shirans, just in case you still haven't resolved this or for anyone else that has the same issue, I wanted to let you know what I did to get this to work.

I basically followed pbirk's instructions:
*Created visibility group only with "View build logs" permission
*Added Build Engineer as a subgroup of the visibility group
*Assigned access control to the visibility group for all of the projects (and libraries) that I want them to see
*IMPORTANT: Ensure all steps in each project/library that you want the visibility group to see have their access set to default (preferably) or the visibility group

The last point was the kicker for me. For some reason most of my steps were hard assigned to the build engineer.

Once this is done any subsequent job will be visible and have their steps (and step output) visible to the visibility group. This does not affect previous build logs as they maintain the original access control settings.

Hope this helps.

What if I have group A and group B.
Members of Group A should be able to start all projects owned by group A and not the projects owned by group B BUT they A should be able to see the logs of builds owned by group B.


Is it possible to implement this in Buildforge ?


Regards,

Geoffroy

You should separate your AccessGroup definitions between "Visibility" and "Permissions.

Create a "Visibiliy" group for your Project, say "Project A Visibility". Assign all users to this group who should be able to see this. You could subgroup other groups to accomplish this. Associate "Project A Visibility" with "Project A".

Next, create your Permission group. For your scenario you'd need two. Build Engineer and Guest. Ensure these Access Groups have the necessary permissions to accomplish the tasks you need. Obviously, the Guest group will have limited permissions. You can use the default Build Engineer and Guest groups after reviewing the currently assigned permissions. Now, assign users to each grop based on which they need to be in. If using LDAP, you can do this via an LDAP group DN which the users belong to. The LDAP group DN for Build Engineer should contain only the users who should have those Permissions. If you use "Map Access Groups" in your LDAP domain, these assignments will occur at login time automatically, thus allowing you to manage your groups from LDAP.

Finally, one important thing to note. Permissions are GLOBAL. If you give user A the permissions in the Build Engineer group, that user will have them for any project that they have visibility to. That's important as it prevents you from being able to allow a specific user from having Read access to Project A and Edit access to Project B.

Hope this helps.

Regards,
Pete
Build Forge/Team Build Developer

Hi,

I have a few projects that build engineer group has access permissions.

I want to give the guest group read permissions to all projects even if they are not the access group of the project.

Is there a way to do it?

Thanks,
shiran

In other words, is it possible to have a visibility on some projects (and their build logs) without the ability to start them, while at same time have the ability to start some other projects ?

In other words, is it possible to have a visibility on some projects (and their build logs) without the ability to start them, while at same time have the ability to start some other projects ?

permissions in buildforge are global to all objects you can see.

you grant permissions at the user level, not the project level.

A good way to look at it is that access groups grant permissions to users, and access groups filter what objects users can see. If you want a different set of permissions, you need a different user object.

I think this security model is a bit unusual in the sense that it combines things that are conceptually different: roles and groups, ownership and access.
I also find that this subject is not clearly documented - and yes, I have read the white paper related to BF permissions.
Do you have any real world examples of how groups can be structured ?

The last topic I covered in my deploying buildforge whitepaper has an example that I took from a customer's installation. The group names and user names are simply placeholders.

http://jazz.net/library/article/584

Configuring access groups of users who can see and control features

Rational Build Forge uses access groups to control two critical aspects of security: the ability of a user to see a Rational Build Forge object and permissions to act upon those objects. The best way to use access groups in Rational Build Forge is to effectively have two sets of access groups. One set limits what objects users can see; the other set controls what permissions users have. For example, if you have two teams whose projects you want to isolate, you can place their users in different access groups. You might create the group widgets for your teams that work with the widget group and the group wodgets for your teams that work with the wodget group. Putting management console users in these groups would limit what Rational Build Forge objects they can see. The widgets team cannot access the wodget projects, and the wodget team cannot see the widget projects. Administrators need to be able to see both groups. If you create a group for administrator access and make that group a subgroup of both the widgets and wodgets groups, members of that subgroup will be able to see both projects. (A subgroup inherits the accessibility of its parent group.)

This example does not discuss permissions. Permissions are separate from visibility and apply to all objects that users can see. Because permissions are separate, create a separate set of groups to manage permissions. Set up access groups that manage permissions to separate management of different sets of permissions you want to grant to your different users.

For example, perhaps a user named Allen requires access to edit projects and run projects using the devtest build servers (access levels on selectors control that access). Perhaps a user, Betty, must not have access to edit projects but must be able to run projects on production build servers. To manage these permissions, create two groups for access and two groups for permissions. Put Allen in the devtest group (which has access to the devtest build servers) and both the proj_run and proj_edit groups that have been assigned the needed permissions to run and edit projects. Then put Betty in the prod_operators group (which has access to the production build servers) and also in the proj_run group. With these groups, Betty can run projects, but not edit them. Also, while Allen can run projects, he cannot do so on production servers because he does not have the access to see them.