Migration plan

[icewind1991]

User migration

UI

• migration can be triggered from both the receiving and sending side.
• migration can be triggered from api, occ and personal settings.
• list of apps that are supported during the migration is shown

Apps

The "core" path only consists of the ui and triggers a hook with the migration details.
All apps that have data to migrate listen for the hook and handle their own migration using
(mostly existing) api's to get the data from the remote server.

Data

Data is always pulled (even when from a ui perspective the migration is push)
since the receiving end requires more migration specific logic.

Files

• Use the regular dav access to read files from remote.
• Use etags to skip files/folders that are already equal on both sides.

Encryption

• Not handled explicitly, files are simply re-encrypted transparently, this way
  differences in encryption setup will not cause problems.

Trash and versions

• New dav endpoint that exposes the trashbin and versions.
• dav endpoint can be reused by apps/webui in the future.

Contacts and Calendar

• Use existing cal/carddav for export.
• iirc there is existing import logic in place.

Shares

• Use existing ocs api to receive shares
• For incomming fed. shares, a new one is created from share source
• For outgoing fed. shares, the share origin is changed on the share target.

Activities

• Use existing activity api