Benötigte "Rechte" um Dokumentsperrung aufzuheben

    Hallo,


    ich habe eine Datenbank bei der wir die Dokumentsperrung aktiviert haben. Funktioniert prinzipiell prächtig. Leider gibt es immer mal wieder Fälle wo die Sperrung einzelner Dokumente nicht wieder aufgehoben wird.
    Ich als DB Manager kann diese Dokumente problemlos entsperren.
    Nun haben wir eine Kolleging die diese Datenbank ab sofort sauber halten soll. Ich habe Ihr Editor Rechte (zum testen auch mal Entwickler) geben. Auch das Recht Dokumente zu löschen habe ich Ihr gegeben.
    Wenn Sie nun versucht ein Dokument eines anderen zu entsperren, kommt eine Messagebox: "Das Dokument wurde von XY gesperrt". Außerdem muss Sie Dokumente die Sie löschen will nun immer erst händisch sperren.


    Wie kann ich das umgehen bzw. Ihr die Möglichkeit geben Dokumente von anderen zu entsperren ?


    gruß
    Joerg

    Domino Server 8.0.2 mit BES / Clients 7.0.* und 8.0.2 Basic
    Test: Domino 8.5 (linux) mit ASSP und 8.5er Client

    Hmm sry ... aber Danke trotzdem :oops:


    Gruß
    Joerg

    Domino Server 8.0.2 mit BES / Clients 7.0.* und 8.0.2 Basic
    Test: Domino 8.5 (linux) mit ASSP und 8.5er Client

    Hallo,


    ich habe dieses Problem genau umgekehrt.
    Selbst ein Autor, der in keinem Autorenfeld auftaucht, kann ein Dokument entsperren.
    Dies macht er bequem von der Ansicht aus über das Kontextmenü -> entsperren.


    Das $Writers Feld ist dann gelöscht.
    Das Verhalten habe ich auf 7er und 8.5er Servern.


    Ich hätte auch gerne das Verhalte, dass dies nur Manager dürfen, bekomme dies aber auf keinen unserer Server hin.


    Kennt jemand die Ursache?


    Gruß, Dennis

    Hallo taurec,


    ja, bin ganz sicher, ich habe dies auf 3 Servern (7.0, 8.5) mit verschiedenen DB und mit 2 verschiedenen Usern als Autoren, sowie unter dem 7er und 8er Client getestet.
    Nur ich und der Server sind Manager in den ACL der jeweiligen DB.


    Der jeweilige Benutzer (Autor) konnte das Dokument nach der Entsperrung auch nie bearbeiten.
    Eine Sperre setzen ist ihm auch unmöglich.
    Wie schon gesagt ist dann jedoch das Feld $Writers entfernt worden.


    Ich habe es auch schon mit einem Autorenfeld probiert, in dem der Benutzer(Autor) nicht enthalten ist, nur ich.
    Er kann dennoch, während ich das Dokument bearbeite, das Dokument entsperren und ich laufe dann bei der Speicherung auf einen Speicherkonflikt.
    Eine Bearbeitung ist ihm, wie erwartet, wieder nicht möglich.


    Gruß, Dennis

    Das deutet aber dann eher auf eine andere Art des Lockings hin.


    Bist du sicher daß es dabei wirklich um den gleichen Lockingmechanimus geht wie der vorher angesprochene ?


    Denn das normale Soft Locking schreibt meines Wissens nach keine Felder in das Dokument.

    Zitat

    ich habe eine Datenbank bei der wir die Dokumentsperrung aktiviert haben


    Ich gehe davon aus, das wir das Selbe meinen.


    Das Locking habe ich aktiviert indem ich in den Eigenschaften der DB "Datenbank allgemein" die Option "Sperren von Dokumenten zulassen" aktiviert habe.


    Das Softlock schreibt keine Felder richtig, sobald ich die Option ("Sperren von Dokumenten zulassen" ) aktiviert habe schreibt er schon beim Wechsel in den Bearbeiten-Modus 2 neue Felder
    $Writers
    enthält alle Lock Holder
    $WritersDate
    Enthält das Datum wann der Lock gesetzt wurde


    Sobald das Dokument verlassen wird, werden die Felder entfernt.


    Außer man macht per Script einen Lock. Der bleibt dann, sieht genauso aus, aber auch diesen kann jeder Autor (ohne im Autorenfeld zu stehen) entsperren.


    Das Dokument gilt nicht als geändert, und es wird niemand ins $UpdatedBy geschrieben.


    Sobald die Sperre entfernt wurde (egal von wem) kann jeder das Dokument editieren, der die Berechtigung dazu hat, obwohl ich es noch im Bearbeiten-Modus offen habe!
    Softlock wirkt da nicht mehr. Ich nehme an, in dem Locking-Modus der DB wird nur das $Writers Feld genutzt.


    P.S. Mit Leseberechtigung kann der Lock nicht entfernt werden.
    Das geht erst ab Autor, selbst ohne Erstellungs- und Löschrechte.