ITIL user unable to delete attachment when ritm is closed complete/incomplete

[Ashwin Perumal1]

@swathisarang98 

I wanted to restrict ITIL role users to edit/remove attachments from portal or from backend view. For incidents as you mentioned in one post I could see 2 OOB ACL which restricts ITIL role users to edit/remove attachment when incident is closed/cancelled. Similarly how could I restrict ITIL role users to edit/remove attachment in RITM when state is closed complete/incomplete.

I am not able to find any OOB ACL similarly like incident. Can you pls share your inputs if you are aware of it. Thanks in advance.

[Community Alums]

Hi @Ashwin Perumal1 ,

The 'Manage Attachments' popup on a record is a UI page of attachment wherein removing the 'Remove' button will remove the button globally, and not specific to a table.

Restricting users from delete attachments on a table can be achieved by adding a before-delete business rule

Note: In this method, we are allowing users to click on the 'remove' button and the attachment disappears with the UI behavior; but when you reload the record, the attachment shows up (because the attachment was never deleted on the server-side because the business rule operation has aborted the action)

In below examples, the before-delete business rule restricts users other than Admin to abort deleting the attachment on the 'sc_req_item' table

Name: Restrict Delete attachment on RITM
Table: sys_attachment
Advanced: check
When: Before
Delete: check

Filter Condition: Table Name is sc_req_item

Script Conditon:

(function executeRule(current, previous /*null when async*/) {

// Add your code here

if(!gs.hasRole('admin')){

current.setAbortAction(true);

}
})(current, previous);

[Maik Skoddow]

This is the OOTB behavior and shouldn't be changed! An closed incident represents an conserved state and shouldn't be changed afterward as this would lead to confusions taking a look on it. And closed incidents often also act as the base for knowledge articles, therefore NEVER touch a closed incident!