Fragen zur Verwendung des Enterprice Policy Generator

  • Firefox-Version
    91.10.0esr
    Betriebssystem
    Linux Mint UE 64 Bit, Cinnamon Desktop

    Das FF Adon "Enterprice Policy Generator" lässt sich im oben benannten FF:

    * installieren

    * per FF GUI als auch per Menüzeile moz-extension:// und die jeweilige im System verwendete Nummer aufrufen

    Richtlinien lassen sich:
    * erstellen
    * als Konfiguration irgend wo innerhalb des Enterprice Policy Generator speichern und wieder neu laden

    Soweit so gut.

    Frage:

    Laut GUI des Enterprice Policy Generator sollte man auch policy Files durch den Enterprice Policy Generator einlesen können.

    Per besagter GUI kann man eine entsprechende Datei per Dateibrowser auswählen. Allerdings kann ich diese bisher nicht mit dem Enterprice Policy Generator öffnen. Der hierfür vorgesehene Menüpunkt "Konfiguration importieren" ist zwar bei mir vorhanden, jedoch ersteinmal ohne Funktion.

    Möglicher Weise muß man damit das so funktioniert der zu öffnenden Datei vorab geeignete Rechte verpassen oder vlt. auch etwas anderes. Was muß man tun um besagte Dtei öffnen zu können ?

    Nachtrag:

    Der Dateiname den man per Dateibrowser ausgewählt hat, erscheint nicht im Feld "Dateiname".

    Wenn man den Namen der zu öffnenden Datei nach der Auswahl per Dateibrowser, zusätzlich in das Feld "Dateiname" einbträgt, ist der Menüpunkt "Konfiguration importieren" auswählbar. Eien Konfiguration wird jedoch zumindestens bei meinen bisherigen Versuchen nicht geladen.

    3 Mal editiert, zuletzt von Alfredo534 (9. Juni 2022 um 09:10)

  • Hallo,

    Laut GUI des Enterprice Policy Generator sollte man auch policy Files durch den Enterprice Policy Generator einlesen können.

    Falls du das auf die Datei policies.json beziehst: Nein, eine solche Datei lässt sich nicht importieren, das würde technisch auch gar nicht funktionieren. Denn Ausgangslage für den EPG ist eine interne Schema-Konfiguration, aus welcher sich alles weitere selbstständig generiert: Die Oberfläche, die JSON-Erzeugung, die Datenstruktur zum lokalen Speichern und Laden sowie zum Exportieren und Importieren. Anders gesagt: Soll eine neue Richtlinie unterstützt werden, ergänze ich lediglich ein Schema und die Integration in die Oberfläche sowie sämtliche Funktionen stehen automatisch zur Verfügung, ohne dass auch nur eine einzige Zeile Code hinzu programmiert werden muss. Mit der Basis könnte man theoretisch im nächsten Schritt neue Richtlinien über das Internet verfügbar machen, ohne dass man die Erweiterung überhaupt je wieder aktualisieren muss. Aber das ist aktuell nicht geplant. Die dafür benötigten Informationen stecken jedenfalls nicht in der Datei policies.json mit drin. Ich könnte nur anhand dieser Datei keine Checkboxen im EPG aktivieren und Eingabefelder befüllen, ohne für jede Richtlinie eigenen Code zu implementieren, oder automatische Migrationen vornehmen, wenn eine Richtlinie durch eine neuere ersetzt oder ergänzt wird, und ich nicht möchte, dass der Anwender in seiner EPG-Konfiguration Daten verliert.

    Was du entweder speichern (und später wieder laden) oder als Datei exportieren (und später wieder importieren) kannst, ist eine Konfigurationsdatei für den EPG, welche genau den Zustand beinhaltet, den du im EPG konfiguriert hast. Man sieht im Importieren-Dialog des Betriebssystems normlerweise, welche Dateiendungen überhaupt erlaubt sind, in dem Fall handelt es sich um *.policy-Dateien, keine *.json-Dateien. Ich habe dafür bewusst mein eigenes simples Dateiformat geschaffen, damit da nicht irgendeine beliebige *.json-Datei importiert wird, mit welcher der EPG nichts anzufangen weiß.

  • Man sieht im Importieren-Dialog des Betriebssystems normlerweise, welche Dateiendungen überhaupt erlaubt sind, in dem Fall handelt es sich um *.policy-Dateien, keine *.json-Dateien. Ich habe dafür bewusst mein eigenes simples Dateiformat geschaffen, damit da nicht irgendeine beliebige *.json-Datei importiert wird, mit welcher der EPG nichts anzufangen weiß.

    Unter oben beschriebener Computerumgebung gelingt es mir:
    *.policy Dateien zu erzeugen, als auch diese im gewünschten Ordner ab zu speichern

    Gefundener Workaround um eine *.policy Datei importieren zu können:
    * Im Importdialog nach Auswahl der Datei per Dateiexplorer, im Feld "Name" des "!Konfiguration importieren" Dialogs, dort per Hand den Dateinamen ein trägt und hierbei die Angabe von ".policy" weg lässt.

    2 Mal editiert, zuletzt von Alfredo534 (9. Juni 2022 um 12:53)

  • Was meinst du mit „Workaround“? Du kannst exportierte Dateien ganz einfach wieder importieren. Um was für ein Problem willst du da herum arbeiten? :/ Den Dateinamen muss man nirgends per Hand eintragen. Einfach nur die Datei auswählen und einen beliebigen Namen vergeben, damit du deine Konfiguration im Lade-Bildschirm auch wieder erkennst. Schließlich kannst du beliebig viele Konfigurationen speichern, daher das Feld für den Namen.

  • Was meinst du mit „Workaround“? Du kannst exportierte Dateien ganz einfach wieder importieren. Um was für ein Problem willst du da herum arbeiten? :/ Den Dateinamen muss man nirgends per Hand eintragen.

    In der eingangs beschriebenen PC Konfiguration der Import einer dateiname.policy ist es zusätzlich zur Auswahl der zu importierenden Datei notwendig, das Feld "Name" in der von mir beschriebenen Art und Weise per Hand aus zu füllen. Vmtl. erfolgt das in anderen PC Betriebsystem und Browser Konstellationen automatisch in der an dieser Stelle notwendigen Syntax.

    Da das zumindest in meiner oben beschriebenen Konstellation nicht der Fall ist, wollte ich über den gefundenen Workaround berichten.

    Für mich selbst ist das damit erst einmal verwendbar.

  • Dass man einen Namen vergeben musst, schrieb ich doch in dem Teil, den du nicht zitiert hat. Das hat mit dem Dateinamen aber überhaupt nichts zu tun, ebenso wenig mit dem Betriebssystem oder irgendeiner notwendigen Syntax. Du kannst da reinschreiben, was du möchtest. Es geht nur um einen beliebigen Namen, den du hinterher im Dialog zum Laden der Konfiguration siehst. Daher ist das, was du beschreibst, auch kein Workaround, sondern die vollkommen korrekte Funktionsweise. Workaround würde bedeuten, dass es ein Problem gibt, welches du damit umgehst. Aber du umgehst damit ja kein Problem, sondern machst einfach nur das, was jeder tun muss, der diese Funktion nutzt.

  • Alles klar.

    Verbesserungsvorschlag:
    Die Beschriftung des Feldes "Name", selbsterklärend benennen. Z.B.

    Name Frei wählbarer Name der nachher da und dort erscheint.

    Oder vlt sollte man auch einfach den Dateinamen der zu importierenden Datei als Vorgabe in das Feld "Name" eintragen und es editierbar lassen.

  • Vor allem ist es gar nicht notwendig, das so extrem umständlich zu formulieren. Würde es eine Einschränkung für den Namen geben, dann wäre eine Erklärung sicherlich hilfreich. Ansonsten ist ein freies Textfeld natürlich frei befüllbar. Und welchen Zweck kann es schon erfüllen, einen Namen zu vergeben? Auch das liegt auf der Hand, dass es darum geht, die Konfiguration später unter diesem Namen wiederzufinden. Wo genau der Name erscheint, ist an der Stelle, wo die Konfiguration abgespeichert wird, aus meiner Sicht nicht relevant.

    Oder vlt sollte man auch einfach den Dateinamen der zu importierenden Datei als Vorgabe in das Feld "Name" eintragen und es editierbar lassen.

    Darin sehe ich keinen Vorteil. Standardmäßig sind die Konfigurationsdateien in der Art policy-export-1654761225769.policy benannt. Das als Namen zu verwenden, wäre sinnlos, weil das kaum jemand zuordnen kann. Dann könnte man das Namensfeld gleich komplett weglassen. Ich glaube nicht, dass es viele Nutzer gibt, welche tatsächlich die Datei umbenannt haben. Das heißt, für die meisten würde in dem Fall policy-export-1654761225769 als Name vorgeschlagen werden. Mit einem vorausgefüllten Feld kann aber keine Eingabe erzwungen werden, weil es ja schon einen Inhalt gibt. In der Folge würden vermutlich einige Nutzer ihre Konfigurationen unter einem Namen speichern, mit dem sie später nichts mehr anfangen können, weil sie einfach auf „Konfiguration importieren“ klicken. Da lasse ich das Feld lieber leer, womit jeder gezwungen ist, eine Eingabe vorzunehmen. Wenn dann ein unklarer Name vergeben wird, war es zumindest eine bewusste Entscheidung und nicht nur ein zu schneller Finger.

  • Vor allem ist es gar nicht notwendig, das so extrem umständlich zu formulieren.

    Würde es eine Einschränkung für den Namen geben, dann wäre eine Erklärung sicherlich hilfreich.

    Wer es kann, kann es natürlich gerne kurz und knackig ausdrücken. Vlt.:

    Irgendwasname. Pflichtfeld.

    Die Einschränkung ist z.B. das ein leeres Feld reproduzierbar nicht geht und ohne Fehlermeldung abgelehnt wird.

    Vorhin hatte ich noch eine zweite Variante die nicht ging, kann diese aber im Moment nicht reproduzieren.

    Wie gesagt, für mich ist es so wie es ist ok, da ich ja nach ein wenig Probieren heraus bekommen habe wie man damit umgehen kann.

  • Naja, dass es sich um ein Pflichtfeld handelt, ist keine Einschränkung bei der Benennung, denn ohne Eingabe gibt es ja überhaupt keinen Namen. :D Eine Fehlermeldung in dem Sinne braucht es deswegen nicht, weil eine Fehlermeldung ja erst bei einer falschen Eingabe erfolgen würde, der Importieren-Button aber gar nicht erst anklickbar ist, solange das Feld leer ist, und das auch visuell so dargestellt wird. Die Situation, in der eine Fehlermeldung angezeigt würde, gibt es also gar nicht.

    Worüber man tatsächlich nachdenken könnte, ist es, deutlicher klarzumachen, dass man etwas in das Feld eingeben muss. Ich werde das für das kommende Update im Hinterkopf behalten, kann aber noch keine Zusage machen, ob ich da tatsächlich etwas ändern werde. Ich muss erst darüber nachdenken, was mir dazu einfällt, ohne zu viel zu machen. Der Dialog soll ja einfach bleiben.