Pour information

Le ou les groupes d'utilisateurs qui peuvent accéder au service de chat est donné par la propriété

chat.xmpp.domain.groups

Si un groupe d'utilisateurs, référencé par cette propriété, venait à être supprimé, rien n'est fait : les comptes des utilisateurs présents sur le serveur ne sont pas supprimés. De même si un utilisateur venait à être retiré d'un groupe référencé par la propriété. En effet, un utilisateur retiré (pour cause de suppression de groupe ou pour cause de retrait explicite) à un moment peut se retrouver à nouveau dans un groupe éligible et il serait mal venue qu'il perde son historique, son roster, et autres informations liées à son compte XMPP.

Toutefois, le mécanisme de création des comptes utilisateurs auprès du service XMPP a été revue. Désormais, le compte XMPP d'un utilisateur est créé que si et seulement si il fait partie d'un des groupes pour lequel le chat a été activé et qu'il fait partie d'un domaine d'utilisateurs pour lequel une association avec un domaine XMPP existe. Ceci a pour conséquence que si un utilisateur est ajouté dans un des groupes référencés par la propriété (soit directement, soit par le biais d'un groupe parent) alors automatiquement son compte XMPP est crée auprès du serveur (s'il ne l'est déjà et si son domaine est associé avec un domaine XMPP).

Pour information¶

Dans SilverChat¶

Avec la version 1.5.0, SilverChat supporte l'ACL qui permet d'indiquer ce que l'utilisateur courant a droit ou non. Pour l'instant, une seule ACE est supportée et ceci dans le cadre de cette feature : la possibilité de créer un groupe de discussion et par conséquent d'inviter des contacts à ce groupe. L'ACL est spécifiée lors de l'initialisation de SilverChat par le biais des options d'initialisation. L'ACL est un objet qui comprend, pour chaque attribut, un contexte qui regroupe les ACE vis à vis de ce contexte. Chaque ACE accepte un booléen comme valeur. Ainsi, dans notre cas, l'autorisation ou non de pouvoir créer un groupe de discussion se fait avec l'ACE acl.groupchat.creation. Par défaut, les ACE sont toutes vraies et donc toutes les fonctionnalités sont accessibles à l'utilisateur courant. Voici un exemple donné ci-dessous d'initialisation avec une restriction sur la création de groupes de discussion :

SilverChat.init({
        ...
        // l'ACL
        acl : {
          // le contexte : ici les groupes de discussion
          groupchat : {
             // l'ACE pour la création
             creation: false
          }
        },
        ...
}).start();

Dans Silverpeas¶

Cette nouvelle fonctionnalité de SilverChat est utilisée ici pour restreindre la possibilité de créer des groupes de discussions à un ou plusieurs groupes d'utilisateurs dans Silverpeas. Pour ce faire, une nouvelle propriété a été introduite dans le fichier de propriétés org/silverpeas/chat/settings/chat.properties :

chat.acl.groupchat.creation

Cette propriété accepte comme valeur une liste, séparée par des virgules, d'identifiants uniques de groupes d'utilisateurs dans Silverpeas. Seuls les groupes spécifiés avec cette propriété sont à même de pouvoir créer des groupes de discussion et d'inviter des utilisateurs à ces groupes. Si la propriété n'est pas valorisée, alors c'est le comportement par défaut qui est adopté : tout le monde peut créer des groupes de discussion.

Attention, il n'y a pas de vérification de l’existence ou non du ou des groupes d'utilisateurs indiqués. Ainsi, il est possible de désactiver la fonctionnalité de créer des groupes de discussion pour l'ensemble des utilisateurs de Silverpeas en spécifiant un identifiant de groupe inexistant comme unique valeur à cette propriété. Aussi, au regard de ceci, si un groupe d'utilisateurs, référencé par cette propriété, venait à être supprimé, il peut arriver que plus aucun utilisateur ait la capacité de pouvoir créer des groupes de discussions. Il faudra donc à l'administrateur ou au gestionnaire de porter une attention particulière sur ce point.

Rappel : seul le créateur d'un groupe de discussion peut inviter un contact.

Quelques points ont été relevés lors d'une première intégration.

Au niveau de la gestion du paramètre chat.xmpp.domain.groups, un problème de performance et de surcharge d'écriture dans le fichier de logs ont été détectés.
En imaginant que ce paramètre est renseigné (ou que celui permettant de restreindre à un ou plusieurs domaines l'est) le serveur Silverpeas va vérifier l'existence de l'utilisateur dans le serveur XMPP, lors de l'ajout d'un utilisateur dans un groupe (ou même à la création d'un utilisateur dans Silverpeas), avant de vérifier si le chat est activé pour l'utilisateur ajouté. De ce fait, selon le paramétrage, beaucoup de communication entre le serveur Silverpeas et celui XMPP peuvent survenir lors de l'ajout d'un nombre important d'utilisateur dans un groupe (peu importe le groupe dans lequel les utilisateurs sont ajoutés) ou lors de la création d'utilisateurs suite à une synchronisation avec un gestionnaire d'identités externes (LDAP par exemple).
De plus si les utilisateurs ajoutés ne sont pas dans les domaines cibles ou les groupes cibles, alors des informations sont manquantes dans les communications HTTP entre le serveur Silverpeas et celui XMPP ce qui entraîne la génération d'erreurs et une forte augmentation du nombre de lignes écrites dans les fichiers de logs.

Lors de la création d'un groupe avec une règle de synchronisation, DS_AccessLevel = U par exemple, seul le premier utilisateur de tous ceux synchronisés dans le groupe est traité dans le serveur XMPP.

Au niveau de la gestion du paramètre chat.acl.groupchat.creation, aucune différence de comportement n'a pu être remarquée qu'il soit renseigné ou non. Aussi, dans le cas où le paramètre n'est pas renseigné, la valeur false est indiquée pour l'ACE acl.groupchat.creation lors de l'initialisation du client XMPP, alors qu'il semble que ce soit plutôt true qui soit attendue.

Lorsque le chat est paramétré sur la plate-forme, une latence se fait ressentir lors de la déconnexion d'un utilisateur qui pourrait accéder au chat mais qui n'est pas encore enregistré au niveau du serveur XMPP.

Un autre problème a été remarqué au niveau de la destruction d'un groupe par son créateur. Lors d'une telle action, des erreurs javascripts surviennent et le client XMPP est alors dans un état de fonctionnement instable. Il est par exemple difficile de recréer un nouveau groupe.

Les points précédents ont été résolus, excepté celui concernant les erreurs JavaScript qui entraînent un comportement instable.
Maintenant, il n'y a plus d'erreur lorsque le créateur d'un groupe supprime le groupe. Cependant, s'il décide de créer de nouveau un groupe, avec un participant (connecté à Silverpeas) qui était dans le groupe précédemment supprimé, alors des erreurs JavaScript surviennent chez ce participant. Son client XMPP est du coup dans un état de fonctionnement instable et les communications entre les différents clients XMPP via le serveur XMPP sont incertaines, notamment dans la gestion du cycle de vie du nouveau groupe.

Je suis étonné par cette erreur parce que j'ai pas mal testé la suppression de groupe et dans mes tests à chaque fois je récréais un groupe (de même nom ou pas) avec le même participant.
Aussi, pour vérifier ce point, j'ai à l'instant réitéré les tests en créant et supprimant plusieurs fois de suite une discussion de groupe de même nom ou de nom différent et avec le même invité et effectivement je ne reproduis pas du tout le problème.