Discussion on the logic of option of deleting without recycle bin in the refactoring module

Help / Discuss
1

Hello all,

XWIKI-17401 was reported and implemented back in 12.x . It was also discussed on this thread XWIKI-17401 - Option for deleting documents and/or attachments without sending to recycle bin .

I think there was a real misunderstanding about the purpose of XWIKI-17401 when this was implemented, I wonder if we can change it now or we need to add an extra option for it (thus making it a bit more complicated).

I think the original intent (as also expressed by @mleduc in XWIKI-17401 - Option for deleting documents and/or attachments without sending to recycle bin - #20 by mleduc ) was that a user that has the appropriate rights to delete from recycle bin can take a shortcut and delete directly a content skipping the recycle bin.

More specifically, without XWIKI-17401:
As an admin, I can (with admin and/or programming rights):

  • delete a page from the UI - this will send it to the recycle bin
  • go to the recycle bin administration and delete the page permanently
    • also, I don’t have to go to the recycle bin, I can just stay on the page itself and just click “delete” in the recycle bin view.

As a regular user (with delete rights):

  • I can delete a page from the UI (or programatically), and it will go to the recycle bin
  • I cannot go to the recycle bin to delete the page permanently, the button on the UI of the deleted page is not present to allow me to delete the page from the UI.

With XWIKI-17401, the original intent was to be able to:
As an admin:

  • choose to skip the recycle bin when deleting the page in the first place, from the UI, without having to do the 2 operations. Differently said, do the 2 operations in a single one, do only one operation instead of 2.
  • this should apply to the UI but also to the refactoring API. It should be possible to write a script that would fire an operation for deletion with skipping the recycle bin.

As a regular user, nothing should change, in the UI or in the API.

What was actually implemented (and it’s a misunderstanding and a complication of the situation, from my pov), is a bypass of the right to delete permanently, applicable to all users once it’s activated, regardless of their rights.

With XWIKI-17401, what is now possible:
There is an option in the administration to allow skipping recycle bin. If this option is not activated, nothing changes compared to before XWIKI-17401.

However, when this option is activated:
As an admin user and as a regular user, I can:

  • set my user to be an advanced user, in order to benefit from the option
  • from the delete UI, I can check a box to delete while skipping recycle bin, in order to delete a page directly, without having it go to the recycle bin
  • from the refactoring API, I can start a job to do a deletion with skipping the recycle bin, and it also will delete permanently.

The problem with the current implementation is that the scenario that was intended — allowing users having rights to do it all at once — is still not possible, and a new option to bypass permanent delete rights was added, unneccessarily if you ask me.
As a corollary of this, today there is a refactoring API to fire a delete job with skipping the recycle bin, but if I use it as an admin, it will still not work as long as the option to allow permanent delete is not activated; activating the option will open it to everyone.

The whole objective of XWIKI-17401 and its urgency was to handle space tight scenarios. Right now, if one wants to do that, they need to open the feature to everyone, not only to rights holders.
Now, the “urgency” turns out to be quite relative, given that it took 5 years for me to find that the initial purpose doesn’t correspond to the result. Or maybe the option in the administration is misunderstood, and many people use it thinking that it will only allow admins to delete permanently, not everyone.

What do you think?

How should we go about the implementation of the actual need described above - new issue, change of the current implementation?
Did anybody use the option added by XWIKI-17401 ?
Do you need it for all users or only for admins? Did you know it’s working for all users or you thought it only works for admins?

Thanks,
Anca

2

This also gives us part of the “easy” way out for the original need:
Just leave the feature as it is and add an extra condition in the code, allowing users having the right to delete from the recycle bin to see the and use the option always, regardless of the state of the setting in the administration.
It makes it a bit more complicated than it should because:

  • it keeps the current “rights bypass” that this option has introduced,
  • the admin will see the option in the administration saying that permanent delete is not allowed and yet, they will see the permanent delete option on their delete UI.

but I guess it’s the easiest that can be done now.

Thanks,
Anca

3

+1

I guess we could open a vote to deprecate that setting entirely and only keep the configuration value in xwiki.properties for backward compat’ if we have some confirmation it’s not used. And personally I tend to agree that it’s probably confusing: a much better feature if there’s really an issue with space for deleting stuff would be the automatic scheduler to empty the recycle bin.

That’s true, but would be probably much less the case if the option is only available in xwiki.properties IMO, and we can even decide to deprecate and remove it entirely in few cycles.

4

Thanks for the feedback @lucaa,

From my understanding, the two main issues are:

  1. The right to skip the recycle bin when deleting content is granted to all users, but instead (when activated) should be granted only to a set of users with elevated rights
  2. Skip validation when deleting

A potential path forward is to:

  1. keep the refactoring.isRecycleBinSkippingActivated property as is
  2. introduce a new configuration to configure the group of users allowed to skip the recycle bin in the UI (with a default value of XWikiAdminGroup)
  3. introduce a new configuration to be able to skip confirmation (but I’m -0 for that one since having to skip the recycle bin is dangerous and supposed to be exceptional in case of critical lack of disk space)

That way admins can grant the skipping action available to a trusted group of users, be they admin of some sort or power users trusted to clear content without the recycle bin safety net.
They could possibly do it quickly with the configuration to allow skipping the validation activated.

On the scripting side, we could also introduce an option usable only with script rights, allowing devs to explicitly skip the recycle bin when necessary.

WDYT?

5

I’m not sure I understand the value of the above proposal, compared to how it’s complicating the situation even further, by introducing a new right, basically, the right to delete permanently, that can be given to a group or something (but in xwiki.properties :slight_smile: ).

The permanent delete action already exists (in the form of deleting from the recycle bin) and it already has some rights associated to it (admin, if I am not wrong). Why not just use the same access control? (which is my proposal and was my need from the very start for this issue).

That way admins can grant the skipping action available to a trusted group of users, be they admin of some sort or power users trusted to clear content without the recycle bin safety net.

What is this need for? Why a new group? there is already a group that can delete things permanently - the admins - they just need to do it in 2 steps: delete to recycle bin first, and then go to recycle bin and delete from there.
Do you have a specific usecase, besides the theoretical exploration, that needs other people than admins to do this kind of permanent delete? (regardless of the number of steps)

Thanks,
Anca

6

Basically here, if we do implement what you proposed, the next question will be:

But why can’t a user from this special group delete items from the recycle bin, if they can delete them directly without putting them in the recycle bin? Why once they put them in the recycle bin they cannot delete them permanently from there?

And so we need to code some more, to make these 2 things coherent, only to maintain a feature that we never really needed / wanted to have, and for which, a priori, we don’t really see the practical application.

Thanks,
Anca

7

I get your point.
In this case, limiting the existing refactoring.isRecycleBinSkippingActivated setting to only allow it for admins is fine with me.
It’s a breaking change, so it’s going to have to go through a vote, but I’m expecting it to pass.