Autorenfelder und das Notes Standardlocking

[Johnson]

Hallöchen,

ich hab grad ´n ziemlichen Müll entdeckt.

Ich habe eine Datenbank, in der alle Benutzer (außer meiner Wenigkeit) Autoren sind (ACL). Die Berechtigung ein Dokument bearbeiten zukönnen, wird über Autorenfelder geregelt. Alles soweit wunderbar.

Öffnet ein Benutzer ein Dokument, das er bearbeiten kann, weil er in einem von vielen Autorenfeldern explizit, mittels Gruppe oder Rolle eingetragen ist, soll das Dokument automatisch im Bearbeitenmodus geöffnet werden:

Code

Sub Postopen(Source As Notesuidocument)
	If source.InPreviewPane = False And source.EditMode = False Then
		source.EditMode = True
	End If
End Sub

So... jetzt kommt´s:
Karl Heinz hat nur Leseberechtigung (steht in keinem Autorenfeld) im Dokument, das er öffnet. source.EditMode = True zieht nicht.
August Müller hat Autorenberechtigung (steht in einem Autorenfeld).

Document is currently locked by Karl Heinz ....

Karl Heinz HAT DOCH ÜBERHAUPT KEINE RECHTE DAS DING ZU BEARBEITEN und tut´s auch nicht.

Ich wollte verhindern jedes mögliche Autorenfeld nach Rollen, Guppen und deren Untergruppen zu durchsuchen.
Ein Schließen und dann nur im Lesemodus öffnen kann u.U. lange daurern, da sich eine eingebettete Ansicht im Dokument befindet.

Hat jemand eine smarte Idee oder ein Workaround?


Gruß und Danke für´s Zuhören
Johnson

[Christian Huber]

Du wirst aber über Deine vorgeschlagene Methodik (alle Items durchscannen hinsichtlich
Autorenfelder) nicht umhinkommen.

Ich verwende das generell als Standardroutine im postopen.

GGfls. kann es bei einem <Nurleser> erforderlich sein, im postopen noch ein "SaveOptions=0" zu setzen, damit beim Schliessen des Dokumentes nicht eine Sicherheitsabfrage wegen dem
Speichern (was sowieso nicht ginge) kommt.

bye
Christian

[koehlerbv]

@"Johnson":
Das Document locking ist ein Versuch von IBM Lotus, auf zwar verständliche, aber einfach in einer immer möglicherweise per se verteilten Umgebung nicht umsetzbare Anwenderwünsche einzugehen. Ich weiss jetzt nicht, mit welcher 6er Version Du arbeitest, aber
- Notes und document locking ist ein Widerspruch in sich
- es gab zudem immer weider einzelne Bugs in unterschiedlichen Versionen von R6 (siehe KBase bzw. Fixlist).

Genauso, wie es eine "philosophische Frage" ist, ob man in einer verteilten Architektur überhaupt ein document locking bewerkstelligen kann, ist es ebenso philosophisch, in welchem Status ein Dokument "gesperrt" ist. Man kann es ja durchaus so sehen: User A (Rechte egal, Hauptsache, er kann das Dokument überhaupt sehen) öffnet ein Dokument. Es kann dann nicht sein, dass User B währenddessen das Dokument verändern darf.

Wie gesagt, die Fragestellung "locking" ist "philosopisch": In vielen relationalen DBs darf besipielsweise der Preis eines Artikels nicht verändert werden, wenn irgendjemand dieses Artikel ( mit dem aktuellen Preis) gerade betrachtet. Könnte ja verheerend sein ...

Das Ganze kannn nur als architektonisches Problem betrachtet werden. Ich scheue daher das ab ND6 angebotene document locking wie der Teufgwl das Weihwasser ...

@Christian:
Deartiges Scanning der Rechte der User an einem bestimmten Dokument kann doch auch erreicht werden, ohne dass man sämtliche Autoren- und Leserfelder scannt (so man das überhaupt kann). Für das Locking à la R6 nützt es einem sowieso nix - siehe dieses Posting von "Johnson".

Aber das wäre (durchaus !!!) einen eigenen Thread oder auch einen wirklich BP-Artikel wert. Wärest Du interessiert ?

Bernhard

[Christian Huber]

@Bernhard

