Zum Hauptinhalt gehen

Gelocktes Element über API "zwangsweise" entlocken

Zendesk API User

Author: bIT_sosswald
Publication Date: 6/30/2015 8:50

Hallo zusammen,

ist es möglich ein gelocktes Element (PageRef, bzw. PageRefFolder), welches von einem anderen User, in einer anderen Session bzw. einem Workflow gelockt ist per API aus einem Modul zwnagsweise zu "entlocken"?

Dabei wäre es auch akzeptabel wenn evtl. vorgenommene Änderungen verloren gehen.

Grund für die Frage ist, dass wir ein Modul haben welches programmatisch eine Ordner- und Seitenstruktur im Strukturbereich anlegt. Dabei kam es in der Vergangenheit zu Fehlern, da z.B. der Root-Knoten der programmatisch angelegten Struktur gelockt war.

ERROR 20.04.2015 14:31:15.414 (com.xxx.structureupdater.structure.CatalogCreator): Could not create structure.
de.espirit.firstspirit.access.store.templatestore.WorkflowLockException: Element '9882722' is locked by workflow!
     at de.espirit.firstspirit.store.access.DefaultStoreElement._setLock(DefaultStoreElement.java:468)
     at de.espirit.firstspirit.store.access.DefaultStoreElement._setLock(DefaultStoreElement.java:463)
     at de.espirit.firstspirit.store.access.DefaultStoreElement.setLock(DefaultStoreElement.java:440)
     at de.espirit.firstspirit.store.access.DefaultStoreElement.setLock(DefaultStoreElement.java:431)
     at com.xxx.structureupdater.structure.CatalogCreator.createCatalog(CatalogCreator.java:78)

Eine Alternative wäre aus Meiner Sicht die Bearbeitungsrechte des Teilbaums der Struktur so einzuschränken, dass kein User bzw. Workflow diesen Teilbaum bearbeiten darf.

Ideen wie man solche Fehler zukünftig vermeiden kann bzw. wie man Locks zwangweise entfernen kann, sind herzlich willkommen.

Grüße

Sandro

Tags: api, lock, locking

Verknüpfung mit

0

Kommentare

1 Kommentar

Datum Stimmen
  • Zendesk API User
    Author: mbergmann - 8/3/2015 10:22

    Hallo Sandro,

    hier ist es wichtig zu unterscheiden ob es sich um einen Workflow-Lock handelt (entspricht der Einstellung "Schreibschutz" beim entsprechenden Status) oder um einen aktiven Bearbeitungsmodus.

    Deine Meldung zeigt einen Workflow-Lock, der sich übrigens auch nicht durch ein Beenden einer Session entfernen lässt. Außerdem wirken Workflow-Locks immer rekursiv (sie sind allerdings nicht rekursiv gesetzt).

    Einen Workflow-Lock kann man programmatisch entfernen, indem man sich das StoreElement holt, dann zuerst setWriteLock(false) aufruft und dann setLock(true,[true|false]) und ggf. save([true|false]), setLock(false,[true|false]).

    Die Frage ist ob das im Fall von Workflow-Locks wirklich sinnvoll ist, denn der Schreibschutz hat gerade den Sinn, sicherzustellen dass während einer Prüfung (z.B. im Rahmen eines 4-Augen-Workflows) eben keine Änderungen am Objekt möglich sind. Sonst würde ein Prüfer ggf. einen "veralteten" Stand freigeben während in Wirklichkeit ein Redakteur kurz vorher (=nachdem der Prüfer die Seite aufgerufen hat aber bevor er die Freigabe erteilt) noch eine Änderung gemacht hat.

    Einen Lock durch einen aktiven "fremden" (=andere Session, d.h. ggf. auch durch denselben Benutzer) Bearbeitungsmodus kann man lediglich über das Beenden der entsprechenden Session per ServerMonitor entfernen.

    Dein Ansatz das über entsprechende Rechte zu lösen wäre hier eine Lösung.

    Eine vorherige Prüfung ob ein Element gelockt ist, funktioniert übrigens nicht 100%ig, weil theoretisch ein User das Element genau zwischen der Prüfung und dem Locken sperren könnte. D.h. hier ist der Weg der Wahl, das entsprechende Element selber zu locken, die Exception zu fangen (muss man ja sowieso, da CheckedException) und dann z.B. eine Fehlermeldung wie "versuchen Sie es später nochmal" anzuzeigen - also einen "fail fast"-Ansatz zu fahren.

    Viele Grüße

    Michael

    0

Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.

Sie haben nicht gefunden, wonach Sie suchten?

Neuer Post