
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-26-2018 12:58 AM
Hello,
I found a weird behavior, where i cannot get a query onto the domain table to work. I reduced it to the code down below. The sys_id within the domain.get(); is the sys_id of a domain record. But insted of actually finding the record, the output is always "ain't found shit". Therefore, the glide Record seems not to return anything, despite a matching record existing.
var domain = new GlideRecord('domain');
if(domain.get('c1bfa49b4f98db00f11329001310c7c7'))
{
gs.info('found domain ' + domain.name);
return domain.getUniqueValue();
}
gs.info('ain\'t found shit');
Now i have checked the acls and on query rules. It seems as if there is nothing in the way to prevent this. Also, just using the following line of code, a domain record is found.
var domain = new GlideRecord('domain');
domain.query();
if(domain.next())
{
gs.info('found domain ' + domain.name);
return domain.getUniqueValue();
}
gs.info('ain\'t found shit');
The reason why i am trying to use a glide record here is, because i do not like to hardcode any IDs. But at the moment i am out of outs. The line of code is performed within the highest domain scope (global).
Has anybody seen this behavior before?
Greetings
Fabian
Solved! Go to Solution.
- Labels:
-
Best Practices
-
Scripting and Coding

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-26-2018 03:37 AM
Hello,
I have indeed found the reason to why this is not working. The visibility of the domainstructure does not allow a user to query the domain table in this context/way. Indeed it has to be ensured, that the user who is used to execute such query (in this case the user triggering the update of the record) can "see" the domain queried. This results in the following workaround:
The user used for this function call has to be granted visibilty access to the highest domain.
Therefore users used for interfaces or scheduled jobs have to be granted that visibilty.
Seems obivous, but i missed it. This originates cause a domain record itself is assigned to the same domain it is representing. Thus it behaves as any other domainseperated record. Therefore, the code infact is not incorrect, but rather the visiblity setting for the executing user.
tl:dr: When using domainseparation, the current domain scope of the user does not seem to matter. Instead the user domain visibility set within the domain-related-list on the domain record is checked.
Greetings
Fabian

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-26-2018 01:14 AM
Hello Fabian,
we are also working on a domain seperated environmet and for me your script is working fine.
You could try addQuery("sys_id", "c1bfa49b4f98db00f11329001310c7c7") instead of the get.
We are currently running "glide-istanbul-09-23-2016__patch9a-09-01-2017"
Greetings
Martin

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-26-2018 01:39 AM
Hello Martin,
Thanks for the suggestion, but this does not seem to work either.
The instance i currently on jakarta-05-03-2017__patch6-11-14-2017_11-22-2017_2104
Greetings
Fabian
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-26-2018 01:49 AM
To retrieve records from all domains we use queryNoDomain() but seems like its not working for domain table itself.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-26-2018 02:29 AM
Hello,
Interesting point. But doesn't this defy the use of domainseparation? What usecase would require a query which does not check for the domainseparation?
Greetings
Fabian