Dokumente mit Leserfeld bleiben in lokaler Replik verschwunden

[NilsLHH]

Hallo liebe Experten,

wir haben da ein merwürdiges Problem mit Leserfeldern in lokalen Repliken.
Vielleicht stehen ich und unser Notes-Administrator auch nur auf dem Schlauch.

Das Szenario ist wie folgt:

Der Kunde wünscht, dass in dem zusätzlichen Adressbuch, das wir ihm zur Verfügung stellen, bestimmte Verteilergruppen nur für bestimmte Benutzer sichtbar sind.

Das Adressbuch basiert auf "StdR4PersonalAddressBook Version 8.02". Es gibt eine Editor-Gruppe, die alle Kontakte und Gruppen pflegen kann; diese hat u.a. auch die Rollen [GroupCreator] und [GroupModifier]. Dann gibt es die Gruppe der "normalen" Benutzer, die nur Autor-Zugriff haben und die Rechte Dokumente erstellen, Öffentl. Dokumente schreiben und Dokumente replizieren und kopieren haben. Ausser dem standardmäßigen DocumentAccess-Autorenfeld (welches nur die o.g. Rollen setzt) existieren bisher keine Leser-/Autorenfelder.
Die Benutzer arbeiten in der Regel mit lokalen Repliken, weil kein ständiger Netzwerkzugang möglich ist (Laptops)

Um nun das Ausblenden der Verteilergruppen zu realisieren, habe ich zwei Leserfelder in der Gruppen-Maske hinzugefügt. Das eine berechnet mit der Formel

@If(ZugriffLeser != "";"LocalDomainServers":"[Manager]":"[GroupCreator]":"[GroupModifier]";"")

um die Dokumente immer für die Server,Manager und Editoren offen zu halten.

In das ZugriffLeser-Feld können dann von den Editoren die Benutzer und Gruppen eingefügt werden, die die Verteilegruppen sehen sollen. Standardmäßig bleibt diese Feld leer, das Dokument ist also für alle sichtbar.

Trägt man nun jemand in das ZugriffLeser-Feld ein und repliziert die lokale Replik eines Benutzers, der das Dokument nicht mehr lesen darf, verschwindet das Dokument auch wie erwartet. Umgekehrt kann er es auch sehen, wenn er im Leserfeld steht. Soweit tippi toppi dank konsistenter ACL.

Aber nun kommt das Problem:

Ändert ein Editor in der Server-Replik das Leserfeld des oben ausgeblendeten Gruppen-Dokuments, so dass es leer ist oder der betreffende Benutzer wieder drin steht, erscheint es in der lokalen Replik nicht wieder.

Löscht man die lokale Replik und legt sie neu an, ist das Dokument wieder sichtbar; was aber für die Benutzer nicht praktikabel wäre.

Das Dokument kann so quasi nur einmal verborgen/entfernt werden und danach wird es lokal nie wieder erscheinen.

Nach einer Untersuchung mit NotesPeek konnte man sehen, dass für das "ausgeblendete" Dokument anscheindend ein DeletionStub in der lokalen Replik angelegt wird. In der Anzahl der Dokumente wird es auch nicht mehr gezählt.

Das "Ausblenden" funktioniert - nach ausgiebiger Recherche hier im Forum - auch wie erwartet, nur das "Wiedereinblenden" eben nicht.

Als Workaround hatte ich es erstmal so gelöst, dass bei Änderungen an dem Leserfeld, das Gruppen-Dokument kopiert wird und das bisherige Dokument sofort gelöscht wird. Nicht schön, aber so erscheint es dank neuer ID in der lokalen Replik wieder.


Ist dies ein generelles Problem bei Leserfeldern und lokalen Repliken oder gibt es irgendetwas, was wir übersehen haben ?

Zur Vollständigkeit halber sei noch gesagt, dass das Document-Locking auf der Datenbank aktiviert ist, aber das dürfte ja eigentlich keine Auswirkungen haben.

[Peter Klett]

Habe es gerade getestet. Ein generelles Problem dieser Art mit Leserfeldern kann es nicht sein.

1. Dokument auf dem Server mit Leserrechten für mich, lokal repliziert, Dokument ist da.
2. Leserfeld auf dem Server geändert, dass ich es nicht mehr sehen darf, repliziert, Dokument ist lokal nicht sichtbar
3. Leserfeld auf dem Server wieder micheingetragen, repliziert, Dokument ist da

Alles so, wie es sein soll. Dass Deletion-Stubs vorhanden sind, ist m.E. völlig richtig. Getestet gerade unter 8.5.3, aber das funktionierte so auch schon unter 4, würde mich sehr wundern, wenn es ausgerechnet unter 8.0.2 nicht funktionieren sollte.

Einen Lösungsansatz für Dich habe ich leider nicht. Ich würde mal die Uhrzeiten zwischen Client und Server vergleichen, wenn der Client in der Zukunft des Servers arbeitet, wäre so etwas vorstellbar. Mehr fällt mir dazu im Moment leider nicht ein.

[NilsLHH]

