Ignore domain in reference qualifier

[dgimmler]

Hey Folks,

We are working with a heavily domain-separated instance. Currently when we create a new entry on the change_request table without specifying an assignment group, all assignment groups not in the global domain are filtered out unless the change itself is in the global domain as well. We would otherwise like to maintain the current domain separation for the assignment groups, but would like the domain to be ignored in this case. I have looked at everything I could in the dictionary definition, and have tried adding attributes such as no_separation=true and global_visibility=true with now luck - the available assignment groups listed on the form continue to filter out anything not in the global domain. There are no reference qualifiers set.

If anyone as an idea on how to ignore the domains, I would greatly appreciate it.

Thanks!

[Michael Fry1]

So you created a change request, in the global domain but can't see all assignment groups, just the global ones? Can you share your ref qualifier?

[dgimmler]

I created a change request in a child domain, but can only see assignment groups for the global domain where I want to see all. And I have no reference qualifier, that's the problem.. it looks like these assignment groups are getting filtered out by default.

[Michael Fry1]

Something new I just learned from david.legrand

Users with the domain_expand_scope user role can select the domain scope from the Toggle Domain Scope UI action on the form. When record scope is in effect, click the UI action to expand to session scope and display all data available based to the user's domain and child domains. When session scope is in effect, click the UI action to collapse to record scope and display only data that matches the current record's domain.

Maybe that will work for this case?

[conmic]

Hello Daniel,

I think you first need to get a basic understanding of what domain separation is supposed to do and much more important: how it works. I strongly recommend you to get the Domain Separation training as it's a really confusing and a difficult topic. You really need to know what it was designed for and especially what it was not designed for.

I try to explain this briefly, but it will give you more questions than answers. that's why I recommend the training:

1. The concept of 'global'
   When you talk about the 'global' domain, you're actually not talking about a domain. 'global' is to be considered as the entire environment. Domains are basically then borders that you apply to that environment. Imagine it a bit like this:
   
   Note: this is not a best practice model! I am on purpose not picturing a "TOP" domain.
   
   
2. Processes (scripts, notifications, rules, etc...) flow down the domain hierarchy.
   Referring to the previous picture: if you apply a business rule (process) to Domain A it is subsequently applied to Domain C unless it gets overwritten. If you apply a business rule to Domain C, it will not be applied to Domain A.
   
   Now if you apply a business rule to 'global', it will be available to all the domains.
   
   
3. Data (records) flows up the domain hierarchy
   So if you have Incidents in Domain C, they will be visible in Domain A. However Incidents in Domain A are not accessible by Domain C.
   
   When you set data to 'global' it will be available to all the domains. And this is pretty dangerous, that's why we have something that's called a default domain.
   
   
4. The concept of data separation
   Domain separation was designed to separate processes and data in one single instance. Now in order to guarantee data separation you basically can only do this on database level. So if you're not a 'global' user but in a specific domain, then whenever your instance queries for data it also includes that domain already into the database query. Meaning that the returned data is only records with the same domain value as your querying user.
   Domain Separation is NOT applied via scripts and frameworks, otherwise you cannot guarantee data separation.

Now the model of those 4 points applies also to your assignment groups. They are considered data. There are ways around depending on the situation, but this I can only tell you by seeing your domain structure.