Alias du personnel Discourse

[Discourse]

	Résumé	Le plugin Discourse Staff Alias permet à des groupes définis de créer des sujets et des publications, ainsi que d’effectuer des modifications, en tant qu’utilisateur alias.
	Lien vers le dépôt	https://github.com/discourse/discourse-staff-alias
	Guide d’installation	Comment installer des plugins dans Discourse

Comme il s’agit d’un plugin official maintenu par l’équipe Discourse, les demandes de Support, de rapports de bug, d’améliorations ux et de nouvelles #fonctionnalités peuvent être soumises dans les catégories respectives sur Meta, en les étiquetant avec le tag approprié du plugin. Cliquez sur un lien ci-dessous pour en démarrer un.

 Support  Bug  UX  Fonctionnalité

Le plugin Discourse Staff Alias permet à certains groupes de créer des sujets et des publications, ainsi que d’effectuer des modifications, en tant qu’utilisateur alias. Cela peut être utile dans des situations où les membres du personnel doivent répondre à des requêtes ou faire des annonces sans révéler leurs noms d’utilisateurs personnels.

Activer Staff Alias

Une fois installé, le plugin Staff Alias peut être activé depuis ses paramètres, accessibles depuis votre page admin/plugins :

Ce plugin est désactivé par défaut. Avant de l’activer, un nouveau nom d’utilisateur pour l’alias doit être ajouté au paramètre d’administration staff alias username :

Une fois le plugin activé, un utilisateur portant ce nom d’utilisateur sera créé.

---

Utilisation de l’alias

Une fois activé, l’alias du personnel peut être basculé via le menu déroulant des actions du compositeur. Les utilisateurs appartenant aux groupes autorisés peuvent alors choisir de créer des sujets et des publications, ainsi que d’effectuer des modifications, en utilisant l’alias du personnel :

Le sujet, la publication ou la modification apparaîtra alors comme ayant été créé par l’alias du personnel :

---

Suivi de l’utilisation de l’alias

Si vous faites partie des groupes autorisés, vous verrez également une mention indiquant qui a créé le sujet ou la publication, ou qui a effectué la modification :

---

Paramètres

Nom	Description
staff alias enabled	Activer le plugin discourse-staff-alias
staff alias username	Nom d’utilisateur de l’utilisateur alias
staff alias allowed groups	Groupes autorisés à publier en tant qu’utilisateur alias du personnel

Hébergé par nous ? Ce plugin est disponible dans notre offre Entreprise.

[sok777 (sok)]

@Discourse

Vous pouvez utiliser un compte utilisateur existant ou saisir un nouveau nom pour en créer un :

Il semble que nous ne puissions pas ajouter un compte utilisateur existant. Pourquoi ?

[JammyDodger]

Il y a une chance que j’aie fait une erreur en rédigeant les instructions.

Je ne parviens pas non plus à faire en sorte qu’un utilisateur existant soit un alias du personnel en testant à nouveau, ce qui est logique quand j’y pense. Je ne suis pas sûr de ce qui m’a amené à croire que c’était possible. Je vais mettre à jour les instructions.

[sok777 (sok)]

Merci ! C’est dommage car je pense que cela unifie lorsque tous les membres du personnel peuvent utiliser le nom du site ou un compte ‘maître’ qui existe déjà. Par exemple @Discourse

[barto_95]

lorsque je teste la création d’un sujet, j’ai reçu le message d’erreur

[JammyDodger]

Votre alias de personnel, l’utilisateur, a-t-il les bonnes autorisations pour créer un sujet dans cette catégorie ? (a-t-il les autorisations de personnel)

[barto_95]

Oui c’est ça le problème…

Merci

[barto_95]

Il n’est pas possible de répondre à un message en réponse à un utilisateur avec un alias de personnel, je reçois l’erreur ci-dessus, mais si j’utilise un alias de personnel pour répondre à un message, le sujet est correct.

[jordan-violet]

Quelles sont les chances que cela puisse être étendu pour devenir un outil dynamique de « publication en tant qu’autre utilisateur » ?

Nous avons un cas d’utilisation où un responsable des communications produit doit créer de nouveaux sujets en tant qu’autres responsables produit de notre organisation. Cet outil semble avoir la plupart des fonctionnalités, mais nécessiterait la possibilité de définir dynamiquement l’utilisateur sous lequel publier.

[fokx]

Je rencontre la même erreur chaque fois que je réponds à un message qui n’est pas l’OP :

Une erreur s’est produite : Vous n’êtes pas autorisé à consulter la ressource demandée.

Après avoir un peu creusé, j’ai trouvé le coupable à l’adresse :

lib/discourse_staff_alias/posts_controller_extension.rb

Le problème est :

params[:whisper] est \"false\", ce qui est une chaîne de caractères. Il suffit donc de changer cette ligne en :

if !DiscourseStaffAlias.user_allowed?(existing_user) || params[:whisper] == \"true\"

…pour résoudre le problème.

J’ai créé une simple PR : FIX: InvalidAccess when replying to non-original post by fokx · Pull Request #67 · discourse/discourse-staff-alias · GitHub

[Heliosurge (Dan DeMontmorency)]

Salut Jordan,

Je peux penser à quelques options.

Si votre chef de produit est un modérateur de site complet, il peut utiliser la clé à molette sur le message pour « changer de propriétaire », aucun plugin requis.

[Bas (Bas van Leeuwen)]

