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:
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:
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.
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
showing 5 of 6
show 1 more comments
As described in the article above and in https://jazz.net/library/article/1399 at least the following is necessary for this to work:
- The repositories need to be of a compatible version e.g. ideally the same version
- The servers must both enable distributed SCM in the advanced properties
-
You require RTC Developer licenses that are not mixed with any 10 Free or Developer for workgroups licenses
- The user needs to have an account on each server (can have different ID's)
- The user must have the developer license on both servers
- The user must have read access to the project areas that own the SCM data
-
Must be able to read and write the involved SCM data in both project areas
-
The respective user must, in both project areas, have a role assigned that has the special "replicate change sets" permission granted
Comments