Im Vergleich der Uhrzeiten auf Domino-Server und dem Test-Laptop gab es tatsächlich eine kleine Abweichung, aber maximal im Sekundenbereich.

Die Systemzeit sollte eigentlich auch durch die Active Directory Domain Controller synchron gehalten werden. Ich hab dies über net time noch mal manuell angleichen lassen.

Es bringt jedoch keine Verbesserung. Bei 3. bleibt das Dokument verschwunden.

[Tode]

Habe es gerade ebenfalls mal nachvollzogen, und Notes arbeitet hier zwar nachvollziehbar aber "Suboptimal":

1. Du änderst das Dokument, so dass der Benutzer nicht mehr im Leserfeld steht
FOLGE: Das Dokument bekommt ein Änderungsflag, bei der nächsten Replikation wird es aus der Lokalen Datenbank entfernt, ein "Deletion- Stub- Stub" wird erstellt (enthält nur den Bruchteil eines echten Deletionstubs, wahrscheinlich um das versehentliche Replizieren der Deletion zu vermeiden)

2. Jetzt gibt es zwei Möglichkeiten, wie Du das Dokument wieder sichtbar machst für den User:
a) Du änderst das Dokument erneut und trägst den Benutzer wieder ein
FOLGE: Dokument erhält Änderungsflag und wird bei der nächsten Replikation auch bei dem Benutzer wieder hinzugefügt (weil Änderungsdatum > letztes Replikationsdatum

b) Du gibst dem Benutzer anderweitig Zugriff aufs Dokument (indem Du Ihm per ACL eine Rolle zuweist oder Ihn in eine Gruppe einträgst):
FOLGE: Der Benutzer sieht zwar das Dokument auf der Server- Replik wieder, es wird aber NICHT lokal repliziert, WEIL: Das letzte Änderungsdatum des Dokuments ist ja älter als die letzte Replikation.
Wenn Du jetzt das Replizierprotokoll auf Lokal löschst, dann kommt das Dokument natürlich wieder. Wenn Du das Dokument selbst auf dem Server änderst ebenfalls....

Das hiesse, dass das erneute speichern der Dokumente schon reichen müsste, um sie wieder nach lokal zu replizieren.

Das sind meine Beobachtungen. Stimmen die mit Deinen überein?

[NilsLHH]

Dein 1. funktioniert auch wunderbar und wie erwartet.

Ich leere dann entweder das Leserfeld auf der Server-Replik oder trage dort halt den Test-Benutzer ein. Ergo: das Dokument ist aktueller als in der lokalen Replik und der Testbenutzer hat Leserecht (entweder über "alle" bei leerem Leserfeld oder über sich selbst).

Das Ändern in der ACL bzw. in den Gruppenmitgliedschaften ist ja wieder ein anderes Thema, was hier im Forum auch schon diskutiert wurde. Das trifft bei uns aber so nicht zu bzw. nur selten, weil die ACL bzw. Gruppenmitgliedschaften nur selten geändert werden. Hier sollen nur die Editoren den Zugriff über das Leserfeld steuern.

Wenn Du jetzt das Replizierprotokoll auf Lokal löschst, dann kommt das Dokument natürlich wieder. Wenn Du das Dokument selbst auf dem Server änderst ebenfalls....

Mit einer neuen lokalen Replik funktioniert es dann auch wieder.

Es scheint entweder an der 8.0.2er-Version zu liegen oder an dem Deletion Stub des "ausgeblendeten" Dokuments.

[Axel Lünse]

Vom Admin-Auf-dem-Schlauch  :

Wir haben soeben einen weiteren Test durchgeführt und zwar mit einem 8.5.3 Client gegen den selben Server und die selbe DB mit dem von Nils eingangs beschriebenen Problem.

Der 8.5er Client kommt damit eindeutig besser zurecht, beim Empfangen von gesperrten Dokumenten auf der lokalen Replik weist er diese als Löschungen aus, die Dokumente sind dann natürlich für den Benutzer nicht mehr sichtbar.

Entsperrt man ein entsprechendes Dokument, wird dies bei der Replizierung gegen die lokale Replik als Update empfangen, das Dokument steht dann wieder quasi ohne weiteren Eingriff auch ind er lokalen Replik zur Verfügung.

Ob das nun ein einzigartiges Feature von 8.0.2 ist und vorher nicht bestand oder mit 8.5 das Handling von "Read-Access-Soft-Deletions" in lokalen Repliken optimiert wurde erschließt sich mir noch nicht, ist für den Moment aber auch nebensächlich.

Danke für die Ideen und Beiträge bisher
Grüße
Axel

[NilsLHH]

Das ist wieder mal typisch Lotus Notes. Genau in einer Version klappt es nicht.

Solange nicht alle Clients auf 8.5 umgestellt sind, braucht man zwar weiter den Workaround, aber zumindest steht eine "normale" Lösung in der Zukunft bereit.

Wer den recht trivialen Code des Workarounds haben möchte, kurze Anfrage per PM.

Vielen Dank an alle bei der Lösungssuche.