Description

This document propose a design to support renaming and moving attachments. (and copying?)

In addition, renaming and moving attachments must trigger a refactoring to update existing references to attachments in (sub-)wikis.

Use cases

• copy?
• rename
• move
• refactors references on copy/move
• maintain a list of relations between referenced attachments and references of attachments.
• create redirections from old name to new name
• prevent file duplicates on the filesystem (i.e., if two files have the same hash, they should not be stored twice, even if they have different filename in the wiki)

Other ideas:

• Replace a given attachment with a new content

Concerns

• Copy and disk space: If we provide an operation to copy attachments (or even in the case where users upload the same file several time). It could be interesting to provide a mechanism to keep only one file on the filesystem. This is especially important for instances with limited disk space such as cloud instances.
• The list of relations between referrers and referee is useful both the refactor attachments references, but also to list the list of usage of an attachment in the wiki.

Design from alternative products

• Notion: No notion of attachments. For instances images are "anonymous" and adding twice the same images means uploading it twice.
• Mediawiki:  Files are independent from pages (i.e., they are attached to a given page)
• Confluence: ...

User Interface

This section currently proposes two design axis, one looks similar to the way we currently move and rename pages by visiting a dedicated page, and one is a draft of proposition to lower the number of full page reloads required to make a move.

Proposition 1

This proposition keeps the same workflow as the one to rename pages and spaces. The users is redirected to a dedicated page where a form is proposed to move or rename an entity. Most of the UI stays the same except for some vocabulary (e.g., page is replaced by attachment). And some irrelevant options are removed (e.g., the notion of terminal page does not exists for attachments).

Proposition 2

Possible ideas to make some actions faster than switching to a new page

• Renaming could be done using the same UI as in-place field editing (a button to switch to edit mode, then two buttons to validate/cancel the edition). Note: It can make it difficult to propose advanced choices such as refactoring/redirection choices.
• Proposing the same UI as proposition 1, but in a modal screen opened dynamically when clicking on the edit button. Note: This alternative can be implemented in a second time once proposition 1 is implements, as an improvement.

Redirection

When an Attachment.Code.RedirectAttachmentClass XObject with the name of the requested attachment is found in the document containing the attachment, the user is redirected to the new location of the attachment.

Attachment.Code.RedirectAttachmentClass contains the following fields:

sourceName: the name of the attachment before the move

targetLocation: the document containing the attachment after the move

targetName: the name of the attachment after the move

Database

See https://xwiki.markmail.org/message/7s2ondchhhgomuum and https://jira.xwiki.org/browse/XWIKI-8346 for discussion regarding performance issues linked to the current way to store relations between referrer and referee.

In summary, the relation between a referrer and a referee is made in the wiki containing the referrer. This makes is easy to list all the pages linked by the current page. But listing all the pages linked by the current page, while not much expensive on the current wiki (a simple query on the xwikilinks table), becomes expensive as soon as many sub-wikis exist, since we need to look over each sub-wiki to repeat the query on each of them (since each wiki has its own database).

The proposed solution is to introduce an xwikibacklinks table listing all the links towards the entities of the current wiki (basically the reverse of xwikilinks, which list all the instances of the current wiki referring to something).

It would contain the following columns:

• xwrl_doc_id: this identifier of the referee document
• xwrl_referee: the serialized reference of the referee entity (which is from the same wiki as the database)
• xwrl_referrer: the serialized reference of the referrer entity (which can possibly be from a distinct wiki from the database)

Refactoring (documents and attachments)

• https://jira.xwiki.org/browse/XWIKI-12318
• https://jira.xwiki.org/browse/XWIKI-8346 The issue is fixed since some part of the refactoring of backlink was indeed broken. Now please note that by default the update of link on farms is not supported for performance reasons: it currently involves to iterate over all subwikis. This should be fixed with XWIKI-16192. Now you can still force the update of link on farms by setting the property updateLinksOnFarm of a refactoring request to true before performing it.
• https://jira.xwiki.org/browse/XWIKI-16192
• https://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/DocumentLifecycle/#HLimitations-1

A first proposal has been made in that direction in https://xwiki.markmail.org/message/7s2ondchhhgomuum to create a dedicated backlinks table as part of this refactoring to help managing them in all wikis.