Alias du personnel Discourse

[Discourse]

	Summary	Discourse Staff Alias allows set groups to create topics and posts, as well as make edits, as an alias user.
	Repository Link	https://github.com/discourse/discourse-staff-alias
	Install Guide	How to install plugins in Discourse

As this is an official plugin maintained by the Discourse team, support, bug, ux, and feature requests can be made in the respective categories here on Meta, and tagged with the appropriate plugin tag. Click on a link below to get one started.

 Support  Bug  UX  Feature

The Discourse Staff Alias plugin allows certain groups to create topics and posts, as well as make edits, as an alias user. This can be useful in situations where staff members need to respond to queries or make announcements without revealing their personal usernames.

Enabling Staff Alias

Once installed, the Staff Alias plugin can be enabled from its settings, accessed from your admin/plugins page:

This plugin is default disabled, and before enabling a new username for the alias must be added to the staff alias username admin setting:

Once the plugin is enabled, a user with that username will be created.

---

Using the Alias

Once enabled, the staff alias can be toggled on using the composer’s actions drop-down, and users in the allowed groups can then choose to create topics and posts, as well as make edits, using the staff alias:

The topic/post/edit will then appear as if created by the staff alias:

---

Keeping track of who used the Alias

If you are in one of the allowed groups you will also see a note of who created the topic or post, or made the edit:

---

Settings

Name	Description
staff alias enabled	Enable discourse-staff-alias plugin
staff alias username	Username of the alias user
staff alias allowed groups	Groups that are allowed to post as staff alias user

Hosted by us? This plugin is available on our Enterprise tier.

Last edited by @Bas 2024-08-12T14:12:55Z

Check document

Perform check on document:

[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…