query_range on data-driven ACLs
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-21-2025 09:31 AM - edited 05-21-2025 09:32 AM
Hi all,
We're experiencing some woes due to query_range ACLs. I'm still trying to get up to speed with these so I thought I'd ask the community how they are tackling issues like these. In advance, I have to apologize for my vague example here, but needs must.
Let's say for the sake of argument that we have two fields on the incident table. u_audience can be set to either A or B. u_somedata contains information that should be masked if a user does not have the appropriate role. These users search u_somedata quite frequently, and it was mostly added to make searching and reporting simpler. We cannot simply disallow searching on this field.
At current, this means the field has two read ACLs:
- Read ACL 1 for incident.u_somedata:
current.u_audience == 'A'
(with a role_a role requirement) - Read ACL 2 for incident.u_somedata:
current.u_audience == 'B'
(with a role_b role requirement)
Some users have both role A and role B, but most have only A.
The problem arises with before_query business rules, which can't seem to replicate this behavior. It blocks querying on this field for both A AND B users.
The ideal behavior would be this: non-role-B users would not see any errors, but they also would not get any B results when searching on u_somedata. If there are results for A and B, they would ONLY get A results, with no "rows removed" or error messages.
In the past, we have achieved similar results with before query business rules on row-level ACLs, but I cannot for the life of me think of a good solution for this case.
Here's the solutions we've thought of so far:
- Split u_somedata into u_somedata_a and u_somedata_b. This will make things easier but it will also complicate searching for users who straddle both environments.
- Allow users in role_a and role_b to search on u_somedata. It's not ideal and opens us up to blind queries.
Anything else I've tried doesn't seem to work, and the sparse documentation around the OOB Security Attributes is not making this easier.
So I ask the community: How do I get from A to B? Is there any way to accomplish our ideal behavior here?
Appreciate any help or advice you can offer. Apologies again for the vague example, please let me know if I need to clarify anything at all.