When using custom endpoints and request fields from a relationship, if the attributes have the same name they get mixed up

[lombao]

Hi
I am uncertain on how to classify this. My apologies in advance if I missed something in the doc, but I would have assume that the reply of both internal openidm.read and REST api should be basically the same

In the ast version 7.0.2 of openidm I am seeing the following
If I use CURL to get a fields like "_fields=username,manager/userName"... then I get the expected response

{ "_id":"...." "userName": The right username .. "manager" { .... "userName": " Username of the manager" } }

But if I request the same using openidm.read , the reply is like

{ "_id": "the correct id as before" "userName": The username of the Manager !!!!!!! "manager" { ..... } }

It is like when using openidm.read there is a clash or problem when using "/"

Is it a bug ? Is it expected behaviour ?

[maximthomas]

Hi @lombao,
That is the expected behaviour - fields are case-sensitive, so username does not return anything. The correct field name is userName (camelCase). For example, your request...

curl -X GET --location "http://localhost:8080/openidm/managed/user/9e38767c-9a5f-4159-884c-da9f9ba09b55?_fields=username%2Cmanager%2FuserName" \
    -H "Accept: application/json" \
    -H "X-OpenIDM-Username: openidm-admin" \
    -H "X-OpenIDM-Password: openidm-admin" | jq
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   221    0   221    0     0   6907      0 --:--:-- --:--:-- --:--:--  7129
{
  "_id": "9e38767c-9a5f-4159-884c-da9f9ba09b55",
  "_rev": "2",
  "manager": {
    "_ref": "managed/user/e2137a54-e377-4c65-a3df-4f887201db82",
    "_refProperties": {
      "_id": "8c94b57e-4036-4b65-a48e-79d8aa3d4aa7",
      "_rev": "1"
    },
    "userName": "jane"
  }
}

correct request:

curl -X GET --location "http://localhost:8080/openidm/managed/user/9e38767c-9a5f-4159-884c-da9f9ba09b55?_fields=userName%2Cmanager%2FuserName" \
    -H "Accept: application/json" \
    -H "X-OpenIDM-Username: openidm-admin" \
    -H "X-OpenIDM-Password: openidm-admin" | jq
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   239    0   239    0     0   6191      0 --:--:-- --:--:-- --:--:--  6289
{
  "_id": "9e38767c-9a5f-4159-884c-da9f9ba09b55",
  "_rev": "2",
  "userName": "demo",
  "manager": {
    "_ref": "managed/user/e2137a54-e377-4c65-a3df-4f887201db82",
    "_refProperties": {
      "_id": "8c94b57e-4036-4b65-a48e-79d8aa3d4aa7",
      "_rev": "1"
    },
    "userName": "jane"
  }
}

[lombao]

