Questions & Answers

[arnbae]

Hallo,

wir haben in den Metadaten ein paar Eingabekomponenten, unter anderem eine CMS_INPUT_PERMISSION namens "roles". Im Root-Knoten der Strukturverwaltung sind keine Metadaten gesetzt.

Solange in den Metadaten nichts editiert wurde, liefert #global.node.meta("roles", "inherit") immer null.

Nun habe wir folgendes Problem: Ein Redakteur setzt an einem Strukturknoten eines der anderen Felder in den Metadaten, zum Beispiel einen Radiobutton. Neben dem Knoten erscheint ein "i", also Metadaten gesetzt.

In der CMS_INPUT_PERMISSION ist der Haken "Rechte definieren" zu diesem Zeitpunkt nicht gesetzt. Trotzdem liefert #global.node.meta("roles", "inherit") nicht mehr null, sondern ein Permission-Objekt, und zwar wird allen Gruppen der Zutritt verboten (Default).

Die gelieferten Rechtedefinitionen sind dieselben, wie wenn ich den Haken "Rechte definieren" setze. Wenn ich ihn aber setze und dann wieder lösche, liefert #global.node.meta("roles", "inherit") wieder null! So würde ich es von Anfang an erwarten.

Im Klartext: Ich habe zwei Zustände der CMS_INPUT_PERMISSION, die beide  für den Redakteur identisch aussehen: Eine (ohne Haken, anfangs) liefert ein Permission-Objekt, welches jeglichen Zugang sperrt, das andere (ohne Haken, nach Ein- und Ausschalten) liefert null, so dass ich erkennen kann, dass keine Rechte definiert sind. Wir haben versucht, den Redakteuren beizubringen, den Haken zu setzen und gleich wieder zu löschen, aber in 50% aller Fälle wird das vergessen. Verstehe ich auch.

Ist das ein Bug? Wenn nicht, kann ich den Zustand des Hakens "Rechte definieren" gezielt abfragen, und dann das Permission-Objekt einfach ignoieren?

Grüße,

Arndt

[klein]

Hallo,

geht es hier um FS V4.2R4? In der Version 4.2.474 wurde in diesem Zusammenhang ein Bug gefixed (interne ID 114711) - evtl. stellt dieser Bugfix auch eine Lösung für Ihren Fall dar (die Abfrage getMeta() und hasMeta() wurden dort überarbeitet)!

Bitte spielen Sie also die derzeit aktuelle FS Version 4.2.476 ein nd geben Sie kurz Bescheid, falls Ihr Problem dadurch nicht behoben wurde.

Übrigens, was ist, wenn Sie in der Struktur-Wurzel den Haken "Rechte definieren" setzen und zwar für alle Gruppen und dann in den Unterknoten die Gruppen einschränken?

Gruß,

Walter Klein.

[arnbae]

Hallo,

leider nicht, Version ist die brandheiße 4.2.476.52922.

Wenn ich im Root-Knoten alle Rechte auf "erlaubt" setze, habe ich dann auch die Rechte entsprechend im Unterknoten geerbt - für alle beschriebenen Fälle.

Allerdings unterscheide ich in meiner Logik - aus FS 3.1 übernommen - generell zwei Fälle:

• Ein Knoten ist für Gruppen erlaubt oder verboten
• Ein Knoten ist anonym verfügbar, benötigt also keinerlei Rechte

Der Unterschied zu "für alle Gruppen erlaubt" und "keine Rechte" ist in unserer Logik der, dass für "keine Rechte" gar keine Gruppenzugehörigkeit vorliegen muss. Jetzt müsste ich einem User, der nicht über einen Login in einer Gruppe landet, implizit eine Pseudo-Gruppe ("ALL" oder so) zuordnen, und dann auch immer bei den Rechten schauen, dass die Gruppe "ALL" zugelassen ist, wenn eigentlich gar keine Beschränkung intendiert ist.

Das kommt mir umständlich vor gegenüber der alten FS-Logik.

Herzliche Grüße,

Arndt Bär

[broszeit]

Hallo,

das Ganze scheint tatsächlich ein ähnlicher Bug zu sein.

Ich habe einen Bugreport erstellt. (interne ID #127532)

Viele Grüße

Rouven