BUG : je veux créer un nouveau salon dans un espace dont je suis admin

[Raphaelrobert65]

TLTR;

• bug : when a admin create a room in a space, it is available in the space welcome page the day after
• see : https://github.com/tchapgouv/tchap-web-v4/issues/881#issuecomment-2302052876
• Workaround : créer les salons en dehors des espaces, puis de les ajouter manuellement un par un aux espaces, en cochant la case "Visible pour les membres de l'espace" dans les paramètres généraux.

Story

En tant que membre de l'Espace sur Tchap, Je souhaite pouvoir créer des salons et des forums dans l'Espace directement depuis l'Espace, Afin de rendre le processus plus fluide et intuitif.

Description du Besoin

Actuellement, dans la gestion des Espaces sur Tchap, la procédure pour rendre les salons et forums visibles à tous les membres de l'Espace est complexe.

Elle nécessite de créer les salons en dehors des espaces, puis de les ajouter manuellement un par un aux espaces, en cochant la case "Visible pour les membres de l'espace" dans les paramètres généraux.

Actuellement, si on crée un salon dans l'Espace, il n'est pas ajouté à l'Espace automatiquement, et en plus, l'option nécessaire pour l'ajouter à l'Espace dans les Réglages/Sécurité et Vie privée n'est pas affichée. On ne peut donc plus le rajouter à l'Espace dans lequel on souhaitait le voir apparaître.

Le besoin est de simplifier ce processus. L'objectif est de permettre aux utilisateurs de créer directement des Salons ou Forums depuis l'Espace. Les nouveaux salons ou forums créés de cette manière devraient automatiquement apparaître dans le listing dédié de l'Espace et être visibles pour tous les membres de celui-ci.

Critères d'acceptation

• En tant qu'utilisateur, je devrais avoir la possibilité de créer un salon ou un forum à partir de l'Espace.
• Une fois créé, le salon ou le forum doit être automatiquement visible dans le listing dédié de l'Espace.
• Les paramètres par défaut du salon ou du forum doivent permettre une visibilité pour tous les membres de l'Espace.
• Les membres de l'Espace devraient être en mesure d'accéder facilement au nouveau salon ou forum

EDIT : Version de Tchap : 4.4.3 Version crypto : Rust SDK 0.7.0 (b1918e9), Vodozemac 0.5.1 Steps to reproduce:

• avec un compte agent A1
• créer un espace
• créer un salon S1
• inviter un user agent B
• se connecter avec le user Agent B
• accepter l'invit pour l'espace
• BUG : le agent B ne voit pas le salon S1
• avec l'admin A créer un salon privé S2
• BUG : le agent B ne voit pas le salon S2

Workaround : créer les salons en dehors des espaces, puis de les ajouter manuellement un par un aux espaces, en cochant la case "Visible pour les membres de l'espace" dans les paramètres généraux.

[estellecomment]

magnifique issue, tres clair :)

[Nivann]

https://github.com/tchapgouv/tchap-product/issues/128

[estellecomment]

Testing what we currently have. Out of scope : external users.

There are 3 buttons where you can add a room to a space :

And 3 types of rooms (private, with externs, public)

In all cases the created room should have settings (Security > Access) which show : (french translation is ugly but nvm for now)

Tests for creating rooms : privé : ok for 3 buttons, settings look fine avec externes : ok for 3 buttons, settings look fine public : ok for 3 buttons, settings look fine

Un utilisateur interne invité au space peut bien voir les nouveaux salons : non. Pas avant d'être invité dans le salon. Une fois invité il voit le salon dans la liste du space (pour les 3 types). Il voit bien les setting approprié, mais ce setting ne fait pas ce qu'il dit !

Creating a room outside the space, then adding it to the space using the setting (Security > Access). The setting says it is in the space, but room is not displayed in the space. For any users (space admin or not).

=> The "Security > Access setting" is broken.

[estellecomment]

Needs fixing :

• [ ] create a room in a space. Other users in the space can see the room in the space's room list.
• [ ] create a room outside a space. Add it to the space (with Security > Access)
  • [ ] room appears in the space for the room creator
  • [ ] room appears in the space for other users of the space
• [ ] Room's settings should
  • [ ] reflect whether the room is in the space or not
  • [ ] be understandable (text is understandable, no radio button if there is only one available choice)
  • [ ] allow changing whether the room is in the space or not

