XWIKI-17401 - Option for deleting documents and/or attachments without sending to recycle bin

To summarize, we have 2 settings:

  • xwiki.recyclebin indicates whether a recycle bin is available
  • canSkipRecycleBin indicates whether a user can choose to skip the recycle bin

Behavior 1
When xwiki.recyclebin is false, all the documents are always removed permanently.

Behavior 2
When xwiki.recyclebin is true and canSkipRecycleBin is false, the behavior is the same as before 12.8RC1, documents are always send to the recycle bin (including their attachments).
The same is true of the children if the user choose to remove them too.

When xwiki.recyclebin is true and canSkipRecycleBin is true, the behavior 2 applies if the user choose the first option (sending the document to the recycle bin), and the behavior 1 applies if the user choose to remove the document permanently/.

If the logic presented above is agreed upon, I will update the javadoc and hints to make this as clear are possible to devs and users.

Regarding the topic of the configuration, I agree that it is counter intuitive to place a document removal into a refactoring section.
However, afaicw no existing section fully match the scope of this newly introduced settings.

On possible approach could be to introduce a xwiki-platform-page-management module dedicated to the management of the configurations of operations related to the pages.
In this case we could introduced a Page management sub-section in the Editing section.

WDYT?

From xwiki.cfg AFAIR and with an old naming style :wink:

You mean behavior 1 I guess :wink: (for the first reference).

It seems correct.

I think it’s fine in the refactoring module if we consider that removing something is called a refactoring. However it has consequences and it means that anything related to removing pages or attachments must be eventually moved to the refactoring module (UIX for the content menu, delete templates, etc).

Even the xwiki.recyclebin property needs to be deprecated and replaced by a refactoring.recycleBin.enable config property and RefactoringConfiguration needs to have an API for that. Maybe we need to list all places where delete is done and check if it makes sense to eventually move them to the refactoring module. Ofc the doc/attachment stores shouldn’t be moved. I’m only referring to APIs (java and scripting) and UIs here.

Do we agree about this?

Not sure if it really means this but we need to ask ourselves the question. I’m on the fence here. But I think it makes sense that both xwiki.recyclebin and refactoring.canSkipRecycleBin are put in the same module (eventually).

The hard part is that delete is currently both a model feature and a refactoring feature. Maybe the refactoring module should only concern itself with performing the refactoring and not the deletion, and thus have the model do the deletion and call the refactoring module to perform additional operations. In this case it would mean that the recycle bin configs are model configs and not refactoring ones.

If we consider that removing something is called a refactoring, I agree.

+1

Another point to consider, in addition to the backend design of the page deletion operation, is how it is perceived by the end users.
I don’t thinks I would look for a page deletion related setting in a refactoring section.
Some alternatives could be:

  • Content -> Pages
  • Editing -> Pages
  • Pages -> Pages

This is why I’m on the fence and far from sure that the refactoring module is the right place for this config property.