Ich möchte Themen auf der Seite „Neueste“ für Benutzer ausblenden, die Mitglieder einer bestimmten „schlechten“ Gruppe sind. Ich glaube, das kann mit einer Theme-Komponente erreicht werden, bin aber offen für Ideen. Dies ist ein Einzelfall, und ich benötige keine Benutzeroberfläche zur Bearbeitung der Parameter.
Hier ist eine ähnliche Anstrengung, vielleicht ein Ausgangspunkt. Der Ansatz besteht darin, api.modifyClass zu verwenden, um der Themen (den <tr> auf der Seite „Neueste“) eine Klasse hinzuzufügen, dann ein paar Zeilen CSS, um diese Klasse auf display: none zu setzen. Ich gehe davon aus, dass man den Benutzer in modifyClass abrufen und die Klasse hinzufügen kann, wenn der Benutzer Mitglied der „schlechten“ Gruppe ist.
(Mir ist bewusst, dass dies ihre Berechtigungen nicht beeinträchtigt, sie können das Thema immer noch in der Kategorie- oder Suchansicht sehen, sie erhalten immer noch E-Mails, sie könnten meinen Trick entdecken und ihr lokales CSS bearbeiten usw. Ich möchte nur eine Belästigung erzeugen und sie zu einer Handlung bewegen. Angesichts aller Einschränkungen denke ich, dass dieser Ansatz funktionieren wird.)
Wann benötigen Sie es fertig?
In den nächsten Wochen.
Was ist Ihr Budget in USD, das Sie für diese Aufgabe anbieten können?
Möchten Sie, dass /latest für diese Benutzer leer ist? Oder nur einige Themen ausblenden?
Der Punkt ist, sie zu ärgern? (weil sie alle ärgern?). Ich frage mich nur, ob es einen besseren Weg gibt, sie zu ärgern.
Ich habe vergessen zu erwähnen, dass wir ihnen immer noch erlauben möchten, ein Thema in „Neueste“ zu sehen – die aktualisierten Nutzungsbedingungen.
Das gefällt mir auch nicht besonders gut, aber es ist das Beste, was mir einfällt. Ziel ist es, alle Benutzer dazu zu bringen, die aktualisierten Nutzungsbedingungen mit höherer als üblicher Wichtigkeit zu unterzeichnen. Es gab eine Diskussion unter How to force existing users to accept ToS, dass Discourse Policy vielleicht helfen könnte. Aber Policy erzwingt nichts, und aufgrund der Wichtigkeit der neuen Nutzungsbedingungen wollen wir mehr als eine blaue Sprechblase, um die Benutzer zu nerven. Wir hatten vor einigen Jahren ein Plugin entwickeln lassen, das Mitglieder einer Gruppe hinzufügt, wenn sie einer Richtlinie zustimmen, und das hat für einige Dinge funktioniert, aber ich sehe nicht, wie es für dieses Problem funktionieren könnte.
Wir haben bereits eine ziemlich ausgeklügelte Sammlung von Gruppen und Kategorien, sodass wir die Berechtigungen für jede Kategorie nicht einfach von „Jeder“ auf „tos-acceptors“ ändern können. Wenn die Berechtigungen für Kategorien boolesche Logik unterstützen würden, könnten wir vielleicht die Berechtigungen ändern, um nur Benutzern zu erlauben, die Mitglieder von sowohl „premium-group“ als auch „tos-acceptors“ sind. Aber das unterstützt es nicht.
Ich habe keine starke Meinung dazu, wie man sie nerven kann. Wenn es eine eingebaute Durchsetzung von Discourse Policy gäbe, würde ich diese verwenden. Aber in diesem Fall brauchen wir mehr als eine blaue Sprechblase.
Ich habe auch kurz darüber nachgedacht, sie mit einem Permalink umzuleiten, wenn sie kein Mitglied von tos-acceptors sind. Das ist immer noch eine Option, wenn wir die Benutzer-ID oder den Benutzernamen als Abfrageparameter an die Permalink-URL anhängen könnten. Wenn wir sie zu Docusign oder etwas Ähnlichem umleiten, könnte ich einen Webhook einrichten, um sie zur Gruppe „tos-acceptors“ hinzuzufügen, damit sie nicht mehr umgeleitet werden. Klingt das nach einem besseren Plan?
Vielleicht schauen Sie sich eine der vorhandenen „Gate“-Komponenten an und passen deren Kriterien an? Diese haben ziemlich störende Blocker und informieren Benutzer auf klare und einfache Weise darüber, was erwartet wird.
Sie können Benutzer möglicherweise dazu bringen, den Nutzungsbedingungen zuzustimmen, indem Sie einige der Funktionen des Discourse Custom Wizard-Plugins verwenden:
Es gibt definitiv Spielraum, um Bedingungen basierend auf der Gruppenzugehörigkeit festzulegen und die Gruppenzugehörigkeit aus der Ausgabe des Assistenten zu ändern.
Ein Plugin, das eine komplexe Berechtigungseinstellung für Kategorien ermöglichen würde, wäre in vielen Situationen nützlich. Das wäre vielleicht die beste Verwendung von Entwicklungszeit für dieses Problem?
Vielleicht mit einer Slug-Formel in einer Texteinstellung:
z.B.: (#tos-acceptor or #direct-concern) and #premium-group