Bestehender Controller erweitern?

Hallo zusammen, ich hoffe, ich poste das hier richtig. Ich versuche, ein Plugin für meine neue Discourse-Website zu entwickeln.

Ich habe das Beispiel-Repo hier geforkt, ein Plugin-Outlet zum Laufen gebracht und bin dann gegen eine Wand gelaufen und fühlte mich ziemlich verloren und verwirrt. Ich fange gerade erst an, MVC-PHP-Frameworks wie Laravel zu verstehen, aber ich bin SEHR neu in JS-Frameworks. Ich habe noch nie Ruby, Rails oder Ember angefasst.

Das Problem

Meine Website ist für eine HOA-Community. Was ich tun möchte, ist, ein paar zusätzliche Datenfelder pro Benutzer zu sammeln und zu speichern:

  • legal_name (string)
  • is_owner (bool)
  • is_resident (bool)
  • building (string) - repräsentiert die Gebäudenummer
  • unit (string) - repräsentiert die Einheitsnummer
  • … und ein paar andere interne Variablen, wie z. B. ob ein Moderator sie bestätigt hat.

Ich möchte diese Felder für die Benutzerregistrierung erforderlich machen. Das bedeutet, das Formular zur Benutzerregistrierung zu ändern. Ich habe mich in das create-account-after-password-Outlet eingehakt und einige zusätzliche Felder anzeigen lassen, aber offensichtlich macht das die Funktionalität nicht.

Ich denke, ich muss den Controller in app/assets/javascripts/discourse/app/controllers/create-account.js erweitern, nicht nur, um die neuen Formularwerte bei der Übermittlung zu erfassen, sondern sogar für etwas so (scheinbar) Grundlegendes wie die Verwendung des Seitennamens this.siteSettings.title in einem client.en.yml-Übersetzungsfeld! (Im Moment sind die zusätzlichen Felder in meinem Registrierungsformular mit "Was ist Ihre Verbindung zu [fehlender %{title}-Wert]?" überschrieben. Was offensichtlich nicht gut ist.)

Je mehr ich versuchte, Antworten zu finden, desto mehr Fragen hatte ich und desto größer wurden sie. Verschiedene Anleitungen, denen ich zu folgen versuchte, waren offenbar für verschiedene Versionen von Discourse geschrieben. Das Beispiel-Plugin-Repo enthält Dinge, die ich nicht verstehe. Was ist der Unterschied zwischen einer Client-Route und einer Server-Route? Was ist der Unterschied zwischen einem Plugin und einem Modul? Ich bin so verloren.

Wenn mir jemand helfen könnte, wäre ich sehr dankbar. Vielen Dank im Voraus.

2 „Gefällt mir“

Ich denke, das könntest du mit Creating and configuring custom user fields machen.

3 „Gefällt mir“

Vielen Dank! Das bietet zwar nicht alle Funktionen, die ich mir vorstelle, aber es regt mich definitiv zum Nachdenken an, ob dieses Feature mir bei meinen Zielen helfen kann.

Auf jeden Fall muss ich immer noch die ursprüngliche Frage beantworten, wie bestehende Controller mit einem Plugin erweitert werden können. Ist so etwas möglich?

speichern, um es irgendwo anzuzeigen? Was möchten Sie mit diesen Daten tun? Ich habe den Eindruck, dass Sie sie für eine andere Funktionalität speichern möchten, anstatt sie nur irgendwo im Forum anzuzeigen.

Dies kann ohne Programmierung mit Creating and configuring custom user fields erreicht werden.

3 „Gefällt mir“

Was möchten Sie mit diesen Daten tun? Ich habe den Eindruck, dass Sie sie für eine andere Funktionalität speichern möchten, anstatt sie nur irgendwo im Forum anzuzeigen.

Nun, meine ultimative Hoffnung/Vision war:

1. Gestaffelte Moderation

Eigentümern jeder Einheit in der Gemeinschaft Moderatorbefugnisse ausschließlich über die Bewohner ihrer Einheit zu gewähren.

