Why does user get "no permission" on flowing changes between repositories ?
Situation: 2 v4.0.7 RTC configured with LDAP registry, but in separate JTS. Repos are friends, distributed SCM enabled on both ends and both are friends. Associations are established between two project areas, but when user attempts to accept changes from a remote component:
User 'Tiong Tan' does not have permission to read component 'MESA'I have checked/verfied that Replicate Change sets is in a role assigned to this user ( at both ends ). In local repository user has Developer license, in remote, Stakeholder and Developer [ this might be the deciding factor ]. JazzUser role for the user in both repositories. BUT in reading https://jazz.net/library/article/535 there are sections that describe "Activating replicated users". I ran the scm list users --noUserIds for both ends. For what would be the remote repository, the user in question does not appear. But in the local repository the user does appear. An attempt to set the user ID failed ( likely due to LDAP registry ). The Components in question are owned by a team ( project area, actually) and user is a member of that project. When I view users workspace in web UI one of the flow targets is labeled similar to this: Inaccessible flow target on https://rtc-iss:9443/jazz/What's next ? |
2 answers
|
I might now know the why of this situation. As a possible work around, I created an empty workspace, added the two remote components of interest, saved and handed its ownership to another user. However, that user still is unable to see/add those components. I happened to notice that the added components became mysteriously owned by a project area that was not at all an expected outcome. Further research into that project shows a stream with those apparently same 2 components. Our user doesn't have visibility into that project which explains the read issue.
However, looking at the URI of the Component in a stream on either end of the "pipeline", the componentItemIds have the same value in both repositories. I'm interpreting that in fact the component actually truly exists ONLY in its original repository and all other references are just that. The 2nd repository knows that what it needs to do is send changes to that owning repository and any artifacts in that 2nd repository serve only to provide 'hooks'. I have read somewhere that the Component is the ultimate delivery target. Comments 
Geoffrey Clemm
commented Mar 12 '15, 7:24 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
In distributed delivery, a component is actually created in the other repository the first time there is a delivery to that component. It is given the same ID as the component in the original repository, so it is easy to locate in a subsequent delivery.
So to be clear, irrespective of whether the delivered component is actually a separate new entity, it has an ID that will be unique in the delivered to repository making the situation we are in now ? i.e. the delivered component has a project area ownership preventing new workspaces in other projects from using ( ignoring the scoping consideration )
The first paragraph makes sense.
I can address the conjecture in your second paragraph: the components in all repositories are equally real. There are no practical differences between the components in each server. Regarding the question in your comment: when changes to a component are first delivered to a new repo, the component is created with the user listed as the owner. From that point on, the normal rules around permissions apply: in order to be able to deliver to the component, the user must be able to see it and have permission to it. Which in effect means that only 1 copy of said component exists. I can understand reasoning behind that ( repository wise ). So it's on the user community to battl, er agree amongst themselves on the scoping.
Geoffrey Clemm
commented Mar 13 '15, 11:52 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
1 copy in each repository to which it is replicated, yes.
showing 5 of 6
show 1 more comments
|
Ralph Schoon (63.6k●3●36●46)
| answered Feb 11 '15, 11:08 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER edited Feb 11 '15, 11:10 a.m.
As described in the article above and in https://jazz.net/library/article/1399 at least the following is necessary for this to work:
Comments 1) Check -- both 4.0.7
Ralph Schoon
commented Feb 11 '15, 11:35 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
3) Please look at the link: https://jazz.net/downloads/rational-team-concert/releases/4.0.7 and scroll waaaaaaay to the bottom and check what licenses are blocking this capability.
Ralph Schoon
commented Feb 11 '15, 11:38 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
If the error message is "no permission to replicate change sets" it is 8, if it is any other permission error it likely is 6.
I understand the necessity of having Membership / Role vs project admin. I did verify that user has a role ( at the project level ) for both ends that has Replicate Change sets enabled.
License Ids on "remote": ( a full CLM )
There is one warning on the "remote" about a Contributor license:Inactive (CRJAZ2380E The "Contributor" client access license type is deactivated because it depends on the client access license type with the "com.ibm.team.rtc.developer" ID which is not installed. If you have multiple client access license activation keys to install, continue installing them to fix this problem.)I have no issue deleting that license, which I've done, now no runs, no drips no warnings on the license page. |
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.