Welcome to the Jazz Community Forum
Which is the right way to restrict users from delivering to a Stream?
I have "Master Project Area" and its process is consumed in "Child Project Area". The "Child Project Area" has "StreamA", "StreamB" and "StreamC". I want to restrict developers from delivering to "StreamA" only.
Should I add a precondition ("Restrict ChangeSet Delivery To Components In Stream") in "Master project area"? or in "Child Project Area"?
If I add in "Child Project Area", will it override the master process configuration for other preconditions for e.g. "Deliver"?
Or Should I change the "Owned By:" of each component in "StreamA" to be "Master Project Area" instead of "Child Project area". So users who are not part of "Child Project Area" will not be able to deliver to it.
Please suggest which is the most appropriate way?
3 answers
WRT your original question, whether to put the deliver precondition in the master or child project area, that depends on whether you want the precondition to apply to every child project area using that master project area (in which chase, put it in the master project area), or if you want the precondition to apply to just a particular child project area, in which case you would put it in that child project area.
WRT whether the child precondition overrides the master precondition, the child precondition definition for an operation overrides the master precondition, unless the master precondition declares it to be final, in which case the master precondition would take precedence.
WRT whether you should change the ownership of the components themselves, the ownership of the component determines read access to the component, and has no affect on who can deliver to that component in a given stream (except, of course, that if you do not have read access to a component, you cannot do anything to it, including deliver to it, since you cannot even see it).
WRT why Test_Jazz_Developer can still deliver to the stream, remember that for permissions, if *any* role held by that developer can deliver, the developer can deliver. Also, remember that the search for the permissions for a given role starts at the "nearest" process area (in this case, the child project area). So to do your testing, first make no role in either the master or child project area have deliver permission. Then incrementally add back deliver permission to the roles that should have it, and that should make it clear where the Test_Jazz_Developer is being given deliver permission.
WRT whether the child precondition overrides the master precondition, the child precondition definition for an operation overrides the master precondition, unless the master precondition declares it to be final, in which case the master precondition would take precedence.
WRT whether you should change the ownership of the components themselves, the ownership of the component determines read access to the component, and has no affect on who can deliver to that component in a given stream (except, of course, that if you do not have read access to a component, you cannot do anything to it, including deliver to it, since you cannot even see it).
WRT why Test_Jazz_Developer can still deliver to the stream, remember that for permissions, if *any* role held by that developer can deliver, the developer can deliver. Also, remember that the search for the permissions for a given role starts at the "nearest" process area (in this case, the child project area). So to do your testing, first make no role in either the master or child project area have deliver permission. Then incrementally add back deliver permission to the roles that should have it, and that should make it clear where the Test_Jazz_Developer is being given deliver permission.
Comments
Hi Geoff,
This particular situation I don't think applies here, but I'd be curious your thoughts in a situation where it is not acceptable to allow customizations in the child area. From my investigation and testing, it's not possible.
In the master template, you are allowed to choose streams from any project area to set the condition on, however it will only let you choose teams from the Master area.
So you would have to recreate teams in the master project area for every child project area you want to customize and limit permissions to.
Even with doing this (which is likely not acceptable anyway), the precondition didn't always seem to work as expected.
In this other situation, we are trying to work around by have one stream per team, then automating updating a common stream which only can be delivered to from "build master", only pulling changes from one component per stream.
I would respond that it is not acceptable for it to not be acceptable to allow customizations in the child area. You should not be defining anything in the master project area beyond re-usable process configuration definitions ... so no team areas, streams, work items, releases, timelines, etc. I wasn't sure how your last paragraph about one stream per team and updating a common stream relates to this thread.
Hi Pravin,
Since you restricting delivery to every component in the stream, you should be able to set the owner of the Stream to a Team Area in your Child Project Area. This team area should not contain anyone who you don't want to allow delivery.
Then, in the Team Permission in the process configurations, make sure that "Everyone" does not have permission to deliver change sets to a stream. (By default, they will not).
Hope this helps!
Melissa
Since you restricting delivery to every component in the stream, you should be able to set the owner of the Stream to a Team Area in your Child Project Area. This team area should not contain anyone who you don't want to allow delivery.
Then, in the Team Permission in the process configurations, make sure that "Everyone" does not have permission to deliver change sets to a stream. (By default, they will not).
Hope this helps!
Melissa
Comments
Hi Melissa,
I created a team area in child project area. Made it to be owner of StreamA. This team area has only one member "Build_Master" added to it.
In the Team Configuration > Permission (of Master Project Area), in the process configurations, ensured that "Everyone" does not have permission to deliver change sets to a stream.
Then tried delivering a change by user "Test_Jazz_Developer" and was able to deliver. What can be done?
Can you try making sure that Test_Jazz_Developer is not a member of the parent project area and see if that prevents them from being able to deliver?
1 vote
Thanks!
Here is the solution that I have and looks like is working ok:
My streams are in Child Project Area. If want to restrict developers from delivering to it. I change the "owner" of stream to be "Master". Now since none of the developers are members of master project area. They get error "You do not have permission to deliver".