Angesichts der Tatsache, dass es in unserer Gemeinde fast 200 Einheiten gibt, schien es nicht machbar, die Gruppenfunktion zur Erreichung dieses Ziels zu nutzen. Siehe auch #3 unten, mit dem Gruppen ebenfalls kollidieren würden.

2. Anmelde-UX

Die perfekte Benutzererfahrung in meinen Augen würde auch das Dropdown-Menü für „Einheit“ im Anmeldeformular dynamisch auf die Wahl des Benutzers im Feld „Gebäude“ reagieren lassen, um nur Einheiten anzubieten, die sich in diesem Gebäude befinden. (Ich würde einen Weg finden, eine JSON-Konfigurationsdatei dafür zu parsen, wenn Discourse initialisiert wird.)

3. Datenschutzeinstellungen für Felder

Ich wollte jedem Benutzer die Wahl geben, ob er seine Gebäude- und/oder Einrichtungsnummer vor anderen Benutzern, die nicht zu seiner Einheit gehören, verbergen möchte.

Ich habe den Eindruck, dass die Kernfunktion für benutzerdefinierte Felder diese Option nur pro Feld (nicht pro Benutzer) und auch nur für Administratoren, nicht für die Benutzer selbst, bietet.

4. Schicke Formatierung

Dies wäre eher eine „Sahnehäubchen“-Sache, aber anstatt es als etwas wie „Eigentümer: ja“ anzuzeigen, wollte ich dem System spezielles Wissen über diese Felder geben, um sie in Benutzersusammenfassungen anders zu formatieren. Zum Beispiel ein SVG-Grundstückssymbol und ein Häkchen, wenn ein Moderator ihren Status bestätigt hat (oder ein Haussymbol für Bewohner). So etwas.

Also, ja …

Vielleicht bin ich hier zu wählerisch, aber ich habe das Gefühl, dass, sobald ich die Lernkurve für die Erreichung der Kernfunktionalität überwunden habe, die kleineren Wunschlistenpunkte fast trivial werden.

Viele der Bewohner meiner Gemeinde sind ältere Menschen mit wenig bis gar keiner Computerkenntnis. Ich habe ernsthafte Bedenken, dass einige der Bewohner meine Discourse-Website nicht annehmen und nutzen werden, nur weil sie neu und nicht Facebook ist, ganz zu schweigen von echten Nutzungsproblemen wie Datenschutz oder der unbestätigten Eingabe von Gebäude-/Einrichtungsnummern.

2 „Gefällt mir“

Gruppen funktionieren für diesen Zweck gut, und Sie können problemlos 200 Gruppen haben.
Alles, was Sie tun müssten, ist, das Feld manuell oder programmatisch einer Gruppe zuzuordnen. Aber Sie möchten vielleicht auch, dass Leute nach der Registrierung eine Art “Nachweis” senden.
Sie könnten es manuell tun, selbst programmieren, das benutzerdefinierte Wizard-Plugin von Pavilion verwenden dafür.

Das stimmt, aber Sie könnten Benutzer haben, die dieses Feld woanders öffentlich anzeigen lassen möchten, d. h. ein “privates” Gebäude-Feld und ein “öffentliches” Gebäude-Feld haben.

2 „Gefällt mir“

Wenn Sie Funktionen hinzufügen müssen, sollten Sie eine Plugin oder eine Theme-Komponente erstellen und nicht Discourse forken.

Das können Sie in einer Theme-Komponente tun, sodass Sie dafür kein Plugin benötigen. Wenn Sie jedoch ein Plugin erstellen, können Sie die Frontend-Änderungen auch in das Plugin aufnehmen. Developing Discourse Plugins - Part 1 - Create a basic plugin. Die Suche nach Plugins, die ähnliche Funktionalitäten hinzufügen, ist ebenfalls ein guter Ansatz. Es gibt ein Discourse-Repository namens all-the-plugins, das Sie verwenden können, um nach Beispielen zu suchen.

