feat: Prevent Attachment Deletion

[barredterra]

This pull request introduces a feature to restrict the deletion of attachments for submitted transactions. This is supposed to prevent the accidental or malicious deletion of documents we are legally obligated to keep. We assume that all files attached to a transaction are such documents.

Restriction on Attachment Deletion:

• Added a new setting prevent_attachment_deletion to the ERPNext Germany Settings.
• Implemented the logic to prevent the deletion of attachments for submitted transactions based on the new setting.
• Added a hook to trigger the restriction logic when a file is trashed.
• Added code to load the new setting into the client-side session defaults.
• Added client-side code to hide the remove button for attachments if the restriction is enabled.

Documentation and Localization:

• Updated documentation to reflect the new restriction on attachment deletion.
• Added translations for the new messages related to attachment deletion restrictions.

[0xD0M1M0]

I personally would extend the applicability to submitted and cancelled and not just submitted. You want to keep records that are in the system, even when not applicable anymore.

Additionally, why only apply the file deletion on sales and procurement and not to accounting, specifically journal entries and assets. Some bookings are for a contract, payroll or just the bank, where you want to still keep the attachments saved.

[barredterra]

I personally would extend the applicability to submitted and cancelled and not just submitted. You want to keep records that are in the system, even when not applicable anymore.

I'm not sure about this yet. For now, I deliberately chose the less intrusive way. I think in combination with PDF on submit, the validation of cancelled documents could prevent some legitimate deletion use cases (submitted by accident, PDF created automatically, no document left the system, I want to undo my mistake).

„Nicht aufbewahrungspflichtig sind z. B. reine Entwürfe von Handels- oder Geschäftsbriefen, sofern diese nicht tatsächlich abgesandt wurden.“ (GoBD)

Additionally, why only apply the file deletion on sales and procurement and not to accounting, specifically journal entries and assets. Some bookings are for a contract, payroll or just the bank, where you want to still keep the attachments saved.

Makes sense, done.

[0xD0M1M0]

Started the review (will use this comment as collection):

• Check with accounting department and HR, which documents need to be locked
• Functional check
• Clarify if bug or feature or ignore: When the same file (content) is uploaded with a new name, the old file renames. Content of course stays the same.

[0xD0M1M0]

I checked with my accounting department and payroll team and identfied DocTypes that should be added:

• Expense Claim (tax authority requirement due to direct payment of expenses to employee and because invoices may be attached depending on use-case)
• Business Trip (tax authority requirement due to direct payment of expenses to employee and because invoices may be attached depending on use-case)
• Asset Depreciation Schedule
• Asset Repair (due to possible value change)
• Asset Value Adjustment
• Asset Capitalization
• E-Invoice Import
• POS Invoice
• Dunning
• Business Letter
• Period Closing Voucher
• Contract (if company collects documents here, likely they want to keep them safe)
• Blanket Order

[0xD0M1M0]

Extend list if file.py is extended

[0xD0M1M0]

When uploading a new file in the submitted state, the list of attachment reloads and the "hide" is temporarily gone. Server side check still prevents from delete.

Same principle when uploading a file in draft. One the site is reloaded the icon to "delete" is hidden, so the file cannot be removed client side from the document. Server side does not prevent deletion as intended.

[0xD0M1M0]

I would extend this to docstatus 1 & 2 ( if docstatus == 0: ). If a document is cancelled, it does usually not matter if a file is attached or not. It is quite clear, that it is cancelled. On the other hand, it prevents the document from being deleted, which is of course a drawback (but in terms of GoBD better). For the case, that something was attached by accident, I would opt for a grace period of maybe 10 minutes after file attachment. That also allows to quickly fix a wrong upload to a submitted document.

Possible solution for check if file can be deleted in docstatus 2. If the user has the permission to delete the document, he can delete the file.