Tech proposal for dealing with aliases

[IljaN]

Problem

We're required to import users using an alias, so a exporting a "user1" can be imported as "user001" in the new server.

While this could be easily done if all the user data was isolated, correlated data between users can be a problem:

1. Assuming there is a A->B share (user A shares a file to user B) in the old server
2. Import B as Z
3. Import A.

Even if A isn't aliased, we need to know that B has been aliased to Z, otherwise the A->B share won't be successfully migrated to the new server because B doesn't exists.
Note that this is a case for just one share, but there could be more shares targeting more aliased users.

In addition, due to the migrate:share command we also need to know how the users have been aliased:

1. Assuming there is a A->B share (user A shares a file to user B) in the old server
2. Import B as Z
3. Run the migrate:share command for the user B

The expectation is that A will have a share targeting the user Z in the new server. This proves that we also need to have the information about the aliases in the old server.

Proposal

We'll handle the aliases information ourselves during import using a file. The reason to use a file is because we need to use the same information also in the old server as said above. We might store the information in the DB, but we'll require to create APIs to access to that information from the old server (worthy to consider for a second version)

The import:user command will accept new parameters:

./occ import:user --alias-file=<file> --alias=<user-alias> <user-metadata-folder>
./occ import:user --alias-file=/aliases.json --alias=user001 /exported/user1

Also the migrate:share will include another parameter to deal with the scenario described above

#./occ export:migrate:share --alias-file=<file> <user> <remote-server>  (use just an alias, not the file, check below)
#./occ export:migrate:share --alias-file=/aliases.json user1 https://remote.server (use just and alias, not the file, check below)

./occ export:migrate:share --alias=<user-alias> <user> <remote-server>
./occ export:migrate:share --alias=user001 user1 https://remote.server

The expected behaviour for the import:user is:

1. Get the aliases file and parse the information
2. If the alias already exists in the file, show a warning / error (this might be an accident, but it can cause problems, so better prevent further actions in this case)
3. Include the new alias in the parsed information
4. Proceed with the import process as usual. Each importer component will be responsible of getting the parsed information and manipulate the models on their own accordingly to the aliases
5. Write the updated aliases information back to the file.

The behaviour of the migrate:share command will be basically the same, with the difference that the command won't include any new alias in the file.

Tech info

Going a bit deeper, the aliases file will be handled by one specific component which will be in charge of handling the file (read and write) as well as parsing the data. This component will just fetch the data, it won't modify any model nor know anything about them.

The import:user command will use this component to check and add the new alias.

Each importer component will use this component to get the alias map and adjust their models on their own. This "model update" will only be performed by the importer component. Note that the original model musn't be modified, each importer has to clone the models it needs, update the copies and work with the copies. This should prevent components to "update twice" the same model.

Summary of new classes:

• OCA\DataExporter\Utilities\AliasesFileParser to handle the aliases file as described
• OCA\DataExporter\Utilities\AliasesHandlers\IHandler as interface for the aliasing
• OCA\DataExporter\Utilities\AliasesHandlers\ShareHandler as a specific implementation for shares