It's all about the answers!

Ask a question

Cascading Permissions Rational Automation Framework


Gerald Gordon (7011419) | asked Aug 26 '13, 9:36 p.m.
 Team,

I have a question about permissions for the Rational Automation Framework vs. 3.0.0.1.  I started reading existing WAS and Portal environments into the tool and creating cell definitions using Env Gen wizard.  Now I want to give access to my team to projects, while making sure access is governed for Production Environments.  

After running the Env Gen wizard I notice that the projects generated were created with the access level Build Engineer.  To control access levels to projects, I created a custom group and included Build Engineer as a sub group.  But when I assign new users to the custom group, they get access to the project level as expected but they can't see any steps.  After future investigation, I realized that all of the individual steps in the project have Build Engineer for access which may explain why my people in the custom group does not see the steps ( but this is a little misleading as well, because my custom group also has Build Engineer as a sub group ). Is there a way to cascade access from the project level down to the individual steps without doing it manually?  ( scroll to the right to see permissions on the image )

see picture enclosed.

Thank you

Accepted answer


permanent link
Ryan Ruscett (1.0k413) | answered Aug 27 '13, 8:20 a.m.
 Hello Gerald,

You have a custom group, that has Build Engineer as a subgroup. This will do exactly what you mentioned. The next thing to do, is to go into your custom group, and manually add/remove permissions. Giving the group as a whole, only with the permissions you want them to have. I don't recommend changing the Build Engineer group because it is your RAFW default user defined in the buildforge.properties. And it could cause issues with further administration of your environments when changing permissions. Creating a group, add Build Engineer as the subgroup and manually add/remove permission to the created group is your best route.

The more technical reason is below. 
 
To extend access to a resource such as the project steps you mentioned, to a particular group, select that resource and change it's access field to the groups name. You have by default Build Engineer. If you look in the RAF_HOME directory, and you go into the buildforge.properties file. You will see the RAFW_BF_GROUP is assigned to Build Engineer by default (value =6). So no matter what environment you read it, it will be Build Engineer of all of it's parts. So you would have to changes this every time which is not acceptable. 
CAUTION: Whatever user you use for this, MUST also have BUILD ENGINEER level access. 
An alternative would be to create a custom group and set Build Engineer as the Control Group. Then change it to reflect the group in the buidlforge.properites. Then every environment read in would be part of the custom group. and you can assign people to the custom group. Add and modify permissions as you see fit. But there are a lot of ups and downs to this. So I don't recommend doing it unless you have read up on all the security information.  I have provided some links below.


If you need further assistance. Please feel free to open a PMR. The support team will be happy to help you. 



Gerald Gordon selected this answer as the correct answer

Comments
Gerald Gordon commented Aug 27 '13, 11:08 a.m.

Thank you! 

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.