Repliken über Gruppenberechtigungen

[Trash]

Hallo,

ich habe ein Problem, dass ich unglücklicherweise hier http://atnotes.de/index.php/topic,13446.msg367272.html#msg367272 schon mal im völlig falschen Forum gepostet hatte, weil die Fehlerbeschreibung dort gut zu meinem Problem passte.

Folgende Situation:
Ich habe in Notes-Dokumenten in verschiedenen Datenbanken Leser-Felder in die berechtigte Gruppen eingetragen sind. Ein Agent ermittelt zyklisch, wer Zugriff auf Dokumente benötigt und bestückt die Gruppen daraufhin mit den Namen der Mitarbeiter. An den Dokumenten selbst findet dabei keine Änderung statt.

Das funktioniert online auch ganz gut, spätestens nach Neuanmeldung ziehen die Berechtigungen wie gewünscht und die entsprechenden Dokumente werden angezeigt.

Die Replizierung bekommt aber offensichtlich die neuen Rechte überhaupt nicht mit. Sie ist in wenigen Sekunden fertig und findet dabei keins der neu berechtigten Dokumente.

Auch die Änderung eines der betroffenen Dokumente führt nur manchmal (gefühlt nur jedes zweite Mal) zur Replikation. In anderen Fällen sieht es so aus, als würde die Replikation die neu berechtigten Dokumente gar nicht sehen.

Wenn ich die Replizierhistorie lösche, funktioniert alles wie gewünscht, dann habe ich aber leider sehr lange Laufzeiten.

Hat vielleicht jemand Ideen dazu? Kann man den lokalen "Berechtigungs-snapshot" irgendwie zum Neuaufbau zwingen?

Danke
Jens

[klaussal]

Wenn ich das richtig verstehe, ändert der Agent die Gruppen in der names.nsf

Da in den eigentlichen Dokumenten ja nichts geändert wird, warum sollte also repliziert werden  

[Klafu]

Die Datenbank mit den Dokumenten, die der Anwender mal sehen können soll und mal nicht, ist demnach aber eine lokale Datenbank, oder?

Chris

[klaussal]

....ist demnach aber eine lokale Datenbank, oder?

So habe ich das auch verstanden.

[Peter Klett]

Wenn ich das richtig verstehe, ändert der Agent die Gruppen in der names.nsf

Da in den eigentlichen Dokumenten ja nichts geändert wird, warum sollte also repliziert werden  

Es muss deshalb repliziert werden, da sich durch die Änderung der Gruppenmitglieder die Leseberechtigungen auf die Dokumente ändern.

Der User kann bestimmte Dokumente lesen, weil er in der Gruppe Mitglied ist, die im Leserfeld eingetragen ist. Er hat eine lokale Replik der Datenbank. Nun wird die Gruppe geändert, der User fliegt aus der Gruppe, und darf danach natürlich die Dokumente nicht mehr lesen. Bei der Replikation müssten die relevanten Dokumente in der lokalen Replik gelöscht werden, da sie auf dem Server vom User nicht gelesen werden können. Das scheint aber nicht der Fall zu sein. Gleiches gilt umgekehrt nach Einräumung der Rechte.

Zur Lösung kann ich leider nichts beitragen, das Problem ist mir bisher noch nicht aufgefallen, aber ich kann erklären, was Jens meint

[Tode]

Ja, ich verstehe das Problem, und es ist tatsächlich essentiell... Im Prinzip müsste man der Datenbank sagen "mach mal einen vollständigen Abgleich". Das kann man ja, indem man das Replizierprotokoll löscht, dann würden wahrscheinlich auch die nicht geänderten Dokumente hin / wegrepliziert.

Problem bei der Sache: Das Protokoll muss bei JEDEM Mitarbeiter lokal gelöscht werden, ein Löschen des Serverprofils reicht nicht aus....

Wow... das ist ne sehr gute Frage, aber ich fürchte mit Notes- Bordmitteln ist das nicht zu realisieren, weil die Replikation mit Timestamps arbeitet: Einmal die "letzte Änderung" des Dokuments, einmal die "letzte Replikation"...und so lange der zweite Wert grösser ist als der erste (der sich durch Änderungen der Gruppenmitgliedschaften ja nicht ändert) wird schlicht und ergreifen nichts passieren.

Natürlich könnte man sowas programmatisch abfangen (queryOpen der Datenbank mit einem UserProfil, dass die Gruppenmitgliedschaften des Benutzers enthält und mit dem Adressbuch vergleicht und das löschen des lokalen Replizierprotokolls veranlasst, wenn sich da was geändert hat), aber schön ist das natürlich nicht (zumal man -wenn ich mich recht erinnere- das Replizierprotokoll nur über die API löschen kann-)...