[estellecomment]

Fun fact : des rooms créés hier dans le space, qu'un user normal du space ne voyait pas, sont maintenant visibles. Ya un délai avant que les rooms soient visibles ?

[estellecomment]

Not found out why yet. No bug on element-web + matrix.org backend. It works fine. Bug present on element-web + tchap backend -> is tchap backend doing something ?

I think that some rooms that were not visible to a space member became visible the next day. If this is not a mistake on my side, then what happened during the night ?? Maybe worth trying to reproduce ?

Useful tips :

• how to inspect the events in a room : type /devtools in the room
• how inspect the events in a space : activate devtools in the settings (in Expériemental/Labs), then go to the home page of the space, click quick settings (wheel icon at bottom left of page), Developer Tools

What I investigated :

Matrix spec about rooms in spaces : https://spec.matrix.org/v1.2/client-server-api/#managing-roomsspaces-included-in-a-space

• a space is a room with extra field in the creation event
• rooms inside a space : m.space.child event on the space, m.space.parent event on the room (both directions).
  • “When only a m.space.child is used, the space is effectively a curated list of rooms which the rooms themselves might not be aware of.
  • When only a m.space.parent is used, the rooms are “secretly” added to spaces with the effect of not being advertised directly by the space.”
• these events look the same on tchap-web + tchap-backend as on element-web+matrix.org .

Join-rules could be involved, though I could not find anything wrong with the join-rule events. https://spec.matrix.org/unstable/client-server-api/#mroomjoin_rules

• we should use "restricted" value, with conditions describing the restrictions : content.allow : “anyone able to satisfy at least one of the allow conditions is able to join the room without prior action. Otherwise, an invite is required”. type": "m.room_membership” : if you are a member of a specific other room, then you pass the condition (in this case the "room" is the space) { "room_id": "!other:example.org", "type": "m.room_membership" },
• Restricted join rules possible for room version >= 8 (mais le space et les rooms ont l’air d’etre version 9)
• the join_rules look the same on tchap-web + tchap-backend as on element-web+matrix.org .

Custom Tchap event "im.vector.room.access_rules" is present only on tchap. Is it involved ?

• "rule": "restricted"

M.room.power_levels is a bit different, is that related ? Below the listed values on tchap-web + tchap-backend vs. element-web+matrix.org .

• Users_default : 0 - 0
• "events_default": 0 - 0
• "state_default": 100 - 50
• "invite": 50 - 0
• "historical": 100 - 100
• Events
  • "m.space.child": 100 - none (“has no effect in rooms which are not spaces” according to spec)
  • "org.matrix.msc3401.call": 100 - none
  • "org.matrix.msc3401.call.member": 100 - none

"M.room.encryption" : present sur tchap-backend, pas sur matrix.org

Code for showing the list of rooms in a space. Anything there ? List of rooms is fetched in useRoomHierarchy https://github.com/matrix-org/matrix-react-sdk/blob/f96606acebaeea99e98c3a827575c76a68f37a5c/src/components/structures/SpaceHierarchy.tsx

[MarcWadai]

The first tests confirm that on element it is working, so the analysis below will show the differences between the two client. Below is a summary of the http call from the web to the backend comparaison between element and tchap :

1. Creating the room: On element

2. POST _matrix/client/v3/createRoom -> request body {"name":"create log","preset":"private_chat","visibility":"private","initial_state":[{"type":"m.room.guest_access","state_key":"","content":{"guest_access":"can_join"}},{"type":"m.room.encryption","state_key":"","content":{"algorithm":"m.megolm.v1.aes-sha2"}},{"type":"m.space.parent","content":{"via":["matrix.org"],"canonical":true},"state_key":"!SPACE_ID:matrix.org"},{"type":"m.room.join_rules","content":{"join_rule":"restricted","allow":[{"type":"m.room_membership","room_id":"!SPACE_ID:matrix.org"}]}},{"type":"m.room.history_visibility","content":{"history_visibility":"invited"}}],"room_version":"9"} -> response room_id

   On Tchap

   POST _matrix/client/v3/createRoom

