How to Prevent Delete of Upload File in "File Attachment" type field

[Michael Gedzelm]

Hi All.  The problem I'm having is NOT related to attaching a file to a ticket/record or using "Management Attachments" at the top of a form. This problem is completely separate and is about the "Delete" link that appears next to an uploaded file for a field that is of type "File Attachment".  There is both an Update and Delete link there.  If I click "Delete", the attachment is instantly deleted from the record (actually deleted from sys_attachment, which is associated with this record), despite the fact that it is mandatory and that I haven't clicked the Save button.  It should not allow a user to delete the contents of a mandatory field and save these changes instantly to the database (no warning, no save button).  That's really really bad behavior.  

I tried messing with ACLs and BRs on the sys_attachment table for Delete and that almost worked, but the problem is that I want to allow Updates to the attachment, and prevent Deletes.  The Update link for a File Attachment type field actually does a Delete and an Add in the sys_attachment table.  So, if I prevent Deletes from sys_attachment, it actually causes the "Update" link to fail as well (since it's trying to delete and then add).

In summary, how can I prevent deletes of a "file attachment" type field while allowing updates?

If you have had this specific issue and have fixed it, I'd love to hear from you.  Thanks.

[Saloni Suthar]

Hi @Michael Gedzelm,

You should be able to restrict access to who can remove an attachment with a delete access control rule on the sys_attachment table. Please review the community post for the solution. The solution has a different logic but it should help you.

[Michael Gedzelm]

Saloni,

Thank you for response.  However, your answer is exactly what I specify in my second sentence that my issue is NOT about.  Your response is about "manage attachments" and I stated that my issue is not about that, but it is about "file attachment" type fields, a very different thing.  I then went further to specify that I want to allow the "Update" link to work for these fields but not the "Delete" link.  I then specified that "Update" links on file attachment fields actually perform a "Delete" and then an "Add" on the sys_attachment table, so using a delete ACL on the sys_attachment table  will also prevent the update, which is not what I want.

I'm looking forward to responses from people who understand exactly what I'm having a problem with, who have experienced it personally, and have solved it.  Thank you!

[Community Alums]

@Michael Gedzelm 

Preventing deletion of attachments in ServiceNow while still allowing updates, especially for mandatory "File Attachment" type fields, requires a nuanced approach due to the way ServiceNow handles file attachments (the Update action involves a delete and add operation). Given the constraints you've described, here's a strategy you might consider implementing:

1. Custom Client Script (Before Delete Confirmation):

   • Create a custom client script that intercepts the "Delete" action on attachments. This script can check if the attachment field is of a mandatory "File Attachment" type and display a custom confirmation dialog explaining that deletion is not allowed because the field is mandatory.
   • If possible, this script could be configured to only trigger under specific conditions (e.g., only for certain tables or form fields).
   • Note: Client Scripts can manipulate the DOM or intercept user actions on the client side but manipulating the default behavior of the "Delete" action for attachments might be limited by the ServiceNow platform capabilities.

2. Business Rule to Prevent Deletion:

   • Implement a before delete Business Rule on the sys_attachment table that checks if the attachment being deleted is associated with a mandatory "File Attachment" field on any record.
   • The Business Rule can prevent deletion by using current.setAbortAction(true); if it determines that the delete action should not be allowed.
   • However, as you noted, this will also interfere with the "Update" action. To address this, the Business Rule could:
     • Temporarily store the attachment information (e.g., in a custom table or in memory).
     • Allow the delete to proceed only if an immediate add operation follows (indicating an update). This would be complex and might not be entirely feasible due to the way transactions are handled.

Note: This is a complex solution which needs through understanding of the functionality that we are trying to achieve. The alternative would also be creating a custom attachment field and then customizing it.

If my response has resolved your query, please consider giving it a thumbs up ‌‌👍 and marking it as the correct ✅ answer‌‌!

Thanks & Regards,

Sanjay Kumar

[Michael Gedzelm]

Thank you Sanjay for your detailed response which clearly indicates that you have a thorough understanding of the issue I am experiencing.  The following sentence is something you wrote and is an absolute requirement if I am to proceed with this solution:  "Allow the delete to proceed only if an immediate add operation follows (indicating an update). This would be complex and might not be entirely feasible due to the way transactions are handled."

Accomplishing this is exactly where I'm stuck.  The delete business rule would have to know the future, that is, that an add operation is coming.  Without this, the approach is not workable.  I wouldn't even know where to start to accomplish this.  If you (or anyone in the community) have any ideas about how a business rule could know of future transactions I would greatly appreciate it.

Thanks,

Michael