incident_SLA list security constraints

[Uncle Rob]

I'm getting a weird issue that I can't duplicate on a private dev instance.   ITIL user clicking on a dashboard widget that opens a list of Incident_SLA records.   They get the "Security constraints" error.   Same error if they try to go directly to incident_sla via url.

So I turn on security debugging and.... nothing.   Just line after line of...

But no failures logged for read on incident_sla.

Meanwhile on private dev instance, itil user accesses it just fine.

[Deepak Ingale1]

If I am correct, incident_sla is view configured using task_sla table and incident table.

OOB, there are ACLs on task_sla , but nothing on incident_sla.

I guess you might require to create READ ACL for incident_sla   Or there might be property difference in your personal dev instance and customer one

Database views

ACLs and database views

You do not need to create ACLs on fields in the view. The system honors contextual ACLs (ACLs with a condition or script) that already exist on the underlying table. Non-contextual ACLs (ACLs with only role checks) are still honored just as with previous releases.

You can revert this functionality to legacy behavior and require explicit read ACLs to be added to the database views. Set the glide.security.expander.view.legacy property to true. For upgraded instances, add this property to the system, and set it to true for the same legacy behavior in pre-Istanbul releases, or set to false to use the new behavior.

You can still create additional ACLs on the database views. These ACLs are evaluated last and are always honored.

[Deepak Ingale1]

Another interesting article what I just came across

Use a Read ACL on Database Views when Reporting in Fuji

[Uncle Rob]

Can't be right.   I'm on a fresh dev instance with an itil user that can access the incident_sla view and there's no associated acls beyond what's on the joined tables: incident / task_sla

[Uncle Rob]

Thanks for coming to my aid,