Why does user get "no permission" on flowing changes between repositories ?
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
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
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 )
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.
1 copy in each repository to which it is replicated, yes.
- 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
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
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.
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.
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 )
1. LicenseId = com.ibm.team.rtc.developer.floating
2. LicenseId = com.ibm.team.rtc.contributor
3. LicenseId = com.ibm.team.clm.rm.datacollector
4. LicenseId = com.ibm.team.rrc.system
5. LicenseId = com.ibm.team.rtc.stakeholder.floating
6. LicenseId = com.ibm.team.clm.qm.datacollector
7. LicenseId = com.ibm.team.rtc.cq-connector
8. LicenseId = com.ibm.team.rtc.buildsystem
9. LicenseId = com.ibm.team.lpa.system
10. LicenseId = com.ibm.rqm.functional
11. LicenseId = com.ibm.team.jis.trs.system
12. LicenseId = com.ibm.team.clm.ccm.datacollector
13. LicenseId = com.ibm.rqm.tester.floating
14. LicenseId = com.ibm.team.clm.datacollector
15. LicenseId = com.ibm.team.rtc.contributor.floating
16. LicenseId = com.ibm.team.rrc.author.floating
17. LicenseId = com.ibm.team.sccd.deliverysystem
18. LicenseId = com.ibm.rtc.developer-iep.floating
19. LicenseId = com.ibm.team.rtc.cc-connector
20. LicenseId = com.ibm.team.rrc.reviewer.floating
21. LicenseId = com.ibm.rqm.viewer.floating
License IDs on local: ( a jts with several RTC applications )
1. LicenseId = com.ibm.team.rtc.contributor.floating
2. LicenseId = com.ibm.team.rtc.developer.floating
3. LicenseId = com.ibm.team.rtc.cq-connector
4. LicenseId = com.ibm.team.rtc.stakeholder.floating
5. LicenseId = com.ibm.team.sccd.deliverysystem
6. LicenseId = com.ibm.team.rtc.buildsystem
7. LicenseId = com.ibm.team.rtc.cc-connector
8. LicenseId = com.ibm.rtc.developer-iep.floating
9. LicenseId = com.ibm.team.clm.ccm.datacollector
10. LicenseId = com.ibm.team.clm.datacollector
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.