If "editing files continues to work" means live sessions will carry on fine, this is not possible if things like etags and last modified timestamps will change. Unfortunately moving to a different file backend will make us lose information that identifies files in the new "filesystem" with their versions in the older one.

The user story is ambiguous, in that either Eva moves a document, for which, at that moment, a collaborative editing session exists, from one storage backend to another, or the corporation switches storage backends as a whole.

In the former scenario, Eva would have access to multiple storage backends in parallel, putting forth certain requirements on Manticore, such as an API call to move a document from one URI to another URI, to be triggered by Chwala.

The latter scenario is a migration track with many more "liberties" -- including modification of line items while the service is off-line; i.e. with a service window.

I think the use-case to be considered is the one where Eva herself triggers the initial copy of the data, and subsequently wishes the existing collaborative editing session to continue to operate as it was.

This would suggest that at least the following API calls to Manticore to be available;

1. I am who I say I am,
2. "Rename" the "URI" of the canonical location of this document (for the particular collaborative editing session) from URI $x to URI $y,
3. Possibly exchange (additional) access credentials (if different) from those used against source URI $x to target URI $y[3].

Naturally, authentication against Manticore for this is required; it is also needed, however, to verify access to the original and target document location, as well as authority over the document (namespace, folder rights, ... [1]) as well as the collaborative editing session[2].

In order of the numbers associated with the annotations, rather than the order;

[1]: The ownership of a personal namespace is quite clear, albeit there are ways to make the owner of a personal namespace no longer "own" the folders within that personal namespace. However the ownership of folders in the shared namespace and other users namespace is not so clear, and requires further clarification for this use-case. Would we require administrator rights on the folder, or just the necessary rights to read-and-purge the document from the old location? To what extend do such individual rights translate between the source and the target (say, from IMAP to Seafile), but then also, between the target and the source (say, back from Seafile to IMAP)?

[2]: Who "owns" the collaborative editing session, and/or who would be considered sufficiently authorized to change parameters of the collaborative editing session? Any participant? Those considered owners of the original source of the document (see [1])?

[3]: A target URI's service that does not use, or otherwise requires not the exchange of credentials but instead requires per-application level authorization (with so-called application authorization tokens), would not be able to automatically use existing sets of credentials, and between a client (Roundcube, if not it's kolab_files plugin, if not chwala) and that target, an exchange of credentials would be needed in whichever form negotiated/required by said target service.

Other then those constraints, for which application-level modifications lay not in Manticore but elsewhere (as well), a parameter that is the current canonical location of the "original" document (or new copy thereof), for which the collaborative editing session had been created, should be pretty easy to modify and adhere to.

[1] The most convenient solution would be to have administrative rights available handy to work on a shared folder. If, however, only a system that exposes individual rights is possible, then enough exposure of who has what permissions on a source document is required.

[2] Given the current WebDAV support in Manticore, if multiple users have access to the same document on the WebDAV server (so not just within Manticore), the user who first opened the document is marked as it's "owner". This is done because having an owner/creator is important, and a lot of WebDAV servers including iRony don't expose this information on files (or, for that matter, ACLs), so we do the best we can.
Generally speaking, the one authorized to change the parameters of the session should be the owner(s) of the original source of the document, yes.

In T723#10323, @Adityab wrote:

[1] The most convenient solution would be to have administrative rights available handy to work on a shared folder. If, however, only a system that exposes individual rights is possible, then enough exposure of who has what permissions on a source document is required.

An individual user never holds "administrative" rights of the same level you seem to be referring to. An individual may, however, have administrator rights on a given folder (personal, others or shared namespace alike). This is called the 'a' right in IMAP, and does not imply any other access directly; One can have the 'a' right, but not the right to read the contents of the folder. In this scenario however, the 'a' right does imply the right to give one-self also the 'r' (read) right.

In T723#10323, @Adityab wrote:

[2] Given the current WebDAV support in Manticore, if multiple users have access to the same document on the WebDAV server (so not just within Manticore), the user who first opened the document is marked as it's "owner".

This means the "session owner", correct? IOW: The owner of the copy of the document as it resides in a collaborative editing session in Manticore -- not exactly the same as the "owner" in Kolab/IMAP, because a single folder (and therefore the files contained within it) can have multiple users with access that would make them be considered "owners".

In T723#10323, @Adityab wrote:

Generally speaking, the one authorized to change the parameters of the session should be the owner(s) of the original source of the document, yes.

We are not in disagreement, but we'll still need to establish who can reasonably be considered the "owner" of a document even in its original location, and especially also, define what we think are reasonable user expectations / provides the better and/or more intuitive experience.

I would like to invite @vincent to comment and share his thoughts on.

Should Manticore use Chwala as it's storage backend, Manticore would not be involved in fulfilling the requirements in this particular user story -- it would just speak to Chwala and leave the canonical location for the document origin to be the URI to Chwala.

This is provided that;

• Chwala can communicate the authorizations associated with a file/user (T483).
• Chwala can provide Manticore with a "static" URI to operate on the document, that is independent from the location at which the document may reside at any point during the collaborative editing session. I.e., the URI could be /chwala/some-doc-id, but not /chwala/shared/sales/files@example.org?UID=1;msgpart=2.

I need to add that Chwala will likely want to apply a type of lock that allows the file to be marked as being locked (in a collaborative editing session) in other UIs (webclient), rather than just "a lock". This lock could be of such type, amended with such identifier, as to establish the static URI for Manticore to speak to.

In current implementation Manticore does not know the real file path, so the magic have to be done on Chwala side.