Data Filtration Issue - Returning a script error on updates

[Robert Crawley]

Hello All. I have an issues with Data Filtration that I haven't been able to sort out, so I'm hoping someone out here can point me in the right direction.

We have the following Data Filtration parameters configured

Set up a custom field on Task, Data Filtration(u_data_filtration)

This is a choice list with the choices Tech, Legal, Finance, and Neutral

Have ACL set up for admin and a neutral_read, for read, write, and create access to u_data_filtration

3 Groups: 

Tech

Legal

Finance

4 Data Filtration Records

All of these records are set to the Task table, and with cascading set to True.

Tech Filtration defined as subject group is Tech or Role is admin, data condition is Data Filtration is Tech

Legal Filtration defined as subject group is Legal or Role is admin, data condition is Data Filtration is Legal

Finance Filtration defined as subject group is Finance or Role is admin, data condition is Data Filtration is Finance

Neutral Filtration defined as subject group is Tech subject group is Legal ubject group is Finance, data condition is Data Filtration is Tech

For the most part this works as expected, users in the Tech group can't see records in Legal or Finance and Legal can't see those in Tech and Finance, ditto for Finance.

Our issue though is when someone from finance or legal submits a catalog request that sends a task to the tech team, the tech team can't update their task.

Request's data filtration is set to Legal

Request Item's Data Filtration is Tech

When the RITM's assignee attempts to update, they receive a script error.

Error Message: 

onSubmit script error: TypeError: Cannot read properties of undefined (reading 'display'):

function() {

   saveAllSelected([ gel(id) ], [ gel(ref) ], ',', '\\', '--None--');

   }

This error is actually something of a red herring, the issue is that the assignee user can't read anything from the parent request since they don't have access to it. I played around in our dev system moving the request to the Tech filtration 'scope" and then the assigned user could see the Request # field on sc_req_item and they could make an update without error. When I flipped the Request's filtration back to legal or finance, the assigned user couldn't see the Request # field and received the script error. Logging shows that the users are failing the legal and finance filtration items, but I wouldn't think that would be the case since the Request Item has the proper Data Filtration set, Tech. I'm assuming this is more because the request # field is referencing a record they don't actually have access to because of the respective filtration record conditions? Is there any way to get around that? I did set up a Data Filtration Table Exclude for sc_req_item, which does seem to be a workaround but that opens up all the request item data to everyone and doesn't feel like an ideal solution. I opened a few NOW support cases on this one, but they didn't have a solution other than fixing the rules.

I know there's a change coming to Data Filtration with Yokohama, but we're not there yet so I was hoping I could resolve this ahead of that.