Das Vorhandensein von öffentlichen vs. privaten Versionen dieser Felder, wie vorgeschlagen, scheint eine gute Lösung zu sein. Sie können jedoch auch Benutzerfelder in einem Plugin hinzufügen und steuern, wie und ob diese Felder zum Serializer hinzugefügt werden, um sie anzuzeigen.

Dies ist das, was Theme-Komponenten tun. Theme Developer Quick Reference Guide könnte ein Anfang sein.

2 „Gefällt mir“

Ich glaube nicht, dass TS vorhatte, Discourse zu forken??

3 „Gefällt mir“

Es sieht so aus, als ob das von ihm verlinkte Repository ein Fork und kein Plugin ist.

2 „Gefällt mir“

image

Das Forken von discourse-plugin-skeleton scheint ein guter Anfang für mich zu sein, um ein Plugin zu schreiben…

5 „Gefällt mir“

Einverstanden! Ich weiß nicht, was ich gesehen habe! Ich weiß nicht, wie ich übersehen konnte, dass es eine Abzweigung war. :person_shrugging:

Ich dachte, ich hätte nach plugin.rb gesucht…

2 „Gefällt mir“

Es ist in Ordnung, ich habe daraus etwas gelernt :grin:

2 „Gefällt mir“

Danke @RGJ für die Klärung! :sweat_smile: Ja, ich hätte Discourse selbst niemals nur dafür geforkt.

Sie können auch Benutzerfelder in einem Plugin hinzufügen und steuern, wie und ob diese Felder zum Serializer hinzugefügt werden, um sie anzuzeigen.

Beinhaltet dies das Hinzufügen zu dem Modalformular “Konto erstellen” und das Erfordern dieser Felder? Können Sie mir Beispiele oder Anleitungen dafür geben?

Ich habe bereits den gesamten Leitfaden gelesen, den Sie unter “Entwicklung von Discourse-Plugins” verlinkt haben. Dort habe ich angefangen. Am Ende zeigt die einzige wirkliche Funktionalität, die erweitert werden kann, wie man eine neue Admin-Seite mit einem lila Tentakel erstellt. Ich habe bereits eine funktionierende Admin-Seite für mein Plugin, aber ich bin mir nicht einmal sicher, ob ich eine brauche. Sie steht in keinem Zusammenhang mit den aktuellen Problemen, vor denen ich stehe, daher ist ihr Beispiel für meinen Fall nicht sehr hilfreich.

2 „Gefällt mir“

Gruppen eignen sich gut für diesen Zweck, und Sie können problemlos 200 Gruppen haben.

Es wären tatsächlich zwischen 400 und 600, um alle Permutationen abzudecken (Besitzer, Bewohner oder Angehöriger jeder Einheit). Aber wie würde das funktionieren? Können 200 Gruppen für Benutzer alle identisch angezeigt werden, sodass nur „Besitzer“ anstelle von „Besitzer 187“ oder etwas Ähnlichem angezeigt wird?

Dies ist eher eine Detailfrage, aber wird eine interne Gruppen-ID irgendwo für Endbenutzer angezeigt, z. B. in einer URL? Wenn ein Benutzer seine Einheitsnummer als privat festgelegt hat, könnte jemand dies herausfinden, indem er die Gruppen-ID mit anderen Benutzern vergleicht?

Mir scheint, dass ich möglicherweise bessere Ergebnisse erzielen würde, wenn ich nur 3 Gruppen erstelle (Besitzer, Bewohner und Angehöriger – oder nur 2: Besitzer und Bewohner). Vielleicht könnte ich diese Gruppen wie gesagt entsprechend zuweisen und dann bestimmte Aktionen blockieren, wenn der Benutzer versucht, einen Bewohner der falschen Einheit zu moderieren?

Ich schätze, wenn das Blockieren einer solchen Aktion völlig unmöglich ist, dann bin ich gezwungen, 600 Gruppen zu erstellen … und hoffe einfach, dass keine Benutzer auf clevere Ideen kommen, das System zu „hacken“ und jemanden zu doxen.