Ich habe den Thread hier eher nicht unter dem Hauptaspekt "Locking" betrachtet, wie er
in einer vernünftigen Datenbank gemacht wird, sondern eher unter dem Gesichtspunkt,
ob ein Anwender überhaupt editieren darf oder nicht.

ND6-Locking verwende ich nicht, meine Standardroutinen bilden das ab R5 nach.
Da die Offline-Thematik vernünftiges Locking sowieso nicht zulässt, habe ich das Ganze
mit einem Merging von Replikationskonflikten gelöst.

Will heissen.

Falls direkt connected an Server -> Lock wird verwendet -> Message an 2.ten User, der ein
Dokument in Bearbeitung nehmen will und Sperre. Wenn der 1.Anwender fertig ist, wird
automatisch ein Mail an den anderen gesendet ("Bin fertig").

Falls nicht connected -> 2 User machen Änderungen am selben Dokument -> Mischen
funkt nicht -> Repl.Konflikt -> Taucht in Adminansicht auf -> Manueller Mischvorgang
möglich mit Benachrichtigung aller Beteiligten. Oder Admin kann Rule (nicht Notes Rule)
definieren, wie solche Repl. Konflikte in Zukunft automatisch behandelt werden sollen
(Zugegebenerweise keine hohe Trefferquote, aber ein Ansatz)

Klingt auf ersten Blick etwas aufwändig und ist es auch (was die Rules anbelangt).
Hatte aber sehr viele Probleme nicht etwa mit unterschiedlichen Usern, aber im
Zusammenspiel mit vielen Agenten, die hier parallel z.B. Statistikfelder füllen.

Die Wahrscheinlichkeit, dass 2 User dasselbe Dokumente gleichzeitig bearbeiten möchten,
ist sehr viel geringer als die Wahrscheinlichkeit, dass periodische Agenten, die tagsüber
laufen, in Kollision mit einem Anwender kommen.

Leserfelder scanne ich generell nicht, warum auch. Wenn ein Leserfeld drinnen steht, dass
mich ausschliesst, komme ich doch gar nicht an das Dokument ran oder sehe ich das falsch ?

Und warum reichen die Autorenfelder nicht aus für den Schreibzugriff ? Gut, die Prüfung,
ob ich das Dokument selbst erstellt habe ($UpdatedBy) und danach niemand anders
verändert, hab ich hier vergessen.

Bin immer interessiert an etwas, wo ein Fehler in meinen Routinen aufgedeckt werden kann.

bye
Christian

[Johnson]

*Gong* Ende Runde 1. 

Was diesen einfachen Versuch betrifft: absolut richtig.
Rein philosophisch bietet Notes über NotesDocument.Lock bzw. NotesDocument.LockProvisional und NotesDocument.LockHolders für den Entwickler eine Möglichkeit sich dem Thema selbst anzunehmen und auch nur unter der Prämisse, das es in den Datenbankeigenschaften aktiviert wurde. Das funktioniert auch nur richtig, wenn es keine Replik gibt und schon gar kein Cluster (wie bei uns).
Zusätzlich gibt es aber ein Locking das vom Server verwaltet wird und das nur durch einen ini-Parameter serverweit und nicht datenbankweit deaktiviert werden kann. Falls es jetzt im laufenden Betrieb ausgeschlatet wird knallt´s wie an Silvester in Paris. Calls, Replizierkonflikte und alles.
Prinzipell kommt es auch äußerst selten vor, das ein Benutzer das Dokument ließt, in den Editiermodus will aber es ihm nicht gestattet ist und gleichzeitig ein anderer Benutzer Sekunden später das Dokument bearbeitet will weil er es darf. (Rein philosophis!)
Rein technisch ist die Möglichkeit einer solchen Situation aber gegeben und äußerst unschön, da man als Entwickler nicht darauf reagieren kann. Wann eine solche Funktion aber den Zustand eines Dokumentes und meine Berechtigungen darauf prüfen soll ist noch lange nicht so egal wie die Verwendung von Not(=) und <>. Tatsache ist, daß das automatische Locking serverseitig es gar nicht interessiert, ob der Benutzer mit Authorenrechte oder nur Leserechte besitzt. Es wird unter allen Umständen gelockt. Komme was wolle.

Fuback!!!