addDomainQuery() and (un)expected results

[rushputin]

I'm running into an issue with addDomainQuery() not, apparently, really making a bit of a difference, and I'm not sure if I'm doing something wrong or what.

Our instance is domain-separated, and one of our domains has a larger set of choices for Impact & Urgency.   It looks, more or less, like this:

Label	Value	Domain
1 - High	1	global
2 - Medium	2	global
3 - Low	3	global
4 - Minor	4	SUBDOMAIN

For the most part, this works fine: if you're in SUBDOMAIN, Impact goes to 4; if you're not, it goes to 3.

However, we've got a requirement to default to the lowest (ie: largest) available value.   So, if you're in SUBDOMAIN, it should default to 4, otherwise it should default to 3.

This is an example of how I'm trying to do that:

function getImpact(current) {

    var gr = new GlideRecord('sys_choice');

    gr.addEncodedQuery('nameINtask^element=impact');

    gr.addDomainQuery(current);

    gr.orderByDesc('value');

    gr.query();

    return (gr.next())

        ? gr.value;

        : '';

}

I've got a query, I use addDomainQuery() and provide the record (which, at this point, has had its domain set), and... no matter what domain the record gets, I always get 4.   (I've also tried this by just sending in the domain ID and even a full domain GlideRecord, with no change.)

Now, I have Visibility into TOP.   And, when I run this script as different users with reduced visibility, it returns the largest value that user can see.   So: a user with visibility into SUBDOMAIN gets a 4 and a user without it gets a 3.  

But this shouldn't have anything to do with the user running the query: it should have everything to do with the domain specified by addDomainQuery().

What am I missing?   How do I say "Give me this data as if I were in this domain?"

[BobbyNow]

Richard,

The choice table has its own proprietary logic for determining what choices to show for domain separation. It is not meant to be queried against directly for this reason. Your script is fine as written and it is returning the correct results based on domain separation. In your example you always get back 4 because parent domains can see the data in children domains and the sys_choice table is a data table.

If you are using data lookup definitions for setting priority based on impact and urgency you can add sys_domain and sys_overrides to the dl_u_priority table and override the combinations as needed. When you create a new record the priority will not immediately show if the impact and urgency are not toggled, but when you save the record it will set the correct priority. If you need the priority to be seen on load you can use a script in the priority default value field on the dictionary to read the correct priority and set it.