It's all about the answers!

Ask a question

Why does user get "no permission" on flowing changes between repositories ?

Kevin Ramer (4.5k6174191) | asked Feb 11 '15, 10:52 a.m.
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 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

permanent link
Kevin Ramer (4.5k6174191) | answered Mar 12 '15, 4:34 p.m.
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.

Geoffrey Clemm commented Mar 12 '15, 7:24 p.m.

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.  

Kevin Ramer commented Mar 13 '15, 7:35 a.m.

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 )

Evan Hughes commented Mar 13 '15, 12:09 p.m.
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. 

Evan Hughes commented Mar 13 '15, 12:12 p.m.

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. 

Kevin Ramer commented Mar 13 '15, 12:15 p.m.

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.

1 copy in each repository to which it is replicated, yes.

showing 5 of 6 show 1 more comments

permanent link
Ralph Schoon (61.6k33643) | answered Feb 11 '15, 11:08 a.m.
edited Feb 11 '15, 11:10 a.m.
As described in the article above and in at least the following is necessary for this to work:

  1. The repositories need to be of a compatible version e.g. ideally the same version
  2. The servers must both enable distributed SCM in the advanced properties
  3. You require RTC Developer licenses that are not mixed with any 10 Free or Developer for workgroups licenses
  4. The user needs to have an account on each server (can have different ID's)
  5. The user must have the developer license on both servers
  6. The user must have read access to the project areas that own the SCM data
  7. Must be able to read and write the involved SCM data in  both project areas
  8. The respective user must, in both project areas, have a role assigned that has the special "replicate change sets" permission granted

Kevin Ramer commented Feb 11 '15, 11:19 a.m. | edited Feb 11 '15, 11:23 a.m.

1)  Check -- both 4.0.7
2)  Check
3)  one more thing to check, we have mixed bag in our jts, but none of the free are assigned ( Removed Stakeholder in remote repository )
4) Check
5) Check
6) Check, might be a project admin in BOTH
7) by other measures ( component / stream ownership; user membership ) ought to be good
8) Check

Ralph Schoon commented Feb 11 '15, 11:35 a.m.

3) Please look at the link: and scroll waaaaaaay to the bottom and check what licenses are blocking this capability.

6) It is a very common, but nevertheless completely wrong, assumption that being project or any other admin role allows you to do everything. If you don't have a role with the correct permissions, all you can do in some situations is to give yourself the role and permission you need.
7) Let the user try this.

Ralph Schoon commented Feb 11 '15, 11:38 a.m.

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.

Kevin Ramer commented Feb 11 '15, 11:50 a.m.

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.

Kevin Ramer commented Feb 11 '15, 12:08 p.m. | edited Mar 13 '15, 11:54 p.m.

License Ids on "remote": ( a full CLM )
1. LicenseId =
2. LicenseId =
3. LicenseId =
4. LicenseId =
5. LicenseId =
6. LicenseId =
7. LicenseId =
8. LicenseId =
9. LicenseId =
10. LicenseId =
11. LicenseId =
12. LicenseId =
13. LicenseId =
14. LicenseId =
15. LicenseId =
16. LicenseId =
17. LicenseId =
18. LicenseId =
19. LicenseId =
20. LicenseId =
21. LicenseId =

License IDs on local: ( a jts with several RTC applications )
1. LicenseId =
2. LicenseId =
3. LicenseId =
4. LicenseId =
5. LicenseId =
6. LicenseId =
7. LicenseId =
8. LicenseId =
9. LicenseId =
10. LicenseId =

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 "" 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

Register or to post your answer.