Mattermost: permettre d'exporter et importer les équipes indépendantes

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:

  1. 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
  2. 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:

  1. Add a --team option to the mmctl export create command, implementing corresponding filtering
  2. 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.
  3. Expose team export from the web UI, possibly introducing the necessary permission to control availability of the feature.
  4. Expose team import from the web UI
3 « J'aime »

Tout à fait.
Après espérons qu’iels n’aient pas envie de garder une telle fonctionnalité pour leur édition entreprise, comme l’est déjà le plugin mattermost-plugin-channel-export.
https://docs.mattermost.com/comply/export-mattermost-channel-data.html

Si jamais c’était refusé pour le cœur de Mattermost, ça serait probablement plus pratique d’intégrer ça sous forme de plugin, si c’est possible.

En tout cas, bon courage et merci, clairement il y a de l’attente pour une telle fonctionnalité.

H.S : Pour besoin d’export générique (pas besoin de réimport) on a récemment forké ce script Python pour le rendre à nouveau fonctionnel :

3 « J'aime »

Chez @Paquerette @oiseauroch a fait un gros travail pour migrer certaine équipe Mattermost vers d’autres instance.
Par contre cela implique toujours d’exporter l’ensemble des données pour faire le tri dedans …

C’est peut-être un projet de développement commun pour les chatons ? :thinking:

Yep, c’est justement ce travail que je voudrais éviter aux gens en contribuant cette fonctionnalité (dans Mattermost directement ou sous forme de plug-in, à voir).

C’est peut-être un projet de développement commun pour les chatons ? :thinking:

Dans la proposition ci-dessus, il y a plusieurs tâches indépendantes donc qui peuvent potentiellement être réparties, si ça en amuse d’autres :slight_smile:

Super proposition :smiley:
On nous a déjà demandé plusieurs fois chez Picasoft aussi, et on aurait bien aimé répondre favorablement aux demandes !

Des retours sur la proposition :

  • Je pense que c’est pas ok d’exporter les messages privés. Par contre les channels privés, ça se discute en effet !
  • Je pense que je rêve, mais ce serait génial (et plus RGPD) d’avoir un export qui demande individuellement à chaque membre de l’équipe s’iel accepte d’avoir ses messages exportés via un bot, et qui ne réalise l’export qu’après avoir une réponse de tout le monde ou après un délai de X jours configurable. (Et ça permettrait au passage aux users de renseigner leur compte sur la nouvelle instance) (Si ça t’intéresse, coder la partie chatbot me botte)
  • Je ne sais pas si c’est pertinent de réaliser l’import sur la nouvelle instance au sein d’une équipe existante. Je me dis qu’il vaut mieux faire une transition d’une équipe à l’autre la plus « atomique » possible ? Et j’ai peur des conflits de noms de channels et/ou de users. (C’est un « je ne sais pas », pas un « mauvaise idée »).

Hâte de voir ce que ça donne tout ça, c’est très excitant !

1 « J'aime »

Je pense que c’est pas ok d’exporter les messages privés. Par contre les channels privés, ça se discute en effet !

Potentiellement, ça pourrait aussi être « tous les canaux privés auquel la personne faisant l’export a accès »… Parce que la distinction entre canal privé et message privé peut être assez ténue je trouve, non ?

Je pense que je rêve, mais ce serait génial (et plus RGPD) d’avoir un export qui demande individuellement à chaque membre de l’équipe s’iel accepte d’avoir ses messages exportés via un bot, et qui ne réalise l’export qu’après avoir une réponse de tout le monde ou après un délai de X jours configurable. (Et ça permettrait au passage aux users de renseigner leur compte sur la nouvelle instance) (Si ça t’intéresse, coder la partie chatbot me botte)

Ouais @Maxime a eu la même réaction (que j’ai sèchement balayé de la main :face_with_peeking_eye:)… Ça me semble effectivement assez compliqué à mettre en place, il faudrait réfléchir à comment représenter ça dans l’export (on supprime les messages des gens qui n’ont pas accepté, j’imagine, mais quid des fils de discussion qui commencent sur un tel message, par exemple ?)

Bonjour @Pintoch. Bienvenue sur ce forum ! :smile_cat:

Il y a eu une discussion similaire sur ce forum discourse mais concernant les fonctionnalités propre à discourse. Mais elle doit pouvoir s’appliquer à Mattermost.

Une partie du problème peut-être solutionné en anonymisant l’auteure des contributions à un fil de discussion.

Je remarque qu’on a vu apparaître sur ce forum la formule «message supprimé par l’auteur» . Dont certains des miens :upside_down_face: . Et effectivement il y a un bouton «corbeille» sur lequel il m’arrive de cliquer…accidentellement. (Je crois pas qu’il était présent depuis que je publie sur ce forum.)
Même si des fils sont désormais «avec des trous», ça reste globalement compréhensible.

Ma conclusion est qu’il ne faut pas s’obstiner à vouloir tout conserver et à tous les prix mais bien accepter de perdre de l’information et ainsi continuer à avancer.

2 « J'aime »

Merci pour tous ces retours !

Une manière potentiellement plus simple de recueillir le consentement avant l’export serait d’offrir un champ dédié dans chaque profil membre (c’est quelque-chose qui peut être fait avec un plugin Mattermost, si ça ne peut pas être fait nativement). Ça me semble intuitivement plus facile que de faire un bot à la « feedbackbot ».

J’ai retravaillé la proposition et l’ai postée dans le forum Mattermost:

1 « J'aime »