Moment. Was? Wenn ich also ein Mieter bin und etwas im Forum sage, kann mein Vermieter meine Worte ändern? Themen gehören nur zu einer einzigen Kategorie, sodass Sie dann Gespräche führen würden, die nur zwischen dem Eigentümer und dem Mieter stattfinden.

Das ergibt keinen Sinn. Und es gibt wirklich keine einfache Möglichkeit, Berechtigungen auf Themenebene festzulegen.

Ich würde denken, dass Sie einige Gruppen und Kategorien pro Gebäude haben möchten, aber die Kontrolle pro Einheit ergibt einfach keinen Sinn.

Ich habe nichts über themenspezifische Berechtigungen gesagt.

Vielleicht ist „Moderator“ das falsche Wort? Ich weiß es nicht. (Ich habe Discourse noch nie zuvor benutzt.)

Ich spreche davon, den Zugriff auf das Forum pro Benutzer zu genehmigen oder zu entziehen. Nein, Ihr Vermieter kann Ihre Worte nicht ändern, aber er ist die Person mit der Befugnis, Ihre Anmeldung als Bewohner zu bestätigen, und wenn Sie sich zu einem TROLL entwickeln, kann er Sie stummschalten oder sperren. Beiträge und Themen werden gleichermaßen anhand einer Inhaltsrichtlinie von Website-Mitarbeitern und nicht von den Eigentümern moderiert.

Mein Ziel ist es, den Zugriff auf das Forum so weit wie möglich an die rechtliche Befehlskette über die Immobilie selbst zu koppeln. Kein bestätigter Eigentümer, der rechtmäßig eine Immobilie hier besitzt, sollte jemals gesperrt werden, aber wenn er einen Beitrag verfasst, der gegen die Richtlinien verstößt, kann dieser Beitrag von den Mitarbeitern entfernt werden. Wenn er die Immobilie jedoch verkauft, wird sein „Eigentümer“-Status sofort widerrufen, was möglicherweise zur Entfernung von der Website führt (es sei denn, er entscheidet sich für den „Affiliate“-Status und wird vom neuen Eigentümer der Immobilie genehmigt).

In unserer Gemeinschaft gibt es keine Beziehung zwischen einer Einheit und einer anderen im selben Gebäude, außer dass sie physisch verbunden ist. Das ist alles. Die Gruppierung von Personen nach Gebäuden ist im Grunde eine kosmetische UX-Entscheidung; die Ernennung von Autoritäten über ganze Gebäude wäre hier sinnlos.

Ich habe das hier gefunden: Add a custom per-user setting in a plugin

In den Kommentaren sagte ein Benutzer, er habe „einen Controller gepatcht“. Er hat eine .js.es6-Datei in assets/javascripts/discourse/initializers/, die sich auf eine Methode namens api.modifyClass() bezieht …

Hmmmmmm :thinking: Vielleicht bin ich hier auf etwas gestoßen.

2 „Gefällt mir“

Ja! Das ist genau das Richtige!

Ich rate Ihnen, sich besser mit Diskurs vertraut zu machen, bevor Sie entscheiden, was genau Sie tun möchten.

Ich denke, es wäre einfacher, wenn eine kleine Gruppe von Personen die Aufnahme von Mitgliedern genehmigt, anstatt dass jeder Eigentümer einer Wohneinheit auch den Zugang zur Website kontrolliert. Wenn die Eigentümer entscheiden, was passiert, wenn jemand die Wohneinheit verkauft? Wer würde dann entscheiden? Was ist mit einem Eigentümer, dem es egal ist, ob sein Mieter Mitglied des Forums sein kann? Wenn ich denke, dass es viel mehr Sinn macht, dies dem Manager des Komplexes zu überlassen, und wahrscheinlich kein Plugin erforderlich ist.

1 „Gefällt mir“