[Sprint Goal] Avancer Tartine : design technique d'une feature

[celiacheff]

Faire le design technique d’une feature à choisir

Objectif bonus : implémentation

Le design doit être fait avec précautions, pour éviter le plus possible de modifier Elément. Checker avec Travis qu’on utilise la bonne méthode.

[estellecomment]

Une feature simple pour commencer : création de room.

• où est le composant existant à remplacer, dans le code element ?
• quel code on va écrire ? Quels appels serveur, quel composant, etc (s'inspirer du code tchap de v2, et de element)
• quelle methode de customisation utiliser ? (webpack file replacement, customisations, autre ? Checker avec Travis)
• Optionnel : les externes. Est-ce qu'on peut faire un truc temporaire à la place ? Ou on les ignore pour le moment.
  • les externes ne peuvent pas créer de room
  • il faut pouvoir creer des rooms avec ou sans externes.

[celiacheff]

WIP:
J'ai effectué une recherche sur le sujet, et testé un peu le component. Ce que j'ai appris:

Component incriminé (et autres fichiers utiles)

v4 et en version js en v2:

• le composant: matrix-react-sdk/src/components/views/dialogs/CreateRoomDialog.tsx
• matrix-react-sdk/src/createRoom.ts
• matrix-js-sdk/src/client.ts

Code à écrire

• Le code de v2 est assez simple, mais un gros rafraîchissement serait bienvenue (on peut simplifier la liste de params envoyés au serveur - federate par exemple, etc...
• En appel serveur, c'est des variations de la fonction L98 en v2. Le onFinished de la fonction est définie en V2 dans MatrixChat.js L972. Il y a donc une modif sur le client, en réalité que pour les externes avec le flag isExtern, mais je n'ai pas cherché assez loin pour voir si on peut s'en passer au final (a checker avec les ops, et avoir mes remarques sur les externes ci-dessous).
• Sur V4, le code est dans MatrixChat.tsx L1034, à noter que comme déjà en v2 le createRoom possède son propre fichier createRoom.ts, ce qui est sympa pour des overrides localisé (le code est bien plus propre).

Customisation

• Testé comme le custom server picker
• autres options disponibles:
  • customisation.json (juste du webpack sous le capot)
  • modules Element (dont on est sans infos)
• J'ai aussi pas encore testé la possibilité de faire de l'héritage sur un component (au lieu de repartir de 0, faire un truc comme TchapCreateRoomDialog extends CreateRoomDialog et du coup on peut partager du code en commun et on défini uniquement ce que l'on veut changer.
• Aussi la possibilité de faire ça avec carrément le MatrixClient pour que l'on puisse le customiser sans toucher au js-sdk

Externes

• Si on modifie tout le component, on peut simplement checker si l'utilisateur a dans le HS 'e.' ou 'externe.' comme sur la V2. Mais il faudrait vraiment avoir des vrais ACL, ou un flag.
• On a aussi la possibilité de masquer facilement le component pour les externes en rajoutant le petit bout de code a la fin de https://github.com/vector-im/element-web/blob/develop/docs/customisations.md
• Je me demande aussi si on pourrait pas simplement écraser le setGuest dans client.ts pour renvoyer notre définition d'un guest ( un externe au lieu de juste un HS différent) facilement (mais j'ai pas eu le temps de vérifier toutes les implications qui pourraient être peut être très positives, surtout cumulées avec les options/restrictions standard d'Element pour les guests) (ou négatives si y'a des effets secondaires :/). Il me semble qu"on a tout de même des notions de guests qui sont pas des externes dans nos flows, mais je n'en suis pas certain, à vérifier avec Giom.

[estellecomment]

Brain dump de Giom sur ce sujet, dans https://www.notion.so/Diff-rences-entre-Element-et-Tchap-329cf4d20ce840a3b53e29dd2d76f0f0#f54d6d57743d497aafce90935e0c0044.
Je nettoie mes notes pour vous les transmettre.

[estellecomment]

Details d'implementation (pas forcément exhaustif):

• Notre dropdown choisira TchapRoomType (comme celui d'android), alors que celui d'element choisit JoinRule.

• Les options qu'on devra spécifier au moment de la room creation sont dans CreateRoomDialog.tsx, this.roomCreateOptions()
  Les options passées par element :

  • name : le nom du channel
  • Topic : on en a pas ?
  • Join_rule : public, invite, restricted
  • noFederate : false (tchap veut tjs federer, c’est a dire autoriser les users de tous les homeservers)
  • parentSpace : on touche à rien (sauf peut etre avec le join_rule ?)
  • associatedWithCommunity : les communities sont bientot deprecated, replacees par les spaces, on y touche pas

Version Tchap :

• Join_rule : salon=invite, forum=public.
• Access_rule : pour salon sans externe et forum : restricted. Pour salon avec externes : unrestricted
• Encryption : true pour salon, false pour forum
• Preset : public_chat pour forum (ca met guest_access=true, mais on peut le override)
• History_visibility : shared pour forum, joined ou invited (?) pour salon
• Guest_access : disable partout

Overall je suis pas convaincue que preset soit tres utile, ca ajoute de la confusion, puisqu’on l’override ensuite (mais peut etre que ca rajoute des options utiles plus tard ?).

[estellecomment]

Les points de customisations proposées par element n'ont pas l'air de couvrir ce qu'on veut. Donc je pense pas qu'on pourra utiliser customisations.

Du coup, c'est webpack file replacement, il reste que ca (puisque replaceableComponent est deprecated)

[estellecomment]

Précision sur domain et federate :

• les salons sont tjs federated=true (c'est a dire les users de toutes les instances peuvent les rejoindre)
• les forums laissent federated au choix de l'utilisateur : on peut limiter à l'instance de l'utilisateur, ou non.
  • exception pour les utilisateurs de l'instance agent qui n'ont que des forums federated (??? a verifier) Edit : parce que les users de "agent" ne comprenaient pas l'option, à cause du nom "agent" qui n'est pas clair, et apres ils contactaient le support parce que ca ne faisait pas ce qu'ils pensaient.

[estellecomment]

Première version mergée !
Reste à faire :

• Undo les changements d'interface sur le toggle de federation. Pour décider de changer, il faudrait faire des user tests pour vérifier que c'est utile, et aligner tous les clients sur le changement. (discussion en cours là : https://github.com/tchapgouv/tchap-design/issues/73) Donc pour le moment on revient à l'identique de v2.
• Le comportement spécifique de l'instance agent (ou intradef pour le moment) est hard-codé. Ca permet pas de tester en preprod par exemple, puis que ca ne marche que pour le domaine agent.tchap.gouv.fr. (PR draft en cours [refactor] Get room federation options from config #59)
• Unit-tester le nouveau composant. On a testé que la logique métier pour le moment. Faudrait tester le composant pour vérifier que quand on clique les boutons, ca fait bien ce qu'on pense.
• Faire tourner les tests de matrix-react-sdk (Olivier est train de les patouiller je crois)

On a pas pris en compte les spaces, et si il faut des options spéciales (par ex "Visible to users in the space"). C'est hors-scope parce qu'on sait pas vraiment encore ce que fera Tchap pour les spaces.