Chatd - des trous dans l'API

Hello,

Je ne vois rien qui en parle sur Jira,
mais il y a quelques manques pour optimiser le chatd.

1/ retrouver les informations utilisateurs d’une conversation

L’information d’une room ne renvoi que le user.uuid et il n’est pas possible d’avoir les informations de base d’un utilisateur avec son uuid, à part si l’utilisateur a des acls d’administrateur pour utiliser

confd API:
GET users/{user_id}  //nécessite acl admin

Mais cela n’est pas souhaitable

Chatd api :
GET users/me/rooms                                 // ne renvoi que user.uuid
GET users/me/rooms/{room_uuid}/messages)           // ne renvoi que user.uuid

il faudrait pouvoir retrouver facilement les informations de l’user, a minima :

  • firstName
  • lastName
  • number (exten)
  • state
  • status
  • dnd

2/ Ajouter / Supprimer un utilisateur

Dans Chatd, il existe aucune requête pour ajouter ou supprimer un utilisateur de la room.
Il faudrait à minima un nouvel endpoint pour mettre à jour la liste des utilisateurs, ex :

Chatd API:
PUT users/me/rooms/{room_uuid}/participants    // array de lensemble des utilisateurs

La requête devra émettre un Event afin que l’utilisateur supprimé/ajouté à une discussion puisse en être informé.

3/ supprimer une discussion

Il manque un endpoint pour supprimer une discussion

chadt API:
DEL users/me/rooms/{room_uuid}

Là aussi, un Event doit être émit.

Sans ces 3 points, le chatd est trop peu maléable.

En attendant que quelque chose soit fait sur les endpoints, est-il possible de contourner le premier point,
retrouver les infos d’un user depuis son uuid sans passer par confd.getUser(uuid) qui demande des droits spécifiques ?

merci

Salut,

Le plus simple est de créer un module dans la stack pour ajouter les API qu’il te manque et faire ton use case comme tu veux. Tu peux trouver du code qu’on a fait dans notre hackathon de l’année dernière ici sur un sujet du style.

Je suis d’accord l’API de chatd est encore trop light pour le moment pour faire tout ce qu’on veut avec.

Sylvain

Le code du hackathlon m’a permis d’avoir une meilleure logique pour retrouver les informations des users des conversations. ça répond à une question importante pour moi !
COOL !!
J’en ai profité pour optimiser mon badge de présence/status.

Pour le chat, je ne mets que le support des émoticons, ce qui est assez simple avec le package.
emoji-picker-react

Je cherche a avoir des badges de notifications pour les messages non lus.
Je me dis qu’il doit avoir quelque chose à faire avec les dates des messages.

Mais je ne vois rien d’utilisable dans mon user connecté.
Avec une valeur “last_connection”: timestamp, j’aurai pu faire une requête sur l’api de tous les messages après cette date et donc mettre les messages non lus sur mes conversations …

et quand je passe par le sdk et demande Wazo.chatd.getRoomMessages(uuid), j’ai bien une valeur
read: true
mais impossible de me baser là dessus, car je ne sais pas comment récupérer cette information quand read : false

là, je peux éventuellement faire une notification de message reçu si l’utilisateur qui reçoit le message est connecté.
Mais si il n’est pas connecté, je ne vois pas comment connaitre les messages non lus.

La question se pose aussi lorsqu’une nouvelle discussion est créée, mais vu qu’elle apparait dans la liste au chargement, je me dis que c’est plus visuel, bien qu’un badge attirerait l’œil également !

une idée ?
merci !

de plus, je me rends compte d’un fonctionnement anormal.
j’utilise wazo.chatd.createRoom(name, users)
je fais donc un:
post https://10.94.101.195/api/chatd/1.0/users/me/rooms
avec dans ma requête:
{"name":"","users":[{"uuid":"3bd112ad-a8a7-4056-97dc-c1547ae2e535"}]}

Mais dans mon cas, j’ai cette réponse:
{“uuid”: “4b61796e-2ce8-4cf8-a8c7-389f1a3a41a8”,
“tenant_uuid”: “958ac4de-d279-4f63-882a-b0e4f8347e56”,
“name”: “les techos”,
“users”: [
{“uuid”: “7d0eaa63-f63e-4e75-b8c9-b89f2c3c52cb”,
“tenant_uuid”: “958ac4de-d279-4f63-882a-b0e4f8347e56”,
“wazo_uuid”: “1cc60e03-8a2c-4f53-9ecc-193c0ce4b7ea”},
{“uuid”: “3bd112ad-a8a7-4056-97dc-c1547ae2e535”,
“tenant_uuid”: “958ac4de-d279-4f63-882a-b0e4f8347e56”,
“wazo_uuid”: “1cc60e03-8a2c-4f53-9ecc-193c0ce4b7ea”},
{“uuid”: “3b4711bf-1227-4222-86ef-68d15b102f99”,
“tenant_uuid”: “958ac4de-d279-4f63-882a-b0e4f8347e56”,
“wazo_uuid”: “1cc60e03-8a2c-4f53-9ecc-193c0ce4b7ea”}]}

Je pense que j’ai cette réponse car l’utilisateur demandeur et destinataire sont déjà dans la room existante et voit cela comme un doublon.

cette réponse me semble normal si le array d’users est strictement identique, mais ici ce n’est pas le cas, seul 2 users sur les 3 sont identiques.

J’ai vu cela, car également, si je veux créer une nouvelle discussion à 3 et qu’une autre discussion avec ces 3 mêmes users existe déjà, alors l’api me retourne la room déjà existante même si le name est différent.

j’espère avoir été clair.
merci !

Oui bien vue, en regardant rapidement le code, ca semble très très plausible
Car en effet il y a une mécanique pour retourner la même discussion lorsque les membres sont pareils

Selon la documentation de l’API:

Warning: >=22.16: If a room with the same participants exists,
it will be returned instead of creating new one. In this case, no other
parameter will be taken into account and the return code will be 201.
This behaviour will disappear in the future and a 409 error will be
raised.

Mais on semble prendre le plus petit subset (ce qui est une erreur)
Je viens de creer un ticket [WAZO-3418] - Wazo

2 Likes

Pour information, le fix pour [WAZO-3418] - Wazo devrait être dans la prochaine version (24.05) :slight_smile:

2 Likes