J’ai récemment créé une intégration incroyable pour ma communauté, mais il manque une fonctionnalité essentielle : je souhaite notifier les utilisateurs abonnés à un sujet lorsque la publication d’origine est mise à jour. Voici mon scénario :
Nous avons une plateforme SaaS et, comme beaucoup, nous avons une page de statut : status.sailpoint.com où nos utilisateurs peuvent surveiller et s’abonner aux incidents lorsqu’ils surviennent sur notre plateforme. Le problème avec ces incidents est qu’ils sont très unidirectionnels, de sorte que nos clients ne peuvent pas communiquer avec nous ou entre eux sur la façon dont cet incident les affecte. Ce qui se passe, c’est qu’ils finissent par submerger leurs CSM et nos lignes de support pour savoir ce qui se passe (ce qui est compréhensible).
Pour remédier à cela, j’ai eu l’idée d’intégrer Discourse dans l’expérience. Lorsqu’un nouvel incident survient, la page d’incident sur status.sailpoint.com aura un joli lien/message comme « Cliquez ici pour discuter de cet incident ». En backend, nous effectuons des appels API pour créer et mettre à jour un sujet dans Discourse au fur et à mesure que l’incident progresse, comme ceci :
C’est formidable car nos clients ont maintenant un exutoire pour converser en un seul endroit, et les CSM/le support ont un point de convergence unique et public pour répondre et apaiser les préoccupations.
Le Problème
Chaque fois que nous ajoutons un nouvel incident à cette publication d’origine, je veux notifier ceux qui sont abonnés au sujet. Je ne veux pas créer de nouvelles publications dans le sujet pour ce faire, je veux que tout soit soigneusement logé dans le sujet d’origine. Je ne veux pas non plus de nouvelles publications dans le sujet qui sont ensuite liées avec un onebox dans la publication d’origine.
Ce serait bien de pouvoir « remonter » le notificateur.
Je reçois une notification lorsque l’équipe ici modifie des sujets de documentation que je surveille. C’est peut-être parce que les messages originaux sont des messages wiki. Si c’est le cas, c’est peut-être votre solution. Vous devrez définir le niveau de confiance autorisé à modifier les messages wiki (min trust to edit wiki post) à ce dont vous avez besoin.
Ce serait très proche ! Mais je ne peux pas laisser des personnes n’appartenant pas à l’entreprise modifier ces publications en raison de leur sensibilité, mais je voudrais toujours que le groupe de niveau de confiance de votre choix puisse modifier les wikis sur d’autres publications.
Je ne connais pas la réponse à cette question, mais qu’en est-il de la modification des paramètres de catégorie pour que les utilisateurs normaux puissent répondre mais pas créer - cela a-t-il pour effet d’empêcher les utilisateurs normaux de modifier le message wiki d’origine ?
Sauf si vous avez des clients qui modifient des articles de wiki ailleurs sur votre installation Discourse, vous pouvez simplement augmenter min trust to edit wiki post à TL3 (si vous l’avez rendu inaccessible) ou TL4 et vous assurer que votre personnel est au même niveau ou à un niveau supérieur.
Le TL4 n’est pas automatiquement accessible, le distribuez-vous ?
Pour être clair cependant, le TL4 peut modifier tous les messages, plutôt que juste les articles wiki. Si vous donnez le TL4 à vos clients, ils peuvent déjà modifier ces sujets.
Oh non, je n’étais pas au courant que le niveau 4 (TL4) pouvait modifier tous les messages. C’est une correction simple cependant, nous donnons simplement le niveau 4 à nos Ambassadeurs dans notre programme d’ambassadeurs, un programme que nous avons pour nos meilleurs contributeurs. Cela est géré par le niveau de confiance dans le groupe d’utilisateurs, donc je vais simplement le réduire au niveau 3 (TL3).
Cette conversation m’incite à revoir les niveaux de confiance
Je dois encore trouver une solution pour cela cependant ! Je devrai peut-être faire appel à l’équipe des services pour cela.
Cela semble toujours réalisable grâce aux notifications wiki, vous pourriez :
Rétrograder les ambassadeurs au niveau TL3
Les désigner comme modérateurs de catégorie pour vos catégories wiki
Définir la permission par défaut d’éditer le wiki au niveau TL4
Désigner votre personnel au niveau TL4
Ensuite, le personnel pourra modifier les publications wiki dans les sujets d’incident, mais pas les ambassadeurs car leurs droits d’édition de sujets ne s’appliquent qu’aux catégories wiki.
Je vois que les sujets dans Plugin sont des wikis, c’est donc ainsi qu’ils procèdent ici chez Discourse. D’accord, je vais mieux m’informer sur les niveaux de confiance d’abord pour m’assurer que je comprends bien cela.
Je dirai cependant que je n’aime pas l’idée de les désigner comme modérateurs de catégorie. Cela ne signifie-t-il pas qu’ils apparaîtront comme modérateurs de la communauté sur /about ?
Ils apparaîtraient dans une section sous les administrateurs et les modérateurs, le nom de la catégorie les désignant comme modérateurs pour cette catégorie.
Vous pourriez utiliser CSS pour masquer cela.
Peut-être attendez de voir si quelqu’un d’autre propose une solution plus acceptable si cela semble être trop de changement.
Apprendre les niveaux de confiance est toujours une bonne chose, je commencerais ici et ensuite jetterais un œil au tableau des permissions.
Je vais faire exactement cela. Je pense que, dans notre cas d’utilisation en entreprise, nous ne voudrions pas que notre communauté liste des utilisateurs réguliers (clients/partenaires) comme modérateurs, car cela pourrait donner l’impression qu’ils sont plus formellement associés aux opérations de notre entreprise dans une certaine capacité.
Merci beaucoup pour toutes vos réponses détaillées !