Würde mich interesssieren, ob jemand da ne bessere Idee hat.

[Trash]

Also ich kann im Moment nur bestätigen, dass ihr mein Problem richtig verstanden habt.
Der Agent ändert die Gruppen in der names.nsf, wodurch Zugriffe auf Daten gewährt oder entzogen werden, ohne dass sich die Daten selber ändern. Es geht um Kundendaten die einem Techniker zugeordnet werden, wenn er einen entsprechenden Einsatz zu diesem Kunden bekommt.

Lösungsmäßig bin ich jetzt tatsächlich auf dem Weg zu versuchen, das Replizierprotokoll programmatisch zu löschen. Die Anwendung würde dann einen entsprechenden Knopf bekommen, den der Anwender bewusst drücken muss. Dadurch würde dann das Protokoll gelöscht und dann die Replizierung gestartet. Damit bekomme ich aber auf jeden Fall die höheren Laufzeiten.

Falls es also noch bessere Ideen gibt, nur her damit :-)

[Driri]

Wäre es eine Alternative, die Anwendung als Online-Anwendung z.B. via XPages aufzuziehen ?

Man könnte dann ggf. auch via Tablet oder Smartphone damit arbeiten. Oder man nutzt eines der verfügbaren Tools, um dies ohne große Umprogrammierung zu bewerkstelligen (z.B. DominoToGo, docLinkr, Teamstudio Unplugged). Damit wäre je nach Tool sogar eine Offline-Fähigkeit enthalten.

[pimpfling]

Gibt es einen Grund warum der Techniker die Kundendaten nur 'sehen' darf wenn er einen entsprechenden Auftrag zu dem Kunden hat?
Macht es evtl. Sinn grundsätzlich alle Dokumente zu replizieren und in der Anwendung dann die entsprechenden Dokumente ein- bzw. auszublenden?

[Pyewacket]

Wenn bekannt ist welche Gruppen verändert wurde könnte man eventuell mit einem Agenten die betreffenden Dokumente einfach neu abspeichern, dann müssten sie mit der nächsten Replikation mitkommen.

Peter

[Trash]

@Ingo
Online-Zugriff entfällt leider, da die Techniker "in allen Winkeln der Welt" unterwegs sind und Internet nicht immer verfügbar ist

@Stefan
Wir sind halt misstrauisch. Die Techniker sollen nicht mit allen Kundendaten durch die Welt reisen. Wer weiß, wo die Daten abgegriffen werden.

@Peter
Das habe ich versucht, klappt aber nicht zuverlässig. Offensichtlich sieht die Replizierung die Änderungen manchmal gar nicht, weil sie ja bisher keinen Zugriff auf die Daten hatte und sie dann auch nicht repliziert hat.

[Peter Klett]

Und wenn Du in die Dokumente nur die Gruppe als Informationsquelle schreibst und das Leserfeld direkt mit den Namen der Mitglieder der Gruppe füllst? Dein Agent aktualisiert die Dokumente also anhand der eingetragenen Gruppe direkt, und nicht im Adressbuch. Die Gruppe steuert dann nicht mehr den Zugriff, sondern die aufgelösten Namen.

Du hast dadurch natürlich viele Dokumentänderungen mit Gefahr von Replizierkonflikten.

Bei großen Gruppen (um wieviele Mitarbeiter pro Dokument dreht sich das Ganze?) könnten die Dokumente ein 32 kB-Problem bekommen.

Ob das sinnvoll ist, hängt vom Umfeld ab, vielleicht ist es aber eine Überlegung wert.

[Trash]

Na ja, pro Kunde kann es schon mehrere 100 Dokumente geben. Die ganzen Dokumentänderungen sollten eigentlich durch das Gruppenkonzept verhindert werden ...

Die Anzahl der Techniker je Kunde ist eher klein, also vermutlich kein 32K Problem.
Ich werde das als Alternative zum automatischen Löschen der Replizierhistorie hier nochmal intern diskutieren.

Danke für die zahlreichen Beiträge, ich halte euch auf dem Laufenden ...

[Trash]

Zur Info:
Die Reise geht jetzt Richtung Löschen der Replikationshistorie. Damit funktioniert der Abgleich perfekt. Wenn Rechte hinzukommen, werden die Daten korrekt repliziert, wenn Rechte wegfallen, werden entsprechende Daten nicht mehr angezeigt.
Ich hoffe, das die Laufzeit nicht zu problematisch werden wird, aber das zeigt dann erst die Zukunft, wenn das Ganze in Produktion ist.
Danke für alle Gedanken und Tipps zum Thema