Currently, XWiki always store deleted documents in a recycle bin, including the attached documents.
That might lead to large space use overtime, or even blocking situations due to low disk space (see XWIKI-17401).
To address this issue, we propose to add an option to allow user to skip the recycle bin when removing documents.
Since that’s an irreversible action, it should be:
clearly advertised as dangerous in the UI, so that user does not mistakenly perform this action.
be proposed only to advanced users.
be activable by the administrators.
For the user, this action takes to form of a set of radio buttons on the document removal.
If the feature is not activated, the current message “Are you sure you wish to move this page to the recycle bin?” is displayed, without the radio buttons.
For the administrators, the configuration of this feature can either be:
A configuration key in xwiki.properties: edit.document.skipRecycleBin.enabled = false.
The default value for the option is false, ie, the feature is not activated by default.
Activating this feature only opens this operation to users that choose to Advanced user type in their user settings.
WDYT?
Which alternative do you prefer regarding the administration?
After considering both options, introducing an XClass for the configuration of whether or not advanced users are allowed to choose to send documents to the recycle bin or delete them permanently is the best option.
Allows to change the setting without restarting the server
Easier to test
You will find below a screenshot of the new configuration screen.
The corresponding code will be placed in a new xwiki-platform-refactoring-ui module.
Do you agree to place this new menu in the “Others” section?
Do you find the title and hint of the property clear enough?
Is it a real need? It’s quite a specific feature so personally I wouldn’t be chocked to have it only in xwiki.properties.
I don’t really understand this argument: for unit tests it should be a config API easy to mock, and for integration tests AFAIR we can specify custom properties, so it shouldn’t be an issue.
Not really, I would have put it in Editing I think.
The hint is a bit confusing IMO since you don’t have a clear information about what Yes stands for when reading it.
For the docker tests it is important, it allows us to perform all the tests related to the deletion of documents in a row.
It is also nicer from an UX point of view.
Agreed
What do you think of the sentences below?
When set to Yes, allows advanced users to choose whether they want to send documents to the recycle bin or delete them permanently when deleting a document. When set to No, documents are always sent to the Recycle Bin if it is available, otherwise they are always permanently deleted.
I think we should always be able to make config changes without restarting the wiki, except when it’s just too technically complex (for example when it needs to init at startup time, like changing the document store or stuff like that).
This brings added value.
I don’t think it clutters the Admin if it’s well organized in the right categories.
Tests are users of XWiki so it’s interesting to listen to them. In this case they’re saying: you cannot modify the config at runtime. And indeed it’s true and it’s a need. Note that restarting a wiki requires an infra person and in lots of companies the wiki admin doesn’t have access to the infra.
Personally I like a Refactoring section because I think there could be more options and the Content section is already quite full. Also it’s not the same level as other Content options which could be more important. That’s why I was asking whether we have other options already or not.
Seems we don’t, only one which is supposed to be removed ASAP (refactoring.rename.useAtomicRename = true).
I can imagine other options in the future related to the generic domain of Refactoring in a wiki.
Now the option to be able to send docs or not to the recycle bin doesn’t feel very “refactoring”. I wonder if the refactoring module was the right place for that… The fact that Simon and Marius both suggested other sections makes me feel that the config property might not be in the right place.
BTW I asked Manuel already on the PR (no answer at this point) but we need to decide if that option applies also to attachments or not. I’m mentioning this here since it impacts the hint description.
