GlideRecord update restricted by ACLs or Application Scope...?

[mattybrodriguez]

Recently we've been having issues relating to GlideRecord use in scripts.  We send out notifications to end-users who then reply to these with certain values, which we use to trigger related inbound actions, business rules, etc. in the system, often utilising GlideRecord to update cases, tasks and other records.  We've noticed that a lot of the time, users attempting to do this fail where admin users succeed - leading me to believe this is related to ACLs.  Has anything changed recently in regards to this?  I remember this was working at one point and is now causing us issues.  Additionally, does anyone know what I could do to bypass the ACLs using GlideRecord (without impersonating an admin user in the script)?

[Gaurav Bajaj]

HI,

I am afraid impersonation is the only way out if you don't want to tweak the ACL to accommodate users to update their ticket.

If the user is caller/opened by/watchlist, then they should have access to update the ticket.( if table is extended from task table).

Thanks

Gaurav 

[mattybrodriguez]

I have tweaked ACLs to enable my test user to create,write,read and execute on all of the involved tables - so at this point I am at a loss - is there some underlying mechanism stopping external users from running GlideRecord updates?

[Gaurav Bajaj]

Hi,

Did you verify that enabling these ACLs are actually reflecting or not?

You can try login/impersonating the end user to see if they can update/view the relevant record manually as well or not?

We had same scenarios few days back and it was sorted based on the ACLs only so I don't think anything else is obstructing. You can place some log statements in inbound action to see where it's getting stuck.

Thanks

Gaurav

[mattybrodriguez]

Yes unfortunately I can confirm as I use log entries to test and validate my inbound action scripts - it is definitely getting stuck on "<gliderecord>.update()" 😞