Dear Experts, How to disable delete action & button in Attachment panel or provide limited access to users delete attachment.
Hi Hari,
IMO “Limited Access” + Users making occasional mistakes would lead me to warning messages and audit log notations over throwing exception or making delete impossible. Also, if user proceeds with delete and it is not warranted, if file copy to a repository is being done, you can always get it back out of the delete folder in there…
I would create bpms that throw a warning message for the particular attachments where deletion is a great concern and then if they proceed to do so, write data to the audit log to note user deleted it since system does not store delete record info in audit log at this time.
Nancy
1 Like
Hi Nancy, Thanks for your support. Could you pls share the code?
The attachment panel seems to be protected from accessing inside the customization code. If we try creating a BPM on (for example: Purchase Order > Method Directive > Pre Processing). I’m able to throw an exception if we click delete on attachment panel by checking the row state. Point is the file references in the XFileAttch remains intact however the physical file has been moved into the delete folder.
Does anyone have a suggestion on this subject? @hkeric.wci
One suggestion is to use a more robust file storage system like DocStar, which gives one very granular control of file permissions.
Why not use the Service Security options on the BO.Attachments Business object and the DeleteFile in BO.Attachment Method
You can then define access to this option at the Security Group and/or user level
1 Like
BO is not used when client system direct copy is setup for attachments.
All, Appreciate your response. However, I have managed to do this as two steps.
Step 1: I have written a code in the attachment tool click to lookup all the buttons available on that particular form, identify the delete button and disabled it. However, the problem does not stop there. Users can click on the attachment and use the “X” on top to delete that.
Step 2: If you trace the delete event on attachment panel and the delete event on “X”, the delete event on “X” will call the GetAttachmentPath method but the former doesn’t. which give me the flexibility to write a BPM to see the path and throw the exception.
As @Olga mentioned we cannot use the service security for this.
Actually, this is one of my first post in the help group and I’m pretty happy to see some nice suggestions and responses.
Many thanks. NR.
1 Like
There’s only one less-likely but potential place left exposed for more technical users. They can still browse to the actual folder through Windows Explorer and delete the file from there since they need write access to put the file there in the first place. So you might have to add some extra folder security to existing folders and make sure that cascades for new folders as they are created.