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

Development
#1

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.

Screenshot_2020-08-18 rm me - XWiki(1)

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:

  1. A configuration key in xwiki.properties: edit.document.skipRecycleBin.enabled = false.
  2. A new entry in XWiki.XWikiPreferences:
    Screenshot_2020-08-18 Global Administration - XWiki

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?

#2

I like the principle/idea.

However we need to work on the English wording a bit :slight_smile:

#3

To be clear: we don’t display the “skip” checkbox by default, right?

#4

Also we should change the message from “are you sure … to the recycle bin”.

#5

Suggestion:

“Skip the recycle bin” --> “Permanently delete the page (it won’t be put in the recycle bin)”.

#6

I wouldn’t show this to simple users. For me skipping the recycle bin is an advanced operation. And yes, the wording needs to be improved.

#7

+1 on this

#8

My proposition was to have this feature activated by default. So, to display the “skip” checkbox by default. I’ll make it deactivated by default.

I’ll take into account the other observations and make a pass of the wording soon and update by initial post.

#9

+1

#10

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.

Screenshot_2020-08-31 Global Administration - XWiki

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?

Thanks

#11

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.

#12

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.

#13

“Preferences” (plural) :slight_smile:

Do we have other refactoring options?

Seems ok.

Thanks!

#14

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.

#15

I don’t think Editing is right. Maybe Content.

#16

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.

#17

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.

#18

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.

#19

BTW we don’t use the “documents” terminology in the UI. Only “pages” :slight_smile:

#20

IIUC the original intent is to be able to remove both the document and its attachments permanently under some conditions:

  • having the right to do so (ie, being an advanced user and having the proper configuration activated)
  • explicitly choosing to do so when removing the document.

Good to know, I’ll update the hint accordingly.