sorry about the username typo, I know about the case, that is NOT the problem.
The issue is the different behaviour I am observing for returning objects with relationships between REST api ( curl ) and script ( openidm.read() , when I ask via the REST ( curl ) returning fields like "manager/userName" , I get the username of the user object which is the manager. However, using openidm.read it seems the same request is ignored

[maximthomas]

please provide curl request and response example

[lombao]

I think I already did. Let me explain
Using the default setup for object user, there is an attribute call manager, which is a relationship to again user object.
A manager, because it is an object user, have, indeed, its own userName.

If I use curl like this when I ask to return the attribute userName of both the requested user and its manager, like this one

curl -X GET --location "http://localhost:8080/openidm/managed/user/9e38767c-9a5f-4159-884c-da9f9ba09b55?_fields=userName,manager/userName"

The output is the correct one, I get something like this:

{
"_id": "9e38767c-9a5f-4159-884c-da9f9ba09b55",
"_rev": "2",
"userName" : "alice"
"manager": {
"_ref": "managed/user/e2137a54-e377-4c65-a3df-4f887201db82",
"_refProperties": {
"_id": "8c94b57e-4036-4b65-a48e-79d8aa3d4aa7",
"_rev": "1"
},
"userName": "bob"
}
}

Bob is the manager of Alice. All iS CORRECT so far, it works as I had expected

Now, let's try the same. but inside OpenIDM using openidm.read instead, something like

openidm.read(resourcePath,null,reqFields);

Where resourcePath is "managed/user/71610169-61a9-4783-b20e-5631c94bbf3e"
And reqFields is something like
[
"/description",
"/userName",
"/manager/usernName",
..
]

The answer this like

{
"_id": "9e38767c-9a5f-4159-884c-da9f9ba09b55",
"_rev": "2",
"userName" : "bob"
"manager": {
"_ref": "managed/user/e2137a54-e377-4c65-a3df-4f887201db82",
"_refProperties": {
"_id": "8c94b57e-4036-4b65-a48e-79d8aa3d4aa7",
"_rev": "1"
},
}
}

The userName fo the manager does NOT appear inside "manager", and the attribute userName, isntead of being Alice, is the manager's username, Bob.
usign openidm.read is where I see the problem

[maximthomas]

I think you have misspelled the command, "/manager/usernName", should be "/manager/userName"

[lombao]

Sorry, correction, my bad
When I was preparing a better case I just realized that openidm.read returns the exact same ouput as the curl commant, so that is NOT problem, so the title of this case is wrong, because curl and openidm return both the correct results. My bad

The problem happens when using endpoints, what I missed is that I have an endpoint defined like

{
"type" : "text/javascript",
"context" : "endpoint/myep/*",
"file" : "script/endpoint/myep.js"
}

In the myep.js I capture the request and , removing all unneeded line I have something like

       logger.warn("REQUEST {} ::: "+ JSON.stringify(reqFields, null, 2) );
        var result = openidm.read(resourcePath,null,reqFields);
        logger.warn("RESULT {} ::: "+ JSON.stringify(result, null, 2) );
        return result;

So I can compare what is requested and what is returned, and both are correct, the result contains the correct userName. So inside teh myep.js all is correct

But then when I do a curl like

https://${OPENIDM_SRV}/openidm/endpoint/myep/managed/user/71610169-61a9-4783-b20e-5631c94bbf3e?_fields=description,userName,givenName,sn,manager,manager/userName

the output is wrong !!!!

{
"_id": "71610169-61a9-4783-b20e-5631c94bbf3e",
"description": "xxxxxxxx",
"userName": "!!! Wrong, here appears the userName of the Manager !!! instead of the user",
"givenName": "xxxxxx",
"sn": "xxxxx",
"manager": {
"_ref": "managed/user/8cbe89a8-beb0-4ddd-bd22-207e1ccb1df7",
"_refProperties": {
"_id": "079cf758-66af-45ad-886c-67447f147c48",
"_rev": "1"
},
"userName": "here appears the correct Manager's username"
}
}

But now, if I use a "direct" curl query withoyut using the custom endpoint

https://${OPENIDM_SRV}/openidm/managed/user/71610169-61a9-4783-b20e-5631c94bbf3e?_fields=description,userName,givenName,sn,manager,manager/sn,manager/_id,manager/userName,manager/givenName,manage

the output is completely correct !!!

Please note that as I said in the myep.js custom endpoint I have logs to show how the request arrives and what is the openidm.read result. here it is for the previous queries ( some bits were edited )

WARNING: Method Read IDMUI REQUEST {} ::: [
"/description",
"/userName",
"/givenName",
"/sn",
"/manager",
"/manager/userName"
]
Jun 10, 2026 8:36:13 AM org.forgerock.script.scope.FunctionFactory$1$2 call
WARNING: Read result {} ::: {
"description": ",,,,",
"userName": "CORRECT USERNAME",
"givenName": "Correct name",
"sn": "Correct family name",
"manager": {
"_ref": "managed/user/8cbe89a8-beb0-4ddd-bd22-207e1ccb1df7",
"_refProperties": {
"_id": "079cf758-66af-45ad-886c-67447f147c48",
"_rev": "1"
},
"userName": "Correct manager's username"
}
}

The relevant code in the myep.js that dumps these logs is
logger.warn("REQUEST {} ::: "+ JSON.stringify(reqFields, null, 2) );
var result = openidm.read(resourcePath,null,reqFields);
logger.warn("RESULT {} ::: "+ JSON.stringify(result, null, 2) );
return result;

So, the title of this issue is wrong, sorry, my bad, the issue seems to be in "something" when endpoints are used, which I cannot figure out what.

[maximthomas]

@lombao
Please proviede complete myep.js script to reproduce the issue

[lombao]

A very basic one will do , something like

(function () {

var resourcePath = request.resourcePath;

var reqFields = Object.keys(request.fields).map(function (k) {
        return request.fields[k];
});

   logger.warn("REQUEST {} ::: "+ JSON.stringify(reqFields, null, 2) );
    var result = openidm.read(resourcePath,null,reqFields);
    logger.warn("RESULT {} ::: "+ JSON.stringify(result, null, 2) );
    return result;

}());

This will work for simple curl GET requests, but nothing more, it is just to reproduce the problem when , for instance, we try to get via endpoint the fields "userName,manager/userName"

[lombao]

So, now I am "with a certain moderately" conviction that there is some bug in the https://github.com/OpenIdentityPlatform/OpenIDM/tree/master/openidm-customendpoint or any associated component in such a way that when using endpoints if an answer contains "someattributename, rel/someattributename" , if the "someattributename" happens to have the same, the reply is flattened. This should be reproducible with the default user object, because the "manager" relationship is a rel to the same user object, they will share the same attribute names, so , imagine that I make a query that wants to retrieve the givenNamer of both, a user, and its manager, the requested fields will be like "givenName,manager/givenName".. such query if it goes trought a custom endpoint will get "flattened" and the reply will wrongly mixup the givenName of the user and the givenName of the manager.

[vharseko]

• Fix field projection collapsing nested JsonPointers to leaf names commons#183
• test(openidm-script): reproduce custom endpoint field projection collision (#183) #190