Unify DMS Content deletion

[PeterTakacs300]

Description

At the moment there are two methods for deleting DMS Content and related records:

• deleteContent
• deleteContentWithPhysicalDocument

The deleteContent method is used e.g. in WDMSPanel, when opening the context menu with right click on the content thumbnail, and clicking on the delete menu item:

This method does not delete published files, so after deleting the DMS content like this, the files remain on the publish storage provider, and eventually fill the disc.

The deleteContentWithPhysicalDocument method is called e.g. from WDMSAttributePanel:

This method deletes the files from the storage provider too.

Proposal

The goal of this issue should be to refactor or unify the deletion methods to avoid filling storage provider disks with files that does not have DMS Content anymore, and allowing to use the delete method from automated processes too. This means to support deleting in a single transaction - as currently the deleteContentWithPhysicalDocument method runs with no transaction.

Patch: add transaction support to deleteContentWithPhysicalDocument method

We have a solution for this, I can provide a patch later for review

[dpansheriya]

@PeterTakacs300 , By design DMS has soft delete so admin can restore the content. Not sure why behavior at two places are different but both button should do soft delete.
Once soft delete done then the user with permission for permanat delete can delete all DMS content from backend.

So here if we are enabling Delete to perform hard delete then it will not be recoverable, so in that case it must driven by permission. I will find out exact flow of cleaning storage.

[PeterTakacs300]

Hi @dpansheriya

We discussed about this with Igor and Norbert. Igor says that the soft delete solution does not have an advanced recovery solution, so it just avoids the deletion of the stored content on file system.

Norbert mentioned about Alfesco's solution (it's not necessary to implement it, just referring): they have a "bin icon", when the user deletes, the meta layer is updated - moved to the bin - but either the file or meta layer is untouched (associations should make the new relation to bin and should keep the original association to recover the original file location). The user would able to manage their bin as a special directory and by selecting recovery, return the file to the original location.

Regarding to permission, we should check permission, then use a new setting which defines "delete to bin" or "delete immediately" - same concept as bin in any operating system.

In our case the api user with permission without moving content to bin should delete by using the same (unified) refactored delete method, supporting transactions and all above concepts.

For the transaction support, we've implemented in deleteContentWithPhysicalDocument to use the transaction from MDMSContent content - this will ensure that the whole method runs in the same transaction instead of sending a separate trxName parameter.
Patch: trx_support_for_hard_delete.patch

Wdyt?

[sbhimani12]

Hello @PeterTakacs300

Here’s a summary of the response to the your’s points:

1. Physical Deletion in AttributePanel:

   • The approach will change from physical deletion to soft deletion or remove the delete button in the AttributePanel form. [ Meanwhile Delete button disabled in that form - so user can't delete physically at the moment ]

2. Soft Delete:

   • For soft deletion, when a user deletes content, the DMS admin will still be able to view the deleted documents. The admin can check for deleted content using:

     • Role → Is DMS Admin flag to determine admin rights.
       

     • In the Document Explorer window, the Documents View option can be used to filter by:

       • All (all documents, including deleted)
       • Deleted Only (only deleted content)
       • Non-Deleted (non-deleted content)
         

3. Permanent Deletion:

   • Currently, no solution has been implemented for permanent deletion. This will be handled in the future as a separate option.

4. Transaction Support:

   • For transaction patch and confirms that will implement transaction handling and its utilities to ensure consistency in the deletion process.

In summary, the focus is on soft deletion with admin-level visibility, and while permanent deletion isn’t yet addressed, the transaction support patch is appreciated and will be implemented.

[sbhimani12]

Change committed:

For Point no 1:

Commit: b74607d [b74607d]
#17 Remove Delete option from Attribute Panel

For Point no 4:

Commit: 6e4cef1 [6e4cef1]
#66 When a table record is deleted, the afterDelete/model handler event should ensure the deletion of the associated DMS referenced records.

[norbertbede]

hi @sbhimani12

which branch you are commited pls

Norbert