-> request body {"name":"marc cake","creation_content":{"m.federate":true},"initial_state":[{"content":{"rule":"restricted"},"type":"im.vector.room.access_rules","state_key":""},{"type":"m.room.encryption","state_key":"","content":{"algorithm":"m.megolm.v1.aes-sha2"}},{"type":"m.space.parent","content":{"via":["agent.dinum.tchap.gouv.fr"],"canonical":true},"state_key":"SPACE_ID:agent.dinum.tchap.gouv.fr"},{"type":"m.room.join_rules","content":{"join_rule":"restricted","allow":[{"type":"m.room_membership","room_id":"!SPACE_ID:agent.dinum.tchap.gouv.fr"}]}},{"type":"m.room.history_visibility","content":{"history_visibility":"invited"}}],"visibility":"private","preset":"private_chat","room_version":"9"}

-> response room_id

2. Updating the space child value, same on element and tchap:

PUT /_matrix/client/v3/rooms/SPACE_ID%3Aagent.dinum.tchap.gouv.fr/state/m.space.child/!ROOM_ID%3Aagent.dinum.tchap.gouv.fr

-> request body {"via":["agent.dinum.tchap.gouv.fr"],"suggested":false}

-> respose {"event_id":"$EVENT_ID"}

3. Getting the list of rooms available in the space from the user invited. Same on element and Tchap. The difference is that on Tchap we don't get the new room just created. But in the room list received, in the first room which is the space, there is an attribute called children_state in which we can indeed see the new room that was created by the owner of the space, but it is not included in the final list 

GET _matrix/client/v1/rooms/SPACE_ID@matrix.org/hierarchy?suggested_only=false&limit=20 -> response roomList

[MarcWadai]

-> Then I also made the experiment to see if the issue is resolved the next day twice, and in both of the situation it indeed works. We can see the next day the new room that was created in the list.

Like Estelle noticed, the only differences on the room states event are on the power_levels and the custom access_rules on Tchap. Concerning the power level on Tchap the previous day the values that are different from element become the same as element the next days, so it goes from :

content.state_default 50 -> content.state_default 100 content.invite 0 -> content.invite 50

Which are the same values as element. For now, this is the only differences that we can notice between the seing the room and not seeing it in the list. Is there a process worker behind that changes those values, and are those power_levels really have an impact on what room is displayed for the user ? @mcalinghee @MatMaul

On our module synapse-room-access-rule, i can see that we use the same default value as Element (state_default 100 and invite 50), so i cannot see a place where those values are changed.

EDIT: My bad the power levels didn't change (i compared with the wrong values). Then, there were no changes on the event state between the previous and next day. so it is still a mystery why it worked a few hours later

[MarcWadai]

• Changing the rank (moderator and admin) of the invited user doesnt change the room list visibility

• After inviting the user to a new room, he can then see the room in the list before accepting the invitation, whilst it wasn't visible before the invite

• Note that during all those tests the space visibility is well set to all member of the space

[MarcWadai]

1. Testing on the DEV environment couldn't reproduce the same error : Below were the different set up :

   • From a user on dev01 to de another user on dev01
   • From a user on dev01 to de another user on dev02 It is working fine DEV, we can see the list of rooms directly :astonished:

2. Testing on preprod and it is also working on this environment

[odelcroi]

Taking the issue

TLTR;

• when a admin create a room in a space, it is available in the space welcome page the day after

Is the issue still present? Yes

Version de Tchap : 4.6.1 Version crypto : Rust SDK 0.7.0 (068a0af), Vodozemac 0.6.0 Backend : PROD 21 aout 2024

Steps to reproduce:

• avec un compte agent A1
• créer un espace E1
• créer un salon S1 dans l'espace E1 à travers les boutons de création de salons
• inviter un user agent B à l'espace E1
• se connecter avec le user Agent B
• accepter l'invit pour l'espace E1
• 👎 KO BUG : le agent B ne voit pas le salon S1
• avec l'admin A créer un salon privé S2
• 👎 KO BUG : le agent B ne voit pas le salon S2

What we learnt

The bug is in PROD : Agent B can NOT see the room in the space welcome page The bug is NOT in DEV : Agent B can see the room in the space welcome page The bug is NOT in PREPROD : Agent B can see the room in the space welcome page

• The bug disappears after few hours or the day after : The user "Agent B" see then the room in the welcome list (confirmed)

• If we invite the user in the room S1, without accepting the invite, he can see the room S1 the welcome page

• Reproduced with "Element App + Tchap PROD Backend", @MarcWadai you said the bug is not present with Element app, did you mean with element app + matrix backend ?