Pseudonym für Discourse-Mitarbeiter

[Discourse]

||||
-|-|
| Zusammenfassung | Mit dem Discourse Staff Alias können bestimmte Gruppen Themen und Beiträge erstellen sowie Bearbeiten vornehmen, indem sie als Alias-Benutzer agieren.
| Repository-Link | https://github.com/discourse/discourse-staff-alias
| Installationsanleitung | So installieren Sie Plugins in Discourse

Da dies ein #offizielles Plugin ist, das vom Discourse-Team gepflegt wird, können Support, Contribute > Bug, Contribute > UX und #contribute:feature-Anfragen in den entsprechenden Kategorien hier auf Meta gestellt und mit dem entsprechenden Plugin-Tag versehen werden. Klicken Sie auf einen der untenstehenden Links, um eine Anfrage zu starten.

 Support  Fehler  UX  Funktion

Das Discourse Staff Alias Plugin ermöglicht es bestimmten Gruppen, Themen und Beiträge zu erstellen sowie Bearbeiten vorzunehmen, indem sie als Alias-Benutzer agieren. Dies kann in Situationen nützlich sein, in denen Mitarbeiter auf Anfragen antworten oder Ankündigungen machen müssen, ohne ihre persönlichen Benutzernamen preiszugeben.

Aktivieren des Staff Alias

Nach der Installation kann das Staff Alias Plugin über seine Einstellungen aktiviert werden, die auf Ihrer admin/plugins-Seite zugänglich sind:

Dieses Plugin ist standardmäßig deaktiviert. Vor der Aktivierung muss ein neuer Benutzername für den Alias in der Admin-Einstellung staff alias username hinzugefügt werden:

Sobald das Plugin aktiviert ist, wird ein Benutzer mit diesem Benutzernamen erstellt.

---

Verwenden des Alias

Sobald aktiviert, kann der Staff Alias über das Dropdown-Menü für Aktionen im Composer ein- und ausgeschaltet werden. Benutzer in den erlaubten Gruppen können dann Themen und Beiträge erstellen sowie Bearbeiten vornehmen, indem sie den Staff Alias verwenden:

Das Thema/der Beitrag/die Bearbeitung wird dann so erscheinen, als wäre er/sie vom Staff Alias erstellt worden:

---

Nachverfolgen, wer den Alias verwendet hat

Wenn Sie zu einer der erlaubten Gruppen gehören, sehen Sie auch eine Notiz darüber, wer das Thema oder den Beitrag erstellt oder die Bearbeitung vorgenommen hat:

---

Einstellungen

Name	Beschreibung
staff alias enabled	Aktiviert das discourse-staff-alias Plugin
staff alias username	Benutzername des Alias-Benutzers
staff alias allowed groups	Gruppen, die berechtigt sind, als Staff Alias-Benutzer zu posten

Von uns gehostet? Dieses Plugin ist in unserer Enterprise-Tier verfügbar.

[sok777 (sok)]

@Discourse

Sie können entweder ein bestehendes Benutzerkonto verwenden oder einen neuen Namen eingeben, damit eines erstellt wird:

Es scheint, dass wir kein bestehendes Benutzerkonto hinzufügen können. Warum ist das so?

[JammyDodger]

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.

[sok777 (sok)]

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

[barto_95]

Wenn ich versuche, ein Thema zu erstellen, erhalte ich die Fehlermeldung

[JammyDodger]

Hat Ihr Mitarbeiter-Alias-Benutzer die richtigen Berechtigungen, um ein Thema in dieser Kategorie zu erstellen? (Haben sie Staff-Berechtigungen)

[barto_95]

Ja, das ist das Problem…

Danke

[barto_95]

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.

[jordan-violet]

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.

[fokx]

Ich stoße jedes Mal auf denselben Fehler, wenn ich auf einen Beitrag antworte, der nicht vom OP stammt:

Ein Fehler ist aufgetreten: Sie sind nicht berechtigt, die angeforderte Ressource anzuzeigen.

Nachdem ich mich ein wenig damit beschäftigt habe, habe ich die Ursache gefunden:

lib/discourse_staff_alias/posts_controller_extension.rb

Das Problem ist:

params[:whisper] ist \"false\", was ein String ist. Ändern Sie diese Zeile einfach zu:

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

…wird das Problem lösen.

Ich habe einen einfachen PR erstellt: FIX: InvalidAccess when replying to non-original post by fokx · Pull Request #67 · discourse/discourse-staff-alias · GitHub

[Heliosurge (Dan DeMontmorency)]

Hallo Jordan,

Mir fallen ein paar Optionen ein.

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.

[Bas (Bas van Leeuwen)]

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

[Heliosurge (Dan DeMontmorency)]

Wenn Sie eine selbst gehostete Version verwenden oder der Plan dies unterstützt, ist das Plugin „Benutzerhinweise“ unter Customization > Plugin sehr praktisch.

Discourse Benutzerhinweise

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]

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?

[nat (Natalie T)]

@ToddZ

Ist staff_alias eine Einbahnstraße?

Ja.

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.

@Discourse

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.

[ToddZ]

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.

[nat (Natalie T)]

[quote=“ToddZ, post:31, topic:156202”]Das E-Mail-Protokoll „Skipped“ enthält Fehler beim Versuch, an den staff_alias Bogus-String zu senden.
[/quote]

Ah, das hätte im Plugin selbst berücksichtigt werden sollen. Es ist ein Mangel an Rücksichtnahme bei der Erstellung, daher sollten wir das beheben.

[quote=“ToddZ, post:31, topic:156202”]persönliche Nachrichten an staff_alias deaktivieren
[/quote]

Das ergibt als Standard Sinn. Ich werde das mit meinem Produktteam klären.

[ToddZ]

Hallo @nat – es scheint, dass das Plugin etwas Feintuning gebrauchen könnte:

@ToddZ

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

(…)

Vielleicht ist es sinnvoll, die persönliche Nachrichtenübermittlung an staff_alias einfach zu deaktivieren?

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!

[ToddZ]

Ich bin gerade selbst auf dieses Problem gestoßen. Sieht so aus, als ob dieser PR noch auf eine Überprüfung wartet…