It's all about the answers!

Ask a question

how to get user's uuid by user id in java script for RTC?

jane zhou (106966) | asked May 08 '19, 5:15 p.m.
edited May 08 '19, 10:07 p.m.


Hi Someone who may concern,

          We want to update a customized attribute (type:contributor) according to role in team area, say we want to read team area, and fetch the person with role as product owner in the team area back, and update this attribute. However, we can only get user id from team area API as format of the following. but we don't know how to get uuid through user id by any java script function.
https://[local host]:9443/jts/users/xxxx
      Since in java script context, we are on ccm server, we can not access jts server directly, how we can get UUID by using user id?


Best Regards,
Jane Zhou


Accepted answer

permanent link
Davyd Norris (2.3k217) | answered May 10 '19, 12:27 a.m.
This JavaScript will do the job for you - you need to supply the Team Area id, and the name of the role as text. If you wanted to use the name of the Team Area instead you could modify the script accordingly.

Note that this script will run asynchronously so that it doesn't affect the performance of your browser, which means that the results may not be available directly in your calling function

  var jazzClient = jazz.client;

  var getTeamMembersWithRole = function(team, role) {
    if (!team || !role) {
      console.log('getTeamMembersWithRole: Error! team = ' + team + ', role = '
          + role);
      return null;

    var xhrArgs = {
      url : '/ccm/rpt/repository/foundation?fields=foundation/teamArea[itemId='
          + team
          + ']/roleAssignments/(contributor/itemId|contributorRoles/name)',
      headers : {
        'Accept' : 'application/xml'
      handleAs : 'xml'

    return jazzClient.xhrGet(xhrArgs).then(
        function(data) {
          var memberIds = data.evaluate(
                  + role + '"]/contributor/itemId', data, null,
              XPathResult.ANY_TYPE, null);

          var members = [];
          var id = memberIds.iterateNext();

          while (id !== null) {
            id = memberIds.iterateNext();

          return members;
jane zhou selected this answer as the correct answer

Ralph Schoon commented May 10 '19, 2:23 a.m.

The reason why customers broke their tools was not due to the fact that the scripts would have been synchronous. It was due to the fact that nobody considered that customers could have hundreds of team areas and timelines and iterations.  This cased the communication to the server so excessive that the browser hoarded the available memory, locking the laptop, and the work items would not load anymore.

Ralph Schoon commented May 10 '19, 2:30 a.m. | edited May 10 '19, 2:36 a.m.

 Also note that this caused a Management level crit sit, cost tenth of thousands of $, weeks of travel time, impacted hundreds if not thousands of users and heavily impacted the acceptance and reputation of our tools, because, of course this was recognized as an IBM defect, because there is no way of telling that this was caused by a customization.

It was luck that we actually found the root cause. We found millions of calls to the admin services that we were unable to account for - why became only apparent when I was able to reproduce this and log the browser communication.

Davyd Norris commented May 10 '19, 2:39 a.m. | edited May 10 '19, 2:43 a.m.
Which is of course why you would test it carefully in your environment before putting it in production, and why you need to use filters in your OSLC or Reportable REST API calls.

And why no scripting is officially supported by IBM, including any of the Java server side stuff in the workshop Ralph has authored. Use at your own risk!

That script is currently being used in one of my client's projects - they have about 50 team areas and about 300 users in that project

Ralph Schoon commented May 10 '19, 2:46 a.m.

The customer claimed they had tested it. 

They questioned we had tested out tools though. 

This specific customer has many, many deployments and there are a lot of different pattern, how the tools are used. Many of which have project areas with a lot of information such as users, roles, team areas,..... You can test with 10 production systems and all looks nice. Then you deploy everywhere and kill off thousands of users. 

Ralph Schoon commented May 10 '19, 2:48 a.m. | edited May 10 '19, 2:50 a.m.

 To sum it up, we also identified several enhancements to use heavy caching for categories, timelines and some other information needed to edit work items. The data shapes the customer generated was never anticipated by our development.

The feature they tried to implement with their extension was also made a product feature.

Ralph Schoon commented May 10 '19, 3:09 a.m. | edited May 10 '19, 3:09 a.m.

Also note that this did not show up for all users. Also most complaints came from one location.  

It only impacted users using the Web UI, because it was an extension that only worked in the Web UI. It also impacted especially users with slower laptops with less resources. The users responsible for the systems that where most impacted usually used the Eclipse UI and also had development machines with more resources and higher performance. They where not as impacted, even being at the location that had the most complaints. 

The location was a red herring however. It was not a network problem..... 

Ralph Schoon commented May 10 '19, 3:10 a.m. | edited May 10 '19, 3:11 a.m.

 BTW, thanks for sharing Davyd!

jane zhou commented May 12 '19, 1:03 a.m.

Thanks Davyd and Ralph for your great help!
Both of you provided very valuable information for me! 
Currently, all of our team areas only accommodate less than 20 users, so I suppose the performance should not be a big problem.

Thanks again!

showing 5 of 8 show 3 more comments

One other answer

permanent link
Ralph Schoon (63.2k33646) | answered May 09 '19, 2:01 a.m.
edited May 09 '19, 2:13 a.m.

This is not supported by the supported and documented JavaScript API for attribute customization. See for a comprehensive documentation of the supported JavaScript API.

In the Web UI it would be possible to use RESt APIs to communicate to the server and to get such information.

However, this is not supported and customers have managed to break performance render the UI unusable by doing so. See for some anecdotal information and suggestions for a minimal performance monitoring.

Your answer

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