Dies ist wie ein Feature - Dev Thema, ich bin mir nicht sicher, in welches es gehört.
Gibt es eine Möglichkeit, die Website-Einstellungen in einem Plugin zu ändern? Ich bin mir zu 99 % sicher, dass dies nicht möglich ist, aber ich möchte es nur bestätigen.
Wenn dies nicht möglich ist, kann ich einen Vorschlag einreichen, es nicht unveränderlich zu machen? Oder vielleicht eine API oder eine Möglichkeit, die unveränderliche Eigenschaft von SiteSettings „freizuschalten“?
Ein möglicher Anwendungsfall, den ich in Betracht ziehe, ist die Aufnahme einer Liste von geschützten Kategorien in eine Einstellung, damit es für den Administrator einfacher ist, diese ein- oder auszuschließen.
[quote=“NateDhaliwal, post:1, topic:389676”]Ein möglicher Anwendungsfall, den ich mir ansehe, ist die Aufnahme einer Liste geschützter Kategorien in eine Einstellung, damit es für den Administrator einfacher wird, sie ein- oder auszuschließen.
[/quote]
Fangen wir hier an und arbeiten uns von außen nach innen vor.
Können Sie zunächst den Anwendungsfall aus Sicht der Community beschreiben? Was versuchen sie zu erreichen und was macht es ihnen im Moment schwer? Welche Funktion stellen Sie sich vor, die ihr Bedürfnis effektiver lösen würde (unabhängig davon, wie sie implementiert wird)?
Von dort aus können wir dann feststellen, ob dies am besten in einem Plugin oder als Kernfunktion umgesetzt werden sollte.
Von dort aus können wir dann Vorschläge zur Implementierung diskutieren.
Ich ging fälschlicherweise davon aus, dass Einstellungen in Plugins in Ruby unveränderlich sind, da sie es in TCs sind. Ich werde das mal versuchen.
Es wäre schön, sie in TCs bearbeitbar zu machen. Mein Anwendungsfall (für den ich momentan ein Plugin verwende) ist, dass ich standardmäßig alle Themen und Beiträge in allen Kategorien nehme und damit einige Dinge mache, aber geschützte Kategorien ausschließen möchte (wie eine Einstellung excluded_categories).
Wenn es jedoch möglich wäre, geschützte Kategorien zu der Einstellung hinzuzufügen und danach darauf zuzugreifen, wäre es einfacher. Auf diese Weise könnten Administratoren einige geschützte Kategorien einschließen, wenn sie dies wünschen, indem sie sie aus der Einstellung entfernen.
Mit @pfaffmans Idee ließe sich das wahrscheinlich umsetzen, aber nicht in TCs.
Das Problem dabei ist, dass ich die geschützten Kategorien nicht im Voraus kenne.
Wenn Sie als Administrator angemeldet sind, könnte eine Theme-Komponente siteSettings über die API ändern.
Fügen Sie dann einfach eine Theme-Komponenten-Einstellung hinzu und fügen Sie diese Kategorien hinzu? Sie beziehen sich nicht auf eine protected_categories-Site-Einstellung, an die ich gerade nicht denke, oder? Also etwas wie das hier?
Ich würde gerne mehr erfahren. Ich denke, es würde mir helfen, diese Anfrage in einen besseren Kontext zu stellen.
Sind Sie bereit, mehr über Ihre Community zu erzählen?
Sind Sie der Hauptnutzer dieser Funktion oder gibt es andere in Ihrem Team, die sie benötigen? Haben Sie eine benutzerorientierte Dokumentation für den Workflow, der von dieser Funktion abhängt? Wenn ja, wie sieht diese aus? Wenn nicht, können Sie kurz beschreiben, wie sie aussehen könnte?
@mcwumbly@pfaffman Okay, lassen Sie mich versuchen, dies so gut wie möglich zu erklären.
Ich entwickle ein Plugin, das Themen und Beiträge nimmt und sie als Markdown-Dateien (wie ein Archiv) auf GitHub veröffentlicht.
Allerdings möchte ich private Kategorien (ich glaube, das ist jetzt der richtige Begriff?) davon ausschließen, da sie „privat“ sind.
Daher suche ich nach einer Möglichkeit, eine Einstellung mit der Liste der privaten Kategorien vorab auszufüllen, die nicht im default-Parameter definiert werden kann, da ich im Voraus nicht wüsste, was die privaten Kategorien sind.
Falls dies durch direkte Änderung von SiteSetting in Ruby möglich ist, kann dasselbe dann auch mit den settings einer Theme Component erreicht werden? Ich bin mir ziemlich sicher, dass letztere unveränderlich ist. Gibt es eine Möglichkeit, sie in einer Theme Component zu ändern?
Es geht eigentlich nicht um die Community. Ich versuche mich auf meine eigene Weise an diesem (auch mit einem Backfill-Job). Dies speichert jedes Thema und jeden Beitrag als Markdown-Datei in einem Repository.
Ich weiß immer noch nicht, was „privat“ für Sie bedeutet. Bedeutet es, dass Sie nur Kategorien wünschen, die für alle oder für anonyme Benutzer sichtbar sind? Oder haben Sie eine andere Definition?
Wenn Sie diese wünschen, kann Ihr Plugin nur diese abrufen, vielleicht durch eine Suche, der Sie einen Benutzer übergeben (oder vielleicht durch Aufrufen eines Guardians) oder indem Sie einfach die Berechtigungen überprüfen.
Oder wenn „privat“ eine Meinung ist, können Sie eine Einstellung hinzufügen.
Und Sie möchten dies wahrscheinlich in einem Job tun, der täglich oder so läuft?
Wenn Sie Dinge auf GitHub pushen, würde ich denken, dass Sie möchten, dass Discourse dies einfach erledigt, anstatt sich damit herumzuschlagen, dass Ihr Browser Daten an Discourse pusht? Ich sehe nicht, wie oder warum Sie dies mit einer Theme-Komponente tun würden.
Ich meine Kategorien wie Staff und andere, die durch Gruppen eingeschränkt sind. Ich denke, das ist mit einem Plugin möglich, aber ich nehme an, dass TC-Einstellungen dann nicht mehr änderbar sind?
Nochmals, ich denke, je mehr man sich aus der Perspektive des Endergebnisses nähert, auf das man hinarbeitet, desto einfacher wird es sein, Ratschläge zu geben.
Vielen Dank also für das Teilen dieses Links:
Vielleicht können wir dies als Ausgangspunkt verwenden, um die funktionale Spezifikation, die Sie bisher implizit definiert haben, weiter zu verdeutlichen.
So wie ich es jetzt verstehe, möchten Sie:
ein statisches HTML-Archiv einer Discourse-Seite erstellen
es aktuell halten, wenn neue Inhalte erstellt werden
bestimmte Kategorien ausschließen
Und das Design, das Sie derzeit untersuchen, ist:
ein Plugin erstellen, das:
Administratoren ermöglicht:
explizit zu konfigurieren, welche Kategorien ausgeschlossen werden sollen
eine Git-URL für die Speicherung statischer Inhalte zu konfigurieren
einen Hintergrundjob periodisch ausführt, der:
Markdown-Dateien für Themen und Beiträge erstellt
diese in einer bestimmten Datei-/Verzeichnisstruktur in einem Git-Repository speichert
dies auf GitHub pusht
Endbenutzer können den Inhalt auf GitHub als HTML sehen
Beziehe ich mich mit der Methode Category.where(...) korrekt auf diese „privaten“ Kategorien? Aber was ist, wenn der Administrator (einige) davon einschließen möchte – muss ich eine Einstellung include categories haben, die den im Code definierten „privaten“ Kategorien entgegenwirkt? Wäre das kontraproduktiv?
Ich verstehe das immer noch nicht. Ja, Sie können diese Einstellungen in einer SiteSetting hinzufügen, und ja, das Plugin könnte diese Einstellung lesen und sogar ändern. Aber warum sollte es die Einstellung angesichts des obigen Szenarios ändern müssen?
Angenommen, ich habe 5 Kategorien: A, B, C, D und E. Nehmen wir nun an, B und C sind nur für bestimmte Gruppen verfügbar. Um zu verhindern, dass private Themen hier geteilt werden, wenn sie in das Repository hochgeladen werden, werden B und C zusammen mit anderen wie z.B. Staff zur Einstellung excluded_categories hinzugefügt.
Angenommen, der Seitenadministrator ist damit einverstanden, dass B’s Themen geteilt werden, kann er B aus der Einstellung entfernen und C dort belassen.
Die excluded_categories müssten also von Anfang an geändert werden, um die „privaten“ Kategorien B und C hinzuzufügen. Ich bin mir nicht sicher, ob das Sinn ergibt?
Obwohl das technisch absolut möglich ist, halte ich den Ansatz für zu kompliziert, insbesondere da „am Anfang“ schwer zu definieren/erkennen ist, und Sie vermeiden möchten, dass das Plugin B wieder hinzufügt, nachdem der Seitenadministrator es entfernt hat. Außerdem müsste das Plugin eine neu hinzugefügte private Kategorie hinzufügen, aber es müsste in der Lage sein, den Unterschied zwischen einer neuen Kategorie (hinzufügen) und einer Kategorie, die zuvor vom Administrator entfernt wurde (nicht erneut hinzufügen), zu erkennen.
Ich würde mich für eine Einstellung include_private_categories entscheiden, die zunächst leer ist, und das Plugin würde einfach alle öffentlichen Kategorien UND die Kategorien in include_private_categories verarbeiten. Das erspart Ihnen eine Menge Kopfzerbrechen.
Ein weiteres alternatives Design, das ich mir hier vorstellen könnte, wäre die Verwendung von zwei separaten Repositories: eines für öffentliche Inhalte und eines für private Inhalte.
Das private Inhalts-Repository selbst könnte privat gehalten werden (Sie könnten unabhängig davon bestimmen, wer darauf Zugriff hat).