Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Read only component - vs. do not allow deliver to a stream

Questions
Tags
Users
Badges
Dr. Hans-Joachim Pross
JAZZ DEVELOPER (1.1k●44●58) edited
Sep 28 '15, 8:12 a.m.
I'd like to have a component with reusable stuff.
This component should be changed only by a specific reuse team, but all other teams should be allowed to read that stuff.
I have a project area and below a team area for that reusable stuff. The same project area has other teams which should have read only access to the stuff from the reuse team.

I can configure my project in a manner, that only the reuse team is allowed to deliver to the reuse main stream.
But others could modify the component, check in and deliver to other streams.

Is there a way to inhibit changes to the files in that component (for other teams than the reuse team) and not only to deliver those to a specific stream?

If not, what is the use of allowing changes to (reusable) stuff by not responsible teams?

0 votes

Comments
Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Sep 28 '15, 8:33 a.m.
Have you read and tried https://jazz.net/library/article/215#componentadvisor ? Restrict delivery to a component in a stream, from my perspective only protects the component in said stream. If one creates another stream with the component, he could still deliver.

Dr. Hans-Joachim Pross
JAZZ DEVELOPER Sep 28 '15, 8:39 a.m.
It's also on a do not deliver to a stream base, and not a component based solution.

Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Sep 28 '15, 8:43 a.m.
Dang, I missed that line.

1 answer
5,498 views
0 votes

One answer

Permanent link
Geoffrey Clemm
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER (30.1k●3●34●35) Sep 28 '15, 9:39 p.m.
It is my (strongly held :-) opinion that if someone has read access to a component, they should always be able to make private changes to that component in their own workspace or their own stream.  If you disallow this, you are just forcing them to make those changes in an uncontrolled way in the file system (if they have read access to the component, they can modify it in the file system).   Anyone who is not interested in those changes can ignore them, and restrict who/what can be delivered to their streams (which is why component write access is controlled at the stream level).

1 vote

Comments
Dr. Hans-Joachim Pross
JAZZ DEVELOPER Sep 29 '15, 2:10 a.m.
Geoff, yes, someone could always change his private copy in his file system. But my customer is aware of that but nevertheless he wants to have some stuff read only except for a specific team. Independent of you opinion ;-) Do you know a solution for that?

1 vote

Geoffrey Clemm
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Sep 29 '15, 10:04 a.m.
There is no support provided for this functionality, and it is very unlikely that we would consider adding such a function, for the reasons identified in my message above.   One of the criticisms of high-end SCM tools is that they "get in your way".   Sometimes a tool has to "get in your way" to prevent a serious problem, but I have seen no convincing arguments for this being one of those cases.

Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Sep 29 '15, 10:29 a.m.
I would like to see this too, because I think you should indeed be able to do this kind of stuff. I also think that operational behavior in general is too brittle to work well, if you are not very careful. Just clicking on "Preconditions and operational behavior is configured..." for some role and doing nothing but save will override all operational behavior configured for everyone immediately for anyone happening to have this role in the context. We can have a discussion about this, if you like Geoff 8)

Geoffrey Clemm
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Sep 29 '15, 10:57 a.m.
WRT disallowing creating private change sets on a component, I'm happy to continue the discussion in this forum entry, or via another medium if you prefer.  Note that "I have a customer that wants to do it" is not a sufficient reason (:-).   WRT the brittleness of operation behavior, I certainly agree, but I'd suggest starting a separate forum question on that topic.

Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Sep 30 '15, 8:49 a.m.
We have permissions that can be set up to prevent a lot of stuff. In the last releases ownership and visibility has been introduced for almost everything. Ownership and visibility and permissions determine what can be done and what can't. I can make sure a stream is owned by a team and you can't deliver there due to a missing permission, I can not deliver to a repository workspace at all, if that is owned by someone else - for good reasons. There are many things you can do to limit now, that we did not have in the beginning. We even have capabilities to make stuff read only. So I don't buy your argument at all. It does not make sense not to be able to protect a component from being changed. Anyone that has a bit of permission can create their own stream and deliver stuff to components and it is impossible to prevent that and you can get - even unintentional - corrupt code and baselines delivered that could accidentally be picked up. I have seen so many requests for this now and the operational behavior is just totally insufficient.

Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Sep 30 '15, 8:55 a.m.
I don't buy your reason in this case. There are other situations where the user can't deliver (e.g. with the precondition) and they don't even see that in advance. Wanting to be able to limit who can deliver to a component by ownership is from my perspective as legitimate as the other precautions we already have. To me this is a gap and I think if RTC is supposed to be used in big enterprises it has to adopt to these kinds of things. It would even be possible to use the pessimistic locking mechanism to prevent a user from accidentally making changes in this case. There is a good argument for a user should be able to do what they want. But there is also a good reason for being able to protect stuff in some cases. Anyway, this is certainly not the platform to discuss this as there is too few space in comments.

Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Sep 30 '15, 9:00 a.m.
I don't, by the way argue that users should be able to do their local changes and be able to e.g. check in to their repository workspace. What sometimes should be prevented is delivering to the component. One example: certified code stored in the component and you want to make sure only that is available to users etc.

Geoffrey Clemm
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Sep 30 '15, 6:36 p.m.
A few comments on the points raised by Ralph: - The fact that we have a bunch of other permissions does not imply we should have this permission.   - The fact that we have added new permissions over time does not imply that we should add this permission.   My argument has never been that it is hard to do (it actually isn't hard to do) ... my argument has only been that it would be wrong to do. - We are talking about write access, not read access control.   I completely agree that you need to provide read access control to the component as a whole, and this is supported in the product today.   The fact that you have read access control at a certain level does not imply it is desirable to have write access control at that level. - The fact that someone can write changes to their own stream of a component in no way implies that this somehow gives you greater access to any other stream.   If someone says you cannot deliver to their stream, you cannot.   It doesn't matter if you happen to have some change sets in that component.   That's like saying "I have to remove write repository to the entire repository to ensure you cannot make changes to a component".   That is of course not true, and the same applies here. - In the presence of distributed delivery, a "global write lock" makes no sense.  As soon as you replicate that component to another repository, you lose the ability to prevent someone making changes to their replica of that component.   How is that significantly different from allowing them to make changes to their stream of that component? - Pessimistic locking is also stream based ... it prevents someone from making changes in the context of some particular stream (just like the other write access control mechanisms). WRT your last point:  "I don't, by the way argue that users should be able to do their local changes and be able to e.g. check in to their repository workspace. What sometimes should be prevented is delivering to the component."   There is no such thing as "delivering to a component".   Do you mean "adding a change set to the component"?   As soon as you checkin an file, that change set is added to the component containing that artifact.   So you cannot allow "checking in" but not allow "adding a change set to a component". - And as a reminder: the fact that someone (or even several people) wants to do something doesn't mean it is the right thing to do (:-).

showing 5 of 8 show 3 more comments

Your answer

Register or log in 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.

Ask a question
Guidelines
FAQ
Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 12,147
× 1,210

Question asked: Sep 28 '15, 8:11 a.m.

Question was seen: 5,498 times

Last updated: Sep 30 '15, 6:37 p.m.

Confirmation Cancel Confirm