Queryopen/Querymodechange --- unter 4.5.7 i.O. und 5 funktioniert`s nicht !

[grisu_stern]

Hallo,

ich habe in einer DB folgendes Script unter dem Event Queryopen:

Sub Queryopen(Source As Notesuidocument, Mode As Integer, Isnewdoc As Variant, Continue As Variant)
     Dim Doc As NotesDocument
     Set doc = Source.Document
     Dim status As String
         
     If Not doc Is Nothing Then
           
          status = Doc.INFO_Status (0)
          If (status = "aktuell" Or status = "Archiv") Then
               
               If Source.EditMode = True Then               
                    Msgbox "Diese Arbeitsanweisung wurde bereits genehmigt." &Chr(10) + _
                    "Sie kann nur zum lesen geöffnet werden!",16, "Hinweis..."
                    Continue = False
               End If     
          End If
     End If
     
End Sub

und im Event Querymodechange:

Sub Querymodechange(Source As Notesuidocument, Continue As Variant)
     
     Dim status As String
     
     status = Source.FieldGetText("INFO_Status")
     
     If (status = "aktuell" Or status ="Archiv") Then
         
          Msgbox "Diese Arbeitsanweisung wurde bereits genehmigt." &Chr(10) + _
          "Sie kann nur zum lesen geöffnet werden !",16, "Hinweis..."
          Continue = False
          Exit Sub
     End If
End Sub

Unter 4.5.7 (OS/2)  funktioniert es super, die Dokumente mit dem angegebenen Status lassen sich nicht verändern.

Jetzt haben wir einige Rechner mit Notes 5, und hier kann man die Dokumente bearbeiten. 

Wie kommt das ?

In 2006 werden wir komplett auf 6.5 migrieren. Wie verhält sich das Problem unter 6.5 ?

Kann mir jemand helfen?

Grüße aus Soest
Tanja

[Axel]

Hi,

guckst du hier: [LotusScript]: EditMode für bestimmte Dokumente verwehren


Axel

[grisu_stern]

Hallo,

danke für den Link Axel.

Meine Frage richtet sich aber v.a. dahin, warum das unter Rel. 5 und 6.5 nicht funktioniert, aber unter 4.5.7 alles i.O. ist.

Das wird mir nämlich aus der ausführlichen Beschreibung nicht deutlich. 

Grüße
Tanja

[Axel]

Hi,

diese Phänomene kenne ich auch, allerdings nicht zwischen verschiedenen Versionen und Betriebssystemen. Ich hatte so eine ähnliche Konstellation auch und immer wieder wurden Möglichkeiten gefunden das Dokument doch im Edit-Modus zu öffnen. Ich habe es damals nicht wasserdicht gebracht. Erst als ich Leser- und Autorenfelder eingesetzt habe, hats sauber funktioniert.

Deshalb mein Rat, verwende nach Möglichkeit Leser- und Autorenfelder.


Axel

[grisu_stern]

Hallo Axel,

danke für Deine Antwort. Leser und Autorenfelder erfüllen leider nicht ganz meine Anforderung. 

Ich möchte die Dokumente für JEDEN User (inkl. Autoren) nicht mehr bearbeitbar haben, wenn Sie aktuell oder archiviert sind. Revisionssicher sozusagen....

Grüße
Tanja

[koehlerbv]

Dieses Verfahren ist aber alles andere als revisionssicher, da es zahlreiche Möglichkeiten der Manipulation offen lässt.

Bernhard

[Semeaphoros]

Jo, revisionssicher geht das definitiv nur über die Zugriffssteuerung, und da lässt sich bei Bedarf auch der Originalverfasser ausschliessen.

[grisu_stern]

Dieses Verfahren ist aber alles andere als revisionssicher, da es zahlreiche Möglichkeiten der Manipulation offen lässt.

Bernhard

Hallo Bernhard,

was ist denn nicht revisionssicher, wenn der normale User keine Agenten und keine Ordner/ Ansichten (auch keine persönlichen!) erstellen kann.  Ein normaler User hat bei uns auch keinerlei Zugriff auf die Design-Elemente.

Grüße
Tanja

[koehlerbv]

Nur ein Beispiel: Die Manipulation muss ja in keiner Weise in Deiner DB programmiert sein, sondern in einer beliebigen anderen. Deine Lösung lässt jedenfalls die DB offen wie ein Scheunentor.

Bernhard

[grisu_stern]

Jo, revisionssicher geht das definitiv nur über die Zugriffssteuerung, und da lässt sich bei Bedarf auch der Originalvervasser ausschliessen.

o.k.

Es geht ganz konkret um unser Orga-HB. Ich mache bei uns im Haus Orga  und Notes Entwicklung.

Revisionssicher definiere ich so, daß außer dem Designer (= ICH + 1 TZ-Student) niemand Dokumente mit dem Status "aktuell" oder "archiviert" bearbeiten kann.

Durch die bereits erwähnten Einschränkungen funktioniert das unter 4.5.7 auch bestens. Mein Problem ist die anstehende Migration auf 6.5 bzw. ca. 15 Rechner, die bereits Notes 5 haben.

Wie könnte es denn konkret im meinem Beispiel mit Autorenfeldern funktionieren? Ich sehe da keine Lösung....

Grüße
Tanja

[Semeaphoros]

Normalzugriff muss Autor sein.

Beim Abspeichern wird das Autorenfeld zum Bleistift auf die Rolle [Admin] gesetzt. Diese Rolle haben diejenigen, die im Notfall an das Dokument rankommen müssen.

[grisu_stern]

Normalzugriff muss Autor sein.

Beim Abspeichern wird das Autorenfeld zum Bleistift auf die Rolle [Admin] gesetzt. Diese Rolle haben diejenigen, die im Notfall an das Dokument rankommen müssen.

Hallo Jens,

es geht weniger um den Notzugriff, den brauch ich nicht unbedingt. Mir geht es um den Status des Dokuments. Wenn der Status = "in Bearbeitung" oder "zur Genehmigung" , dann soll es auch bearbeitbar sein, von allen definierten Usern.

Wenn der Status aber "aktuell" oder "archiviert", dann soll es von niemanden bearbeitbar sein.

Grüße
Tanja

[grisu_stern]

Nur ein Beispiel: Die Manipulation muss ja in keiner Weise in Deiner DB programmiert sein, sondern in einer beliebigen anderen. Deine Lösung lässt jedenfalls die DB offen wie ein Scheunentor.

Bernhard

das sehe ich anders. Die User haben keine Designrechte! Null, selbst ich habe mit meinem User keinen Zugriff darauf. Ich muß mich jedesmal ummelden (Admin-UserID). Das kann man bei uns auch nicht ändern.

Und Agenten können unsere User auch nicht nutzen, die einzige DB in der sie gem. ACL eigene Agenten / Ansichten erstellen könnten ist die Mailbox. Aber ganz ehrlich, das bekommt von unseren MA keiner hin.

Grüße
Tanja

[Semeaphoros]

Tanja, wer lesen kann ......

Das Autorenfeld beim Speichern je nach Status ändern ......


Variante wäre auch, ein berechnetes Autorenfeld zu verwenden.

[Glombi]

Hallo,

danke für den Link Axel.

Meine Frage richtet sich aber v.a. dahin, warum das unter Rel. 5 und 6.5 nicht funktioniert, aber unter 4.5.7 alles i.O. ist.

Das wird mir nämlich aus der ausführlichen Beschreibung nicht deutlich. 

Grüße
Tanja

Hast Du mal den Debugger laufen lassen?

Ich vermute, dass Notes 5 und 6 gar nicht erst in die If Schleife gehen.

Andreas

[koehlerbv]

R4 und R5x behandeln auch das QueryOpen anders. Nicht ohne Grund schreibe ich in meinem BP-Artikel, dass hierfür PostOpen zu verwenden ist.

Tanja, die von Dir geschilderte Sicherheit ist eine Pseudo-Sicherheit. Jeder, der sich mit einem TextEditor eine 2-Bye-Datei mit dem Namen DESIGNER.EXE erstellen kann, hat sofort Zugriff auf den Designer. Und dann ... Notfalls könnte ich ja einem Deiner User eine klitzekliene DB schicken. Bei der muss er dann nur noch einstellen, wo das Orga-Handbuch rumkullert, und auf Knopfdruck sind alle Dokumente vom Status "aktuell" oder "archiviert" wieder "in Bearbeitung". 
By the way: Bei "Zur Genehmigung" dürfen die Autorenrechte nicht die gleichen sein, wie bei "in Bearbeitung" ....

Bernhard

[Semeaphoros]

Genau, Bernhards letzter Satz erläutert meine Anmerkungen noch ein wenig mehr.

[grisu_stern]

Hallo,

ungeachtet der geäußerten Bedenken, hier die Lösung:

In der Eigenschaften der Maske darf ab Version 5 der Haken "Bearbeiten-Modus automatisch aktivieren" nicht gesetzt sein.

Anschließend funktioniert das Script "QueryOpen" und  "QueryModeChange" auch wie unter der Version 4.5.7.

Grüße aus Soest
Tanja Sepke

[koehlerbv]

Revisionssicher sozusagen...

Von der Revisionssicherheit habt Ihr Euch also in den letzten Monaten definitiv getrennt, wenn ich Dein letztes Posting richtig lese? Die Applikation ist mit dieser Änderung nach wie vor offen wie ein Scheunentor ...

Bernhard