GlideAggregate_Query - Insufficient rights to query records

XuanYingY
Tera Contributor

yesterday

I was trying to pull the data using glideaggregate query data source in UI builder to populate for a component.

 

But there's a data fetch exception. the event payload

{

    "dataElemId": "aggregation_query_2",

    "errors": [{

        "message": "Query: Exception encountered processing field: GlideAggregate_Query - Insufficient rights to query records",

        "errorType": "DataFetchingException",

        "path": ["GlideAggregate_Query"]

    }],

    "__uxfCompositionElId": "27bf535347655a90cfc5457c736d43bd",

    "options": {}

}

 

it works for admin but does not work for other users. I checked all the ACLs are correct and the users can see the relevant records. 

0 Helpfuls
  • 147 Views
2 REPLIES 2

Matthew_13
Mega Sage

yesterday

Hi Buddy,

This usually comes down to field-level access, not table access.

The GlideAggregate data source runs fully server-side and is stricter than lists/forms. Even if a user can see the records, the aggregate will fail if they don’t have read access to every field used in the query (filters, group by, dot-walks, or the aggregate field itself).

That’s why it works for admin but not for other users.

What you can do:

  • Check read ACLs on all fields referenced in the aggregate (especially group by and any dot-walked fields).

  • Watch for scripted ACLs that behave differently outside normal list/form access.

  • Impersonate a failing user and turn on Debug Security Rules — it will show exactly which ACL is blocking the query.

If you don’t want to open up field access just to support aggregates, the safer pattern is to use a scripted data broker that returns only the summary values you want and enforces your own authorization logic.

 

@XuanYingY - Please mark Accepted Solution and Thumbs Up if you found Helpful!

0 Helpfuls

XuanYingY
Tera Contributor
In response to Matthew_13

an hour ago

Hi Matthew,

Yup, i double-checked. My field level access (table.* and table.fields) are all there (read, query_range, query_match), there are also no scripted ACLs
i also checked:

  1. Impersonate user via script and queried with glideaggregate - it works
  2. Impersonated user and created a report with the exact query - it works

  3. Impersonate a failing user and turn on Debug Security Rules — there was no error. I tried debug graphQL and i could see that the glideaggregate query was executing without any errors, it seems like there is only problem with Data Fetching?

A bit more information, My instance is domain separated. I think i will find a workaround using either reports or scripted data broker as you adviced. Thanks

 

 

0 Helpfuls