Questions & Answers

[Thomas_Hagenloc]

Hallo zusammen,

ist es möglich per Regeln zu sagen, dass in Abhängigkeit der Sprache des Redakteurs einen bestimmten Sprachreiter editierbar / nicht editierbar zu machen?

Beispiel:

Ein deutscher Redakteur darf nur den deutschen Inhalt bearbeiten. Er darf zwar die anderen Sprachreiter anklicken und sehen, allerdings nicht editieren.

Ein englischer Redakteur darf nur den englischen Inhalt bearbeiten. Er darf zwar die anderen Sprachreiter anklicken und sehen, allerdings nicht editieren.

usw.

Im Prinzip müsste man ja per IF-Bedingung so etwas machen:

<IF>
  <EQUAL>
  <PROPERTY source="#global" name="LANG"/>
  <TEXT>DE</TEXT>
  </EQUAL>
</IF>

Und nun müsste <TEXT>DE</TEXT> durch die Sprache des Redakteurs ersetzt werden. Diese ergibt sich z.B. aus der Gruppe, in der sich der Redakteur befindet.

Ginge es z.B. wenn man eine Gruppe DE erstellt und dann mit <IN_GROUP name="DE"/> prüft, ob Sprachtab und Gruppe gleich sind. Wenn ja, werden alle Felder editierbar?

Gibt es andere Alternativen?

Viele Grüße

Thomas

[StefanSchulz]

Hallo Thomas,

das sollte auf diesem Weg schon gehen, würde aber abhängig ovn der Anzahl an Sprachen eine ziemlich Fette Regel werden, die dann auch auf alle Eingabekomponenten angewendet werden müsste. Das könnte man eventuell mit einem versteckten Schalter (CmsInputToggle oder ähnliches) ein wenig optimieren. Und man sollte sicherstellen, dass die Regel nur ein Mal ausgeführt wird. In 5.2 gibt es für die einmalige Ausführung einen Parameter, unter 5.1 müsste man die Information im IF eventuell mit dem Schalter verbinden.

Leider fällt mir da auch keine praktischere Lösung ein, vielleicht liest ja noch jemand mit anderer Idee hier mit.

Beste Grüße

Stefan

[Thomas_Hagenloc]

Hallo Stefan,

danke für die Antwort.

Ja, das wird eine ziemlich ziemlich dicke Regel, da es irgendwann ca. 30 - 40 Sprachen und ca. 30 Formularelemente sein werden.

Wäre es performanter, wenn man das Ein- und Ausblenden über ein Skript lösen würde? Die Regel ruft dann nur das Skript auf.

Wie würdest du das mit dem Schalter implementieren? Also was genau macht der Schalter?

Viele Grüße

Thomas

[StefanSchulz]

Hi Thomas,

ob das per Skript leistungsfähiger wird, kann ich nicht beurteilen. Das Problem ist eher, dass die Regel potentiell sehr oft aufgerufen wird. Die Prüfung auf Gruppenzugehörigkeit kann je nach Anbindung ein wenig langsam werden.

Die Idee mit dem Schalter: Die IF-Regel prüft, ob der Schalter bereits gesetzt wurde (Null-Test, für die Einmaligkeit). Im WITH-Teil ermittelt die Regel dann, ob der aktuelle Benutzer die aktuelle Sprache bearbeiten darf. Im DO-Teil wird dann der Schalter und die Editierbarkeit aller Eingabekomponenten gesetzt (Boolean-Wert).

Habe ich nicht ausprobiert, sollte aber so gehen.

Beste Grüße

Stefan

[mbergmann]

Hallo Thomas,

vielleicht funktioniert folgender etwas schlankerer Ansatz (nicht getestet!):

Implementierung eines ValueServices, dem die aktuelle Sprache als Parameter mitgegeben wird:

 <RULE when="ONLOCK">
      <SCHEDULE service="EditorLanguagePermission" id="editorPerm">
          <PARAM name="lang">
              <PROPERTY source="#global" name="LANG"/>
          </PARAM>
      </SCHEDULE>
      <DO>
          <PROPERTY source="st_headline" name="EDITABLE"/>
          <PROPERTY source="st_text" name="EDITABLE"/>
          ...
       </DO>
</RULE>

Im Rahmen des ValueService dann über den UserAgent den Benutzer holen und ggf. dessen Gruppen. Letztlich gemäß eigener Logik ein Boolean ermitteln, das zurückgegeben wird und die Editierbarkeit bestimmt.

Hier ist allerdings zu beachten, dass meines Wissens solche "nicht-editierbar"-Regeln für InEdit nicht greifen sondern nur in der Formularansicht.

Viele Grüße

Michael

[Thomas_Hagenloc]

Hallo Michael,

bekomme ich im ValueService den Benutzer auch, wenn das Formular im ContentCreator geöffnet wird, oder wird da der SYSTEM-Benutzer zurückgegeben?

Wenn es der SYSTEM-Benutzer ist, wie komme ich in diesem Fall an den tatsächlichen Benutzer?

Viele Grüße

Thomas

[mbergmann]

Hallo Thomas,

ich habe es nicht getestet, würde aber schon denken dass Du hier über den UserAgent an den jeweiligen Benutzer kommst. Um sicher zu gehen, könntest Du das vorab mit einem minimalen ValueService (=ohne das restliche Konstrukt) testen, der z.B. einfach den Benutzernamen zurückgibt und in ein INPUT_TEXT schreibt.

Viele Grüße

Michael

[marza]

Hallo Thomas,

benötigst Du noch weitere Hilfe oder haben Dir die Antworten von Stefan und Michael bereits geholfen?

In diesem Fall wäre es super, wenn Du die "richtige Antwort" entsprechend markierst, damit auch andere Community-Teilnehmer diese auf den ersten Blick finden. Solltest Du zwischenzeitlich eine eigene Lösung gefunden haben, wäre es nett, wenn Du diese hier bereitstellst.

Viele Grüße

Marian

[Thomas_Hagenloc]

Hallo Marian,

in diesem Fall haben sich die Kundenanforderungen einfach geändert. Daher habe ich das Thema nicht weiter verfolgt.

Die Ansätze von Stefan und Michael sind sicherlich sehr hilfreich, stellen für mich jedoch keine "richtige Antwort" im Sinne einer tatsächlichen Lösung dar.

Ich ändere den Status des Tickets in "wahrscheinlich beantwortet".

Viele Grüße

Thomas