CMS_INPUT_PERMISSION: Werte via FS-API auslesen

[Freecastle]

Hallo,

ich wollte kürzlich via FS-API die Werte dieser Komponente auslesen, komme aber nicht wirklich weiter.

Dazu folgender Pseudocode:

metaData = pageRef.getMeta(); //Angenommen pageRef ist ein gültiges PageRef-Objekt

perms = metaData.get("roles").getEditor().get(null); //perms ist jetzt ein Objekt der Klasse PermissionsImpl und roles ist der Name der Komponente

Ich nehme an dass "persm" dem Interface Permissions der FS-API entspricht (/help/odfs/access/index.html).

Hier gibt es auch die Methode getAllowed(String). Allerdings weiß ich nicht was es hier für mögliche Werte als Parameter gibt bzw. ich hab sie nicht in der Javadoc gefunden.

Kann mir da jemand weiterhelfen?

[gockel]

Hallo,

von welchem Typ ist der Editor mit dem Variablennamen "roles". Im Titel steht CMS_INPUT_CHECKBOX und im Text sprechen sie von Permission, was nicht zu Checkbox passen würde.

Es geht ja um Metadaten. Können Sie das Formular des Metadatentemplate hier hochladen bzw. die Definition des Editors den sie auslesen wollen und genau beschreiben, von welcher der Eingabekomponenten sie die Daten auslesen wollen.

Gruss

[Freecastle]

Ups sry, da hab ich mich im Titel vertan. Habs editiert.

Hier ist die Formular-Definition der Eingabekomponente:

<CMS_INPUT_PERMISSION name="roles" group="epintegration" hFill="yes">
            <ACTIVITIES>
              <ACTIVITY name="access">
                <LANGINFOS>
                  <LANGINFO lang="*" label="Read"/>
                  <LANGINFO lang="DE" label="Lesen"/>
                </LANGINFOS>
              </ACTIVITY>
            </ACTIVITIES>
            <LANGINFOS>
              <LANGINFO lang="*" label="Access rights" description="Please select the roles that should be allowed to access these folder."/>
              <LANGINFO lang="DE" label="Zugriffsrechte" description="Bitte wählen Sie die Portalrollen aus."/>
            </LANGINFOS>
          </CMS_INPUT_PERMISSION>

[gockel]

O.K.

also geht es um das Auslesen von Daten aus dem PermissionEditorValue. Dessen Persitenztyp ist Permissions und die Methode #getAllowed(String operation) erwartet einen der Aktivitätennamen, den sie im Formular definiert haben.

In Ihrem Fall gibt es nur einen, nämlich "access".

metaData = pageRef.getMeta(); // get meta data
perms = metaData.get("roles").getEditor().get(null);     // no language metadata is language independent
perms.getAllowed("access")

Die Menge der verfügbaren Aktivitätennamen können Sie sich mit #getActivityNames() holen.

Gruss

[Freecastle]

Hi,

danke für die schnelle Hilfe! Es ist tatsächlich so, dass ich über den Aktivitätsnamen an die Berechtigungen komme.

Ich hätte jetzt eigentlich vermutet, dass ich über getAllowed(String), alle Berechtigungen (d.h. auch die vererbten und nicht explitzit gesetzten) bekomme und über getAllowedExplicit(String) nur die am Objekt selbst gesetzten Berechtigungen. Dies scheint aber nicht der Fall zu sein, denn ich kriege bei beiden Methoden nur die explizit gesetzten Berechtigungen.

Gibt es da noch eine API-Methode um relativ einfach auch an die vererbten Berechtigungen zu kommen, oder muss ich diese manuell durch Hochtraversieren im Baum holen?

[gockel]

Ich hätte jetzt eigentlich vermutet, dass ich über getAllowed(String),  alle Berechtigungen (d.h. auch die vererbten und nicht explitzit  gesetzten) bekomme und über getAllowedExplicit(String) nur die am Objekt  selbst gesetzten Berechtigungen. Dies scheint aber nicht der Fall zu  sein, denn ich kriege bei beiden Methoden nur die explizit gesetzten  Berechtigungen.

Es ist so, dass sich die Methoden #getAllowed(String) und #getAllowedExplicit(String) nur auf die Vererbungshierachie innerhalb der Komponente beziehen und nicht auf die Vererbung der Metadaten.

Ein Beispiel:

In diesem Fall liefert:

#getAllowed("zwei"): Die IDs sowohl von "Anonyme Besucher", als auch von dem vererbten Wert von "1. anonyme Besuchergruppe"

#getAllowedExplicit("zwei"): Nur die ID von "Anonyme Besucher"

[Freecastle]

Ok, vielen dank für die ausführliche Erklärung!

D.h. aber dann auch, dass ich manuell nach oben traversieren muss um an die vererbten Berechtigungen zu kommen oder?

[Freecastle]

Hi,

nochmal wegen den vererbten Berechtigungen. Ich habs jetzt genauso mit dem Back-Traversieren implementiert, und es scheint auch gut zu funktionieren. Obs eine bessere bzw. elegantere Lösung gibt weiß ich nicht.

Hier der Code, falls es jemanden interessiert (ist aber noch nicht zu 100% getestet, war eher auf die Schnelle):

String getRoles(StoreElement node, String defaultVal) {
    StringBuffer result = new StringBuffer();
    
    metaData = node.getMeta();
    perms = metaData.get("roles").getEditor().get(null);
    roles = perms.getAllowedExplicit("access");

    if (roles != null && roles.size() > 0) {
        //Do nothing, roles contains now the Set with the allowed roles
    } else {
        parent = node.getParent();
        int limit = 10; //Just to prevent the while loop from running infinite (who knows what can happen 🙂
        int cnt   = 0; //We have anyway an maxium sitestore tree depth of 7
        while (parent != null) {
            metaData = parent.getMeta();
            perms = metaData.get("roles").getEditor().get(null);
            roles = perms.getAllowedExplicit("access");
            
            if (roles != null && roles.size() > 0) {
                //roles contains now the Set with the allowed roles
                break;
            }
            
            cnt++;
            if (cnt > limit) {
                break;
            }
            
            parent = parent.getParent();
        }
    }
    
    if (roles != null && roles.size() > 0) {
        cnt = 0;
        for (iter = roles.iterator(); iter.hasNext();) {
            if (cnt > 0) {
                result.append(",");
            }
            String role = iter.next();
            result.append(role.substring("/epintegration".length()+1));
            cnt++;
        }
        return result.toString();
    } else {
        return defaultVal;
    }
}

[gockel · Accepted solution]

Bei der Prüfung der Metadaten sollte allein schon aus Performancegründen zunächst geprüft werden, ob an dem jeweiligen Knoten Metadaten gesetzt sind. Hierzu gibt es in IDProvider die Methode #hasMeta(). Wenn man sich die Metadaten über #getMeta() holt von einem Knoten, an dem Sie nicht gesetzt waren, erhält man ein ein leeres MetaData Objekt, welches dann auch Rückgriffwerte aus dem Template enthält. Das wäre in Ihrem Fall aber nicht gewünscht denke ich.

[Freecastle]

Stimmt, danke für den Tipp.