Salut tout le monde !
Je suis nouveau ici, je commence à m’impliquer au Cloud Girofle (et dans les Chatons plus généralement) en essayant de développer des trucs qui manquent dans les plateformes utilisées. Et je commence par Mattermost, que je déploie aussi dans un collectif où je suis actif.
Une fonctionalité manquante de Mattermost qui m’intéresse est le problème de l’export/import d’une équipe (sans prendre toute l’instance Mattermost avec elle). C’est quelque-chose qui n’est pas supporté pour l’instant et j’ai eu des retours de plusieurs hébergeurs indiquant que c’est un problème qui embête pas mal de gens.
Comme c’est une fonctionnalité un peu lourde j’envisage de faire une proposition de design au projet via leur forum. @Maxime m’a suggéré de vous faire part des plans ici aussi, pour vérifier si ça vous semble aller dans la bonne direction. Donc voilà le brouillon ci-dessous (j’espère que c’est pas un problème de le poster en anglais ici).
Sinon j’ai découvert les problèmes de limites d’utilisateurs et le fork Framasoft… si j’ai bien compris le fork n’a pas vocation à diverger autrement qu’en faisant sauter les limites donc je compte essayer de contribuer cette fonctionalité dans Mattermost directement. Ça vous va ?
Voilà ce que je compte leur proposer.
Mattermost: Support for team import/export
Problem statement
As a team admin in Mattermost, I want to be able to download an archive containing all the data that makes up my team and import it in another Mattermost instance (concerning private data, see the Design details section).
Broader context
Currently, Mattermost only lets system admins generate a dump of the entire instance (containing all teams), via the mmctl export command. There is no built-in way to filter the dump to only contain a single team. As a result, hosting providers which host multiple teams in the same instance (such as framateam.org or girofle.cloud) are unable to offer migration options for their users. This goes against the portability expectations associated with an open source platform and might also be incompatible with regulatory requirements in some jurisdictions or industries.
Relevant feature requests
Team admin should be able to export datas
Mattermost Bulk Export Single / Selected Team
High-level design
Unlike the current instance-wide export functionality, team exports would be available via the web UI. In the “Team Export” dialog, a new “Import / Export” tab is added. In this tab, the user is able to:
- Generate a new export. This triggers a job to prepares the corresponding archive. For a given team, there can only be one export job at a time. The archive is made available for download once the job is complete. Only the archive generated by the latest export job can be downloaded and the time at which it was generated is shown. It expires after some delay.
- Upload an archive for import in the current team. This also starts a background job to perform the import. A team can only have one import job at a time and the dialog shows the state of such a job, if any.
Design details
User management
One major hurdle consists in the fact that user accounts are defined at the instance-level and not team-level. Despite that, users need to be exported and imported as part of a team export.
When exporting a team, user accounts belonging to this team are exported as well. Users who have left the team should likely not be exported, meaning that their interactions will then appear as deleted users in the imported team (to rejoin the team after migration, they need to create a new account).
When importing a team, one needs to merge the list of users supplied in the archive with the list of users already present in the Mattermost instance. The usernames supplied in the archive need to be changed in two cases:
- An existing user has the same email address but a different username. In this case, the username of the existing user is used instead of the one in the archive
- An existing user has the same username but a different email address. In this case, we generate a new username for the user to be imported (appending a number to the username and incrementing this number until the username is free).
Once new usernames have been assigned to the users to be imported, we need to rewrite the rest of the archive’s contents to update them with the new usernames where needed. A logic similar to the one already implemented in mmctl (for Slack import) can be used.
One could consider giving the opportunity to the user to provide a mapping from old to new usernames themselves but I think this is rather complex so I would leave this out of a first version of this feature.
Handling of private data
It is an important product decision to determine whether private channels and direct messages should be part of a team export, as including them makes them accessible to the team admin.
Similarly, the export will expose personal information from users that team admins might otherwise not be able to see, for instance the email address or full name if the “Show Email Address” or “Show Full Name” options have been turned off.
To address those issues, the generation of exports could be guarded by a permission flag (or multiple flags) that could be configured on the team admin role by the system admin. Or make team export and import only accessible to site admins (which does not introduce any privacy issue since they already have access to this data through the existing instance-wide export).
Archive format
The export format for a team should ideally follow that of an instance-wide export. The ability to use a team export as an instance export containing a single team would simplify the user experience, avoiding to create multiple types of exports which need to be imported in different ways.
If a team export is indeed the same thing as a single-team instance export, then care needs to be taken that importing such an export by a team admin only accepts dumps that contain a single team and is not able to make changes to any other teams than the current one.
Implementation strategy
The implementation could be broken down into the following tasks:
- Add a
--team
option to the mmctl export create command, implementing corresponding filtering - Add support for automatically renaming users during an import to avoid integrity violations as outlined above. This feature would also be available when importing entire instances with multiple teams.
- Expose team export from the web UI, possibly introducing the necessary permission to control availability of the feature.
- Expose team import from the web UI