Je voulais signaler que j’ai passé pas mal de temps à essayer de comprendre pourquoi un modérateur mystère avait été créé sur un site.

Cet utilisateur avait un hash aléatoire comme adresse e-mail, ce qui semblait assez suspect.

Je pense qu’il serait bon de laisser une note pour le personnel, d’enregistrer l’octroi de la modération dans le journal du personnel, ou de donner une autre indication que cet utilisateur a été créé par un plugin

[Heliosurge (Dan DeMontmorency)]

Si vous êtes auto-hébergé ou si votre plan le prend en charge. La note utilisateur Plugin est très pratique

Discourse User Notes

Summary Share private notes with other staff about a user that normal users cannot see. Install Guide This plugin is bundled with Discourse core. There is no need to install the plugin separately. Configuration The User Notes plugin can be enabled either by the toggle or from its settings, both accessible from your /admin/plugins page: [/admin/plugin - user notes] [user notes - settings] Features Sometimes staff members want to share notes about…

[ToddZ]

J’essaie ceci et je me demande : quel est le comportement attendu concernant les notifications et les e-mails pour l’utilisateur staff_alias ?
L’utilisateur staff_alias reçoit une chaîne aléatoire à la place d’une adresse e-mail — ainsi, les e-mails qui seraient normalement envoyés sont ignorés.
Je ne peux pas donner à l’alias du personnel une vraie adresse e-mail, car Discourse essaie d’envoyer un e-mail de confirmation à la chaîne aléatoire.
Est-ce que staff_alias est une voie à sens unique ? Peut-être que je manque quelque chose. Y a-t-il, ou devrait-il y avoir, un moyen pour qu’il agisse comme un « front » pour un vrai compte, comme admin, qui reçoit les communications comme d’habitude ?

[nat (Natalie T)]

@ToddZ

Est-ce que staff_alias est à sens unique ?

Oui.

Dans la gestion de communautés plus importantes, l’identité peut être assez délicate. Lorsque vous autorisez de nombreux « membres du personnel » à publier sous le « staff alias », le compte du modérateur réel qui a utilisé le staff alias pour publier est également montré au personnel, comme le montre la capture d’écran

@Discourse

Si vous mettez un « vrai compte » derrière le staff alias, de nombreuses autres options utilisateur sont alors exposées, ce qui rend difficile de vérifier quel membre du personnel a effectué quelles modifications sur le compte.

Quel type de « communication » attendez-vous à recevoir ? J’ai l’impression qu’il existe une autre façon d’obtenir ce que vous espérez accomplir.

[ToddZ]

Merci de votre réponse, @nat. Je pensais simplement qu’en postant avec staff_alias, les utilisateurs répondraient, et je ne voudrais pas les ignorer.

Je craignais que personne ne voie de telles notifications – mais j’ai depuis découvert que je reçois bien ces e-mails et notifications sur le compte du personnel qui utilisait l’alias. Donc, c’est bien.

Quelques questions restantes :

• Le journal des e-mails ignorés inclut des échecs lors de l’envoi à la chaîne bidon staff_alias. Je suppose que je peux désactiver tous les paramètres d’e-mail pour staff_alias, et les e-mails seront toujours déclenchés et envoyés au compte du personnel « parent »… ?

• Je ne peux voir les messages personnels adressés à staff_alias qu’en fouillant dans son profil via l’administration. Peut-être serait-il judicieux de simplement désactiver la messagerie personnelle pour staff_alias ?

Merci pour vos conseils.

Je me sens plus proche de comprendre les choses après avoir expérimenté davantage… mais le sujet du plugin pourrait bénéficier d’une mention sur la façon dont les notifications sont acheminées, et de quelques conseils sur d’autres paramètres de compte pertinents.

[nat (Natalie T)]

@ToddZ

Le journal des e-mails ignorés inclut les échecs lors de la tentative d’envoi à la chaîne fictive staff_alias.

Ah, cela aurait dû être pris en compte dans le plugin lui-même. C’est un manque de considération lors de sa création, nous devrions donc le corriger.

@ToddZ

désactiver la messagerie personnelle vers staff_alias

Cela semble logique par défaut. Je vais vérifier avec mon équipe produit.

[ToddZ]

Salut @nat – il semble que le plugin pourrait avoir besoin d’un peu d’ajustement :

@ToddZ

Je suppose que je peux désactiver tous les paramètres d’e-mail pour staff_alias, et les e-mails seront quand même déclenchés et envoyés au compte “parent” du personnel… ?

(…)

Peut-être est-il judicieux de simplement désactiver la messagerie personnelle vers staff_alias ?

a.) J’ai essayé de désactiver les e-mails pour staff_alias, et cela devient un peu un trou noir. Les e-mails et notifications vers le compte “parent” ne sont pas déclenchés. Je vais donc réactiver les e-mails et ignorer les notifications d’e-mails ignorés pour le moment.

b.) La désactivation de la messagerie personnelle vers staff_alias n’empêche pas les comptes privilégiés comme les administrateurs et les modérateurs de lui envoyer des messages – et ces messages ne sont vus que si on les cherche. Peut-être que ceux-ci pourraient également être acheminés vers le compte “parent” concerné ?

Ces choses ne sont pas une grosse préoccupation pour moi pour le moment, mais j’imagine des problèmes pour les sites avec plus de personnel et une activité plus intense. Je suivrai toute nouvelle… merci !

[ToddZ]

Je viens de rencontrer le même problème. Il semble que cette PR attende toujours une révision…