ACL not working: no write/create if Parent Closed/Canceled?

[JP-ODU]

I thought I was trying to make a very basic change on our incident_task table, namely: it should not be possible to create or edit incident tasks if the parent incident is state: closed or canceled.

To that end, I went to the incident_task table and first tried editing the existing ACLs that control write and create based off of role: itil. I used the condition builder to dot-walk to Incident fields and added Condition: Incident.State | is not one of | Closed, Canceled

However, this had the unintended effect of preventing the creation and editing of any incident tasks, at all? Even open, active incidents. 

2nd try: I removed the conditions from the itil ACLs. Then, I went to incident_task table and added two entirely new ACLs, one for write and one for create. They simply set the condition for write and create to Incident.State | is not one of | Closed, Canceled

But that's still not working? Now, the result is that I can still edit and create incident tasks on closed incidents, even with that ACL running.

3rd try: I went for the inverse. 2 ACLs, write and create, condition: Incident.State | is one of | New, Open, On Hold

But I can still create and edit incident tasks on closed incidents.

Can anyone please tell me what I'm doing wrong?

[Allen Andreas]

Hi,

Sorry, your post is a bit confusing because you're saying:

"To that end, I went to the incident_task table and first tried editing the existing ACLs that control write and edit based off of role: itil. I used the condition builder to dot-walk to Incident fields and added Condition: Incident.State | is not one of | Closed, Canceled"

So what you've mentioned above doesn't affect "create". That is a separate ACL type.

I want to make sure we're talking about the same ACL type as for starters, you would review all "create" ACL's for this table, then, if they are currently allowed to do 'x' and you don't want that, you'd edit the current ACL to prevent 'x'.

It sounds like you're saying you did that, but I'm not seeing a specific callout for "create" ACL type and instead see "write/edit" and then some unintended outcomes dealing with create...but not clear.

Out of box on my personal developer instance, there's 2 "create" ACLs for the incident_task table. You'd have to ensure in both of those that the user wouldn't pass those ACLs. So you'd need to look at both and see and/or adjust.

I've just tested this myself by disabling 1 of the 2 ACLs, and then adjusting the remaining one ACL (which has itil role involved) to this:

And while the "new" button shows on the incident task related list on a closed incident (that's a separate thing you need to adjust), if they click the new button, the entire form is grayed out and they can't submit:

Please mark reply as Helpful/Correct, if applicable. Thanks!

[JP-ODU]

Sorry, for the confusion, to correct terminology: I'm trying for two separate ACLs, on create and write. The intent is that, if the parent Incident is in state or closed or canceled, then users should not be able to edit or create new incident tasks for them.

I have tried 3 variations, with both create and write ACLs:

1. Modified existing create and write ACLs that required role: itil. Kept role: itil, added condition: Incident.State | is not one of | Closed, Canceled. Result: prevented itil from editing or creating any incident tasks.

2. Reverted the itil create and write ACLs to just role: itil. Added new create and write ACLs with condition: Incident.State | is not one of | Closed, Canceled. Result: users can still create and edit incident tasks with closed or canceled parents

3. Swapped the conditions of the new ACLs from attempt 2. The condition is now Incident.State | is one of | New, On Hold, In Progress. Result: users can still create and edit incident tasks with closed or canceled parents

[Allen Andreas]

Hi,

I would just focus on "create" first.

Please re-read my post above. There could be multiple ACLs for "create" for that table. Just because you see an easy target with "itil" specified in the ACL, it does NOT mean they don't also qualify for the other ACL.

So both need to be reviewed.

As I mentioned above and provided screenshots. I've literally just done this from a simple "create" ACL perspective on the incident_task table and it does not allow them to save/submit on a brand new incident task for a closed or cancelled incident. It does allow them to save/submit on a brand new incident task for an incident in any other state.

Once you successfully handle "create", then you can rinse and repeat on "write", with "write" perhaps being a bit more complex due to table level ACLs and table.* ACLs.

Please mark reply as Helpful/Correct, if applicable. Thanks!

[JP-ODU]

Sorry, I'm attempting to make sure we're aligned, but my results still don't seem to be the same. 

1. I deleted my trial ACLs

2. I ensured that there is a single create ACL on the incident_task table (the one for role: itil)

3. I modified that one ACL to add condition: Incident.Incident state | is not one of | Closed, Canceled, matching your screenshot

4. Impersonating an itil user, they're able to create new incident tasks on canceled and closed incidents. The New button appears, opens to a form with active, fillable fields, and allows them to save a fresh, new incident task to closed and canceled incidents

I don't understand what's missing

5. If I flip it, taking the single create ACL (requires role: itil) and setting the condition to Incident.Incident state | is one of | New, In Progress, On Hold, or Resolved then the "New" button is removed from the incident task form for itil users, regardless of state