Domain Separation - Issue when quering the domain-table

Fabian Kunzke · ‎02-26-2018

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

Fabian Kunzke · ‎02-26-2018

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

View solution in original post

Chris Sanford1 · ‎09-25-2018

Hey Fabian,

Thanks for stating the obvious! I encountered a very similar issue, except mine is in an inbound email action. Basically, we have new user creation enabled for inbound emails, and I'm trying to update their company via an inbound email action. The company updates fine, but the domain is stuck in 'default' for presumably the same reason you described. Any ideas how I could work around this? The visibility domain option doesn't really work for this, since the script is running as a new user every time.