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:
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:
Es besteht die Möglichkeit, dass ich beim Verfassen der Anweisungen einen Fehler gemacht habe.
Außerdem kann ich keinen bestehenden Benutzer mehr als Staff-Alias einrichten, wenn ich es erneut teste, was Sinn ergibt, wenn ich darüber nachdenke. Ich bin mir nicht sicher, was mich zu der Annahme verleitet hat, dass dies möglich sei. Ich werde die Anweisungen aktualisieren.
Danke! Es ist schade, denn ich denke, es macht es einheitlich, wenn alle Mitarbeiter den Seitennamen oder ein bereits existierendes „Master“-Konto verwenden können. Zum Beispiel @Discourse
Es ist nicht möglich, auf eine Nachricht zu antworten, wenn der Benutzer die Option „Mitarbeiter-Alias“ verwendet. Ich erhalte denselben Fehler wie oben, aber wenn ich den Mitarbeiter-Alias verwende, um auf eine Nachricht zu antworten, ist das Thema in Ordnung.
Wie hoch sind die Chancen, dass dies zu einem dynamischen Tool zum „Posten als anderer Benutzer“ erweitert werden kann?
Wir haben einen Anwendungsfall, bei dem ein Produktkommunikationsmanager neue Themen als andere Produktmanager in unserer Organisation erstellen muss. Dieses Tool scheint über die meiste Funktionalität zu verfügen, würde jedoch die Möglichkeit erfordern, den Benutzer, als der gepostet wird, dynamisch festzulegen.
Wenn Ihr Produktmanager ein Voll-Site-Moderator ist, kann er den Schraubenschlüssel für den Beitrag verwenden, um den “Besitz zu ändern”, ohne dass Plugins erforderlich sind.
Ich wollte darauf hinweisen, dass ich gerade eine ganze Weile damit verbracht habe, herauszufinden, warum auf einer Website ein mysteriöser Moderator erstellt wurde.
Dieser Benutzer hatte eine zufällige Hash als E-Mail, was ziemlich verdächtig aussah.
Ich denke, es wäre gut, eine Staff-Note zu hinterlassen, die „Moderationsgewährung“ im Staff-Log zu protokollieren oder eine andere Angabe zu machen, dass dieser Benutzer von einem Plugin erstellt wurde
Ich probiere das aus und frage mich: Wie ist das erwartete Verhalten in Bezug auf Benachrichtigungen und E-Mails für den Benutzer staff_alias?
Der Benutzer staff_alias erhält eine zufällige Zeichenfolge anstelle einer E-Mail-Adresse – E-Mails, die normalerweise gesendet würden, werden übersprungen.
Ich kann dem Staff-Alias keine echte E-Mail-Adresse geben, da Discourse versucht, eine Bestätigungs-E-Mail an die zufällige Zeichenfolge zu senden.
Ist staff_alias eine Einbahnstraße? Vielleicht übersehe ich etwas. Gibt es – oder sollte es geben – eine Möglichkeit, dass er als „Front“ für ein echtes Konto, wie z. B. Admin, fungiert, das Mitteilungen wie gewohnt erhält?
Bei der Verwaltung größerer Communities kann die Identität sehr schwierig sein. Wenn Sie vielen „Mitarbeitern“ erlauben, als „Mitarbeiter-Alias“ zu posten, wird das tatsächliche Moderatorenkonto, das den Mitarbeiter-Alias zum Posten verwendet hat, auch den Mitarbeitern angezeigt, wie im Screenshot zu sehen ist.
Wenn Sie ein „echtes Konto“ hinter dem Mitarbeiter-Alias setzen, werden viele andere Benutzeroptionen offengelegt, was es schwierig macht zu überprüfen, welcher Mitarbeiter welche Änderungen am Konto vorgenommen hat.
Welche Art von „Kommunikation“ erwarten Sie zu erhalten? Ich habe das Gefühl, es gibt einen anderen Weg, um zu dem zu gelangen, was Sie erreichen möchten.
Danke für die Antwort, @nat. Ich dachte nur, wenn ich mit staff_alias poste, würden die Benutzer antworten, und ich möchte sie nicht übersehen.
Ich befürchtete, niemand würde solche Benachrichtigungen sehen – aber inzwischen habe ich festgestellt, dass ich diese E-Mails und Benachrichtigungen tatsächlich an das Staff-Konto erhalte, das den Alias verwendet hat. Das ist also cool.
Ein paar verbleibende Fragen:
Das E-Mail-Skipped-Protokoll enthält Fehler beim Versuch, an die staff_alias-Bogus-Zeichenkette zu senden. Ich vermute, ich kann alle E-Mail-Einstellungen für staff_alias deaktivieren, und E-Mails werden trotzdem ausgelöst und an das “übergeordnete” Staff-Konto gesendet…?
Ich kann persönliche Nachrichten an staff_alias nur sehen, indem ich über die Administration sein Profil durchsuche. Vielleicht ist es sinnvoll, die persönliche Nachrichtenübermittlung an staff_alias einfach zu deaktivieren?
Danke für jeden Rat.
Ich habe das Gefühl, dass ich die Dinge nach weiterem Experimentieren besser verstehe… aber das Plugin-Thema könnte von einer Erwähnung profitieren, wie Benachrichtigungen weitergeleitet werden, und einigen Hinweisen zu anderen relevanten Kontoeinstellungen.
Hallo @nat – es scheint, dass das Plugin etwas Feintuning gebrauchen könnte:
a.) Ich habe versucht, E-Mails für staff_alias zu deaktivieren, und es wird zu einem schwarzen Loch. E-Mails und Benachrichtigungen an das „übergeordnete“ Konto werden nicht ausgelöst. Daher werde ich E-Mails wieder aktivieren und die übersprungenen E-Mail-Benachrichtigungen vorerst ignorieren.
b.) Die Deaktivierung der persönlichen Nachrichtenübermittlung an staff_alias hindert privilegierte Konten wie Administratoren und Moderatoren nicht daran, es zu kontaktieren – und diese Nachrichten werden nur gesehen, wenn man danach sucht. Vielleicht könnten diese auch an das entsprechende „übergeordnete“ Konto weitergeleitet werden?
Diese Dinge sind für mich noch keine große Sorge, aber ich kann mir Probleme für Websites mit mehr Personal und höherer Aktivität vorstellen. Ich werde auf Neuigkeiten warten… danke!
Ich werde die Anweisungen aktualisieren. 
