Entschuldigung für den alten Beitrag, aber warum richtet ihr euer Theme nicht als Repository auf GitHub ein? Gebt euerer Design- und UX-Abteilung die Berechtigung, das Theme auf GitHub zu aktualisieren.
In Discourse könnt ihr Themes nun so einstellen, dass sie beim Neuaufbau automatisch aktualisiert werden.
Eure Administratoren müssen dann nur noch den Neuaufbau durchführen, um Änderungen der Design- und UX-Abteilung zu übernehmen, und diese benötigen überhaupt keinen Admin-Zugriff mehr.
Nur eine kurze Anmerkung:
Bei der Programmierung von Zugriffssteuerung sollten RBAC-Prüfungen im Allgemeinen serverseitig durchgeführt werden.
RBAC-Code in clientseitigem JavaScript kann vom Client manipuliert werden.
Das bedeutet, dass die Definition der Kern-RBAC-Berechtigungen für Mitarbeiter, Administratoren und Moderatoren (allgemein gesprochen) in Rails und nicht in JavaScript erfolgen sollte.
Übrigens handelt Discourse RBAC mittlerweile ebenfalls so, indem es das verwendet, was Discourse „Guardian
In Discourse 2.5 und neuer gibt es auch das Vertrauenslevel 4 und Kategoriemoderatoren.
Ich habe einen ähnlichen Anwendungsfall: Ich leite eine kleine Non-Profit-Community, in der einer unserer Nutzer die Themes und das Design pflegt.
Ich möchte niemandem außer mir und meinem Mitinhaber Zugriff auf private Benutzerdaten (z. B. E-Mail-Adressen usw.) gewähren, aber ich habe vier Moderatoren.
Damit der Designer arbeiten kann, habe ich eine Kopie der Seite ohne Inhalte erstellt, auf der er Administrator ist, und kopiere Themes und Komponenten manuell. Dies ist jedoch nicht wünschenswert, da einige Änderungen Inhalte benötigen, um sie zu überprüfen.
Warum fügst du nicht einfach etwas Inhalt auf die Staging- / Testseite hinzu? Das wäre die übliche Empfehlung.
Lassen Sie also den Entwickler auf der Staging-Site arbeiten und die Themes auf GitHub pushen. Sie müssen sie jedoch weiterhin selbst aktualisieren. Es könnte gelingen, das Upgrade über die API durchzuführen und dem Entwickler so die Möglichkeit zu geben, es auszulösen.
Ich arbeite an einem Tool, das dabei helfen könnte.
Wir haben genau diese Anforderung auch, hat dies zufällig jemand gelöst?
Ich weiß nicht, ob das in dieser Situation nützlich ist, aber wenn Sie nur einige Inhalte benötigen, gibt es die populate Rake-Aufgabe:
Danke, leider ist es im Moment nicht wirklich nützlich.
Wenn Sie dem Designer nicht vertrauen, dass er Ihre Daten sieht, welche Lösung würden Sie sich vorstellen?
Könnten Sie ihm nur einen API-Schlüssel geben, mit dem er die discourse_cli verwenden kann, um das Thema dort hochzuladen, und ihn dann deaktivieren, wenn er fertig ist, vielleicht?
Es gibt absolut keinen Grund, warum ein Designer Zugriff auf 100.000 Benutzer haben sollte, lol. Außerdem würde dies gegen die DSGVO-Regeln verstoßen. Ist es möglich, einen CLI-Schlüssel nur für Theme-Updates zu geben?
Entschuldigen Sie vielmals! Ich glaube, Sie haben Recht.
Im Gegensatz zu dem Zeitpunkt, als dieses Thema erstellt wurde (was offenbar der Zustand meines Gehirns war, als ich meine Antwort schrieb), haben wir jetzt granulare API-Schlüssel. Es sollte nicht allzu schwer sein, einen neuen Geltungsbereich nur für die Verwaltung von Themes hinzuzufügen.
Es könnte sich lohnen, ein neues Thema in Feature zu erstellen und nach einem Theme-Entwickler-API-Schlüssel-Geltungsbereich zu fragen. Das scheint eine gute Idee zu sein.
Nein, das ist es nicht. Es kann gegen die Regeln dieser Website verstoßen, aber diese können und sollten sich ändern.
Es wäre gut, wenn @AV_C vielleicht einen Verweis auf diese Anforderung posten könnte. Obwohl ich gut verstehen kann, warum ein Kunde den Zugriff auf die Benutzerbasis und sogar auf private Kategorien aus verschiedenen Gründen einschränken möchte. Vollständige Administratoren können die Anmelde-E-Mails der Mitglieder einsehen und private Kategorien können andere sensible Inhalte enthalten, je nach Anwendungsfall des Kunden.
Ich denke, @pfaffman hat eine gute Idee, um sicherzustellen, dass diese Art von Lücke durch eine eingeschränkte Admin-API abgedeckt werden kann. Sobald die Designerarbeit abgeschlossen ist, kann der Schlüssel widerrufen werden, bis er benötigt wird.
Dies würde auch zu Jays Idee passen, einen Benutzer nicht als Administrator auf der Über-uns-Seite anzuzeigen.