Hide Build results. Possible in RTC 4.0.5?
Can we avoid showing build results to users of specific role or team?
I tried and it looks like it if a user is added to a team, the user can see virtually everything.
This also means that the user can see Build results belonging to team to which he/she has no access to. Worst thing is that they can see build logs and downloads. Can this be avoided?
I see that we cannot make another PA as the owner of the build definition since this is not allowed. Only way is to recreate build in another PA. But this leads to another problem since we cannot delete the existing build definitions as we need for audit purposes. So we might need to move the existing build definitions to a team which is archived. The build definitions may not show in eclipse by default, but it is possible to see "archived" build definitions in eclipse & in web, which leads to viewing build results
What options do I have to restrict the viewing of build results for the team areas to which the use has no access to
Thanks
I tried and it looks like it if a user is added to a team, the user can see virtually everything.
This also means that the user can see Build results belonging to team to which he/she has no access to. Worst thing is that they can see build logs and downloads. Can this be avoided?
I see that we cannot make another PA as the owner of the build definition since this is not allowed. Only way is to recreate build in another PA. But this leads to another problem since we cannot delete the existing build definitions as we need for audit purposes. So we might need to move the existing build definitions to a team which is archived. The build definitions may not show in eclipse by default, but it is possible to see "archived" build definitions in eclipse & in web, which leads to viewing build results
What options do I have to restrict the viewing of build results for the team areas to which the use has no access to
Thanks
Comments
Winston Enos
Aug 08 '14, 12:47 p.m.As you have already seen, you cannot move build engines and build definitions to different Project Areas (you'll get an UnsupportedOperationException.)
As I understand it, you have users assigned to a team, but you only want a subset of users on that team to be able to view the build results.
Could you create a new team within the Project Area that will specifically only hold users that should be able to view build results and then assign ownership of the build engine(s) and build definition(s) to that team?
Even if you could restrict users of a team, by name, to not see the build results (which I don't think you could do anyway in RTC) it would become a large maintenance point, and the onus would be on an admin to not forget to add a user both to the 1) team and the 2) ignore list whenever they had to add a new user who shouldn't see these artifacts.
1 vote
Karthik Krishnan
Aug 08 '14, 10:20 a.m.Hi @winstonenos This is exactly what i have done
PA -> TA1, TA2, TA3
Build Def owner is TA2
But members from TA1 & TA3 can see TA2 build definitions. Logically this shouldn't happen but somehow the user in TA1 & TA3 can see.
Winston Enos
Aug 08 '14, 12:06 p.m.Ah, yeah, I see what you mean, I just mocked it up and I'm able to do the same.
RTC 4.0.6 added the ability to create folders under 'Build' to organize your build definitions under them, and those folders can be assigned to a project or team area, however, it will not restrict other teams from viewing them. It only restricts them from modifying their contents. It seems the Project/Team assignment does not restrict visibility, only write-access.
RTC also added the ability to have Access Groups (https://jazz.net/library/article/837) but I wasn't able to get this to work, the build definitions aren't a modifiable template that I saw was available for adding the presentation editor attributes.
One option you could go with (since you indicated that you need to retain the build information, and you also can't move the build engines/definitions) is to create a new project and move all the project data there (components, streams, work items, workspaces, everything) and then re-name this project and lock down the access-control.
1 vote