Move and rename attachments

Development
#1

Hello all,

I’d like to introduce my work on the integration of the possibility to move and rename attachments.

You can find the corresponding design page here Attachments Move and Rename (Proposal.Attachmentsmoveandrename) - XWiki.

This work will be composed of 3 main tasks:

  • offering an UI and an API to move and rename attachments
  • automatic refactoring of attachments (i.e., references to attachments, for instance on images, are automatically renamed after a move or a rename).
    • this will require to maintain a list of relations between attachments location and use of attachments locations
  • automatic redirection from old attachment location to new attachment location

I propose to start by working on these tasks in this order. Until refactoring and redirection are implemented, the UI will include warning inform users of the consequences of their actions.

User Interface

I propose to keep it simple in a first time and to integrate a button next to the delete button in the attachment panels, and to introduce a page following the same pattern as the one we currently have for page rename and move.

Screenshot 2022-01-07 at 15-16-10 Sandbox - XWiki

image

Architecture

I propose to introduce two new modules xwiki-platform-attachment-api and xwiki-platform-attachment-default.
The API provides the scrip services, templates and roles for the attachments operations (currently move and rename but could en enriched later).
The default module provides the default implementation for the roles defined in the API.

Let me know what you this and if you have suggestion on how to make this improvement better.

PS: Some related technical topics will need to be discussed in other discussions, for instance the database table to use to map the location and user of the attachments, or how to minimize disk-usage by prevent attachments duplication on disk.

#2

I’d rather not leave the page just to rename / move an attachment. It’s OK for a first version, but on the long term I’d rather use a modal. Also, we may want to separate rename from move(+rename). I’m thinking that most of the time the user will just want to rename the attachment, which should be done quickly by simply typing the new name in a text input, ideally in-place.

#3

I fully agree.

Regarding the modal, once the “static” version is done is shouldn’t be too difficult to move to this.

For the quick rename, I started to think about it and while it is for sure a feature that will be used often, but integrating cleanly the advanced options (redirect/refactoring) is more challenging.

Also note that, at least for images, we have planned some improvements to choose the name of the attachment directly from the CKEditor.

#4

… how would the history of an attachment be handled with this new functionality?

#5

I would expect to have the same behavior as for document rename (move the history too).

#6

OK. Since there are a few things with attachments that are “odd” IMHO or I don’t know how to handle properly. Let’s assume there is a page version with an attachment version 1.3 and the current page has the attachment version 1.16. If I display the page with in the history with attachment version 1.3, the attachment tab will still show the current version of the attachments, not the historical view. Only way to access the attachment version 1.3 was to restore the page to the version that had attachment version 1.3, which causes the attachment version to be bumped to version 1.17 … This is not related to renaming directly, but in general … Renaming an attachment will then start at version 1 of the new “file name” or ??? Will renaming an attachment create a new copy of the file in the file system as a restore of a page will do (I assume it does)? Sorry if this is not directly related or an uneducated user concern.

#7

Sounds like a bug.

There is a much simpler way to access any version of the attachment you want: clicking the attachment version number leads you to the attachment history view.

Attachments have their own store and history storage, they are not really stored in the document, even if it’s how the UI (and the page export) makes it feels like.

#8

How embarrassing is this! My simple mind didn’t expect that … great! Thanks for the hint …

Tested with 13.9 and the history view of a page shows the most up to date attachments and not the one attachment version corresponding to the page version => https://jira.xwiki.org/browse/XWIKI-19301

#9

Thanks !

#10

I was thinking that we could have:

  • rename: quick, in-place, no options (use defaults)
  • move+rename: show modal with advanced options, show progress, show log, etc.

When you want to rename quickly using the defaults, you would use the simple rename. If you want to rename but without updating the backlinks for instance (i.e. you don’t want the default settings) then you use the move+rename, which allows you to do just rename, but shows the options (in the modal). Just an idea.