Les messages “whisper” pourraient être utiles pour être étendus, de manière similaire à la fonctionnalité en cours de développement pour les réponses pré-enregistrées spécifiques aux groupes, afin de permettre également plusieurs messages “whisper” (spécifiques à certains groupes).
Exemple :
Nous avons un @documentation-group qui pourrait utiliser des messages “whisper” sans avoir besoin d’accéder aux messages “whisper” du personnel.
Il serait utile d’autoriser éventuellement plus d’une section de messages “whisper”. Merci dans tous les cas de votre considération.
Mais tous les groupes pourraient voir tous les chuchotements. Je pense que des chuchotements cloisonnés seraient un bon ajout, bien que je ne sache pas à quel point il serait difficile d’y parvenir.
Je ne suppose pas que cela ait été abordé au sein de votre équipe au cours des deux années écoulées ?
Nous commençons à intégrer d’autres équipes à la plateforme qui aimeraient utiliser la fonction de chuchotement, mais nous ne voulons pas qu’elles voient nos chuchotements d’administration.
C’est similaire mais différent. Je ne pense pas que nous voudrions que l’autre groupe puisse voir nos chuchotements d’administrateur dans toutes les conditions. Voici une petite visualisation, j’espère que cela vous aidera — pensez-y comme à des couches de chuchotements :
Chuchotements d’administrateur, seul l’administrateur peut voir
Chuchotements de l’équipe interne ; l’administrateur peut également voir
Utilisateur externe qui ne peut voir aucun chuchotement
Si un plugin ou un composant de thème bbcode n’affecterait pas les chuchotements.
Dans le lien que j’ai fourni, vous auriez du code supplémentaire disponible dans un message pour n’afficher qu’une partie du message à tout le monde, le contenu caché n’étant affiché qu’à l’OP et au groupe cible.
Maintenant, pour que les gens ne puissent pas voir les révisions de messages, sauf le personnel.
L’idée d’une solution de type bbcode vous permettrait de masquer le contenu d’un message à un autre groupe. L’un des exemples est les jeux de rôle sur table. Cependant, les utilisateurs astucieux pourraient le voir en utilisant l’inspecteur d’éléments et en modifiant le CSS.
Je pense que la #demande de fonctionnalité est assez claire et nous devons faire attention à ne pas traiter tout comme un sujet de Support et à ne pas aller trop loin dans les solutions de contournement. Essayons de rester concentrés.
Idéalement le second, mais je réalise que le regroupement de différents utilisateurs dans différents groupes pourrait être assez complexe. L’idée est que nous avons de nombreuses équipes internes dans notre entreprise qui cherchent maintenant à créer des expériences pour leurs utilisateurs sur notre Discourse, également. On a l’impression d’avoir construit une communauté parente, mais ils construisent aussi des mini-communautés à l’intérieur.
Avec cela, beaucoup d’entre eux s’intéressent à la possibilité d’utiliser la fonction de murmure dans leurs boîtes de réception et catégories de groupe. Le problème, bien sûr, est que nous ne voulons pas qu’ils voient les murmures administratifs.
C’est délicat. Les murmures sont déjà un outil un peu dangereux dans le sens où les personnes qui peuvent les voir doivent donner un sens à un sujet sur deux niveaux, plisser les yeux pour le voir du point de vue du public tout en ayant la vue privilégiée qui inclut les murmures.
Je pense qu’ajouter une couche supplémentaire pourrait rendre cela trop confus pour la plupart des gens. Je reconnais que l’e-mail vous donne déjà cette liberté car de nombreux clients afficheront un seul fil de discussion, quelle que soit la personne ajoutée ou retirée de la liste CC en cours de route. Mais j’ai aussi vu que cela entraînait le même type de confusion que je voudrais éviter ici.
Une idée qui, je pense, pourrait trouver le bon équilibre est de faire de la visibilité des murmures une configuration au niveau de la catégorie. Par exemple :
Dans la catégorie A, les groupes X et Y peuvent voir les murmures.
Dans la catégorie B, le groupe Z peut voir les murmures.
Dans ce modèle, X et Y pourraient toujours voir les murmures des administrateurs dans A. Mais je pense que vous pourriez définir des catégories et des normes d’une manière qui fonctionnerait, sans avoir à ajouter une troisième couche de murmures au sein d’un même sujet.
comme décrit par @putty. Ce serait un excellent compromis car, au moins dans notre instance, au moins tout le monde dans « tous les autres chuchotements » serait un employé de la même entreprise. Je me lance ici, mais j’ai l’impression d’apprendre chaque jour davantage les complexités de la plateforme : je suppose que si telle était la configuration, ce serait (au moins en partie) moins complexe que de donner aux groupes individuels la possibilité de contrôler qui peut voir leurs chuchotements ?
Cela donnerait aux employés de toute l’entreprise la possibilité de chuchoter au sein de la communauté entre eux, quelle que soit la catégorie, le sujet ou le message privé. Cela me semble en fait incroyable maintenant que j’y pense. Ce serait incroyable !
Oui, je ne suis pas sûr de ce qui serait le plus complexe à implémenter et à configurer au final. Je suis toujours préoccupé par l’idée d’avoir un troisième niveau de discussion au sein du même sujet, cependant.
Vous pourriez faire cela aujourd’hui, n’est-ce pas ? Tant que vous accepteriez aussi de laisser tous les employés voir les chuchotements des administrateurs.
Cela vaut-il la peine d’envisager d’accepter cette contrainte ?
Quels sont les scénarios où vous auriez besoin qu’un administrateur puisse chuchoter sans que cela soit visible par tous les employés ? Et ne voudriez-vous pas au moins parfois que les administrateurs puissent chuchoter à d’autres employés si vous laissez d’autres employés chuchoter entre eux ? Comment cela fonctionnerait-il ?
Peut-être que dans le modèle “tous les employés peuvent chuchoter entre eux”, les administrateurs devraient utiliser un outil différent pour communiquer entre eux lorsqu’ils en ont besoin (comme les messages privés ou une catégorie ou un canal de discussion réservé au personnel). Si cela était acceptable, vous pourriez le faire aujourd’hui.
Malheureusement, nous devons aussi administrer nos utilisateurs internes, parfois ! Quand on commence à être si nombreux, il y a des scénarios qui se prêtent tout aussi bien à une discussion réservée aux administrateurs. Je pourrais vous en dire plus sur ce cas d’utilisation dans un message privé, si vous êtes intéressé.
Oui !
Le personnel peut voir/répondre/créer des chuchotements du personnel
Le personnel peut voir/répondre/créer des chuchotements réguliers
Les employés peuvent voir/répondre/créer des chuchotements réguliers
Les employés ne peuvent pas voir/répondre/créer des chuchotements du personnel
Je suis toujours sceptique quant au compromis valeur/complexité ici, mais je comprends maintenant comment avoir un type supplémentaire de murmure permettrait de répondre à votre demande actuelle.
Compte tenu des contraintes existantes du système, choisiriez-vous d’autoriser tout le monde à murmurer et d’utiliser une autre solution pour les conversations réservées aux administrateurs ? Ou choisiriez-vous de limiter les murmures aux administrateurs uniquement ?
C’est difficile à décider pour le moment. La philosophie que j’ai toujours fait suivre à mon équipe est de faire ce qui est le mieux pour nos utilisateurs, pas ce qui est le plus facile pour nous, car ce sera finalement ce qui est le mieux pour nous aussi.
Dans ce sens, je pense que je laisserais probablement les chuchotements ouverts à tout le monde, et que mon équipe déplacerait les conversations de modération vers Slack ou peut-être le chat lorsque les problèmes de notification seront résolus. Ce n’est pas idéal et cela retire le chuchotement aux modérateurs/administrateurs, mais cela nous permettrait de continuer à développer notre communauté.
Dans notre cas, nous avons une équipe d’auteurs et d’autres contributeurs qui ne sont pas modérateurs, et j’aimerais leur donner la possibilité de chuchoter dans certaines catégories sans leur rendre visibles les chuchotements du personnel/des modérateurs.
Ce ne serait pas sécurisé. Et les utilisateurs astucieux pourraient le contourner.
Mais qu’en est-il d’un composant de thème qui utilise CSS pour afficher « none » sur un murmure créé par le personnel si l’utilisateur actuel n’est pas du personnel ? En ce qui concerne certaines catégories.
Une logique similaire pourrait être utilisée pour le commutateur de murmure dans le menu d’engrenage afin de ne pas afficher le bouton de murmure pour ledit groupe s’il n’y a pas de catégories que vous souhaitez qu’ils soient autorisés à utiliser les murmures.
Le groupe du personnel devrait savoir ne pas partager des choses d’un réel besoin sensible/de sécurité.
Quelque chose comme cela pourrait être utilisé comme solution de contournement temporaire avec des mises en garde.
Je me basais simplement sur du CSS dans un composant de thème.
Cela ne devrait-il pas être un plugin ? Je m’excuse si ma logique floue est erronée.
Cependant, vous avez une bien meilleure compréhension de ces choses que moi. Mais cela semble intéressant si c’est réalisable, car plus tôt dans ce sujet, il a été dit qu’il ne serait pas possible de créer des murmures séparés à l’heure actuelle en raison de la complexité.
Je basais ma conclusion sur l’idée d’un autre sujet d’utiliser un bbcode CSS générique pour n’afficher le contenu caché dans un message qu’à un certain utilisateur ou groupe.
