Query on Data visibility in Domain separation

[Suggy]

Hello,

I have  a query on Data visibility in Domain separated instance.

Below is the domain map 

Cloud Ops domain has no visibility to any of the above parent domains.

I have written a BR in TOP domain like below (triggers upon each update for testing purpose)

var gr = new GlideRecord('incident');
gr.initialize();
gr.short_description = '123';
gr.caller_id = '5a7ed4341f1310005a3637b8ec8b7092'; //user from Initech domain
gr.company = 'c94cf9c54a36231201e14142cf24f5ee'; //sys_id of Initech company
gr.sys_domain = 'c94122494a362312007f2ce5bd78768f'; //sys_id of Initech domain
gr.insert();

As per the process flow, above BR will be applicable and runs in 'Cloud Ops' domain as well.

What I did is, I logged into 'Cloud Ops' domain as 'Test cloud user' and udpated an incident which triggered the above BR and then an incident for created in 'Initech' domain.

So for the newly created incident, the created by/opened by is 'Test cloud user' and the company and doamin of that incident is 'Initech'.

Question - the 'Test cloud user' user does not have visibility to 'initech' domain. but just by triggering the business rule, (here the BR ran as 'Test cloud user' user) and it created the incident with caller from 'Initech' domain.

In UI, 'Test cloud user' cannot see data elements from 'Initech' domain , but via script, 'Test cloud user' created the incident with data from 'Initech' domain.

Is that expected behavior in Domain separated environment?

[Suggy]

Anyone?

[KevinBellardine]

Hey @Suggy 

This is an interesting case honestly, but from what I can tell everything is working as expected. Domain separation prevents you from viewing, editing, or updating records outside of your domain. Here you've created a record using the a Top domain BR and you're manually passing the Sys IDs, bypassing the need for a query.

If you tried to query the sys_domain table or the sys_user table, for example, this would have failed. Because you have the sys_ids already you're effectively bypassing domain separation, at least for creating the incident.

[Suggy]

Hi @KevinBellardine 'If you tried to query the sys_domain table or the sys_user table, for example, this would have failed. ' >>>>>>> I tested that and it did not fail. Incident got created successfully as per the script.

var gr = new GlideRecord('incident');
gr.addQuery('number', 'INC0243413');

gr.query();

if(gr.next())

{

gr.short_description = '123';
gr.caller_id = '5a7ed4341f1310005a3637b8ec8b7092'; //user from Initech domain
gr.company = 'c94cf9c54a36231201e14142cf24f5ee'; //sys_id of Initech company
gr.sys_domain = 'c94122494a362312007f2ce5bd78768f'; //sys_id of Initech domain

gr.setWorkflow(false);

gr.insert();

}

[KevinBellardine]

The core problem here is that domain separation doesn't technically restrict record creation. You can create a record in another domain, but you would need to have all the sys_id's required ahead of time. Provided you have the information already available and your user passes the ACLs to create the record you'd be able to do it.