Nicht lesbare Dokumente finden um Löschen zu verhindern

[pram]

Hallo, diesmal hab ich folgendes Szenario.

Es gibt ein "Hauptdokument" (Hauptdokument ist eigentlich der falsche Begriff, weil sich die Dokumente nicht in einer Antworthierarchie befinden) und ein oder mehrere Unterdokumente. Diese sind über eine Lookupansicht verknüpft.

Nun ist es so, wenn das Hauptdokument gelöscht werden soll, muss geprüft werden ob das Unterdokument gelöscht werden darf. Dies funktioniert auch soweit der aktuell angemeldete Benutzer diese lesen darf.

Es kann allerdings vorkommen, dass dies einmal nicht der Fall ist. Hier möchte ich prüfen, ob es Unterdokumente gibt und eine entsprechende Warnung/Fehlermeldung ausgeben.

Hat hier vielleicht wer einen Tipp für mich?
Mir würde es schon reichen, wenn ich feststellen könnte, wieviel Dokumente es mit "Name = xyz" in meiner DB gibt, da ich die Anzahl dann mit der in der LU-Ansicht vergleichen könnte.

Gruß
Roland

[koehlerbv]

Unter dem Account des aufrufenden Users geht das nicht. Du kannst da nur eine Löschanforderung mitsamt bekannter Parameter (Anzahl der für die aktuelle Nase lesbaren (Unter-)Dokumente) absetzen und dann einen Agent mit entsprechenden Rechten darauf loslassen (RunOnServer sinnvollerweise).

Bernhard

[pram]

Hmm, das hab ich schon befürchtet... und das wollte ich eigentlich vermeiden.

Dann werd ich wohl doch etwas mittels Antworthierarchie basteln müssen. Hier kann man ja vom NotesViewEntry Childcount abfragen, welches auch die nichtlesbaren Docs berücksichtigt.


Gruß
Roland

[koehlerbv]

Ich denke, es gibt keine Antworthierarchie, Roland?

Bernhard

[C_T]

Anderen Alternative ist, du hast einen Counter in deinem "Hauptdokument" der bei jedem erstellen eines Unterdokuments hochzählt....

So könntest du zumindest kontrollieren ob die Anzahl vergleichen ob alle Dokumente erwischt wurden...

[tge]

Anderen Alternative ist, du hast einen Counter in deinem "Hauptdokument" der bei jedem erstellen eines Unterdokuments hochzählt....

...und runterzählt, wenn Antwortdokumente/Unterdokumente gelöscht werden. Diese Variante halte ich aber für nicht hundertprozentig sicher.
Da ist der Agent (RunOnServer) doch die beste Methode und so aufwendig zu programmieren nun auch wieder nicht - was spricht dagegen?

Viele Grüße
Thorsten

[pram]

Hallo zusammen,

also die beiden (mir Bekannten) Möglichkeiten, wie ich mein Problem lösen könnte sind
a) über eine Antworthierarchie
b) über einen Serveragenten
(und ggf. c) über Referenzzähler)

a) wollte ich nach Möglichkeit vermeiden, weil ich die Antworthierarchie anderweitig verwenden wollte und mir da vorerst alle Möglichkeiten offen lassen wollte.

b) gefällt mir nicht, da der Ablauf wie Folgt sein soll:
- ermittle alle Unterdokumente rekursiv und prüfe ob diese gelöscht werden dürfen. Dies müsste wegen Leserfelder am Server erfolgen.

- Präsentiere dem User einen Dialog über eine Zusammenfassung: Wenn Sie diese Aktion fortsetzen, werden 1234 Dokumente in den Papierkorb verschoben
Dies muss am Client erfolgen

- Führe den Löschvorgang (bzw. hier Verschiebung in den Papierkorb durh Kennzeichnung mittels eines Flags) durch.
Dies muss wieder am Server erfolgen.

c) scheidet aus, da ggf. Dokumente in die Datenbank repliziert werden, welche vom Counter nicht berücksichtigt werden usw...


je mehr ich überlege umso mehr gefällt mir Lösung A am Besten.

Gruß
Roland

[DAU-in]

...
a) über eine Antworthierarchie
....
a) wollte ich nach Möglichkeit vermeiden, weil ich die Antworthierarchie anderweitig verwenden wollte und mir da vorerst alle Möglichkeiten offen lassen wollte.

das verstehe ich nicht.

warum kannst du die Antworthierarchie nicht verwenden?
die nutzt sich doch nicht ab?

[pram]

Also ich möchte eine Wissensdatenbank machen, in dieser gibt es Kapitel, Artikel und Links. Wird ein Kapitel gelöscht, so müssen alle untergeordneten Elemente gelöscht werden.
Wird ein Artikel gelöscht, so müssen alle Links gelöscht werden (Link = mini-Dokument, welches beim Anklicken den referenzierten Artikel öffnet).
Für jedes Kapitel/Artikel  kann dann eingestellt werden, ob und welche User das Dokument löschen dürfen.

In der Ansicht soll das dann so angezeigt werden:

Code

KAPITEL 1
|
+- KAPITEL 2
|  |
|  +-- Artikel 1
|  +-- Artikel 2
|
+- KAPITEL 3
   |
   +-- Link1 auf Artikel 1
   +-- Link2 auf Artikel 2

Lösche ich Kapitel2, so muss erst geprüft werden, ob Artikel 1 und 2 gelöscht werden dürfen und ob ChildCount von Kapitel2 = 2 ist, da ich sonst annehmen muss, dass es "unsichtbare" Artikel gibt.

Weiterhin müssen auch alle Links die auf die Artikel zeigen, also Link1 und Link2 gelöscht werden, welche aber Antwortdokumente von Kapitel 3 sein müssen, da es sonst in der Ansicht nicht korrekt angezeigt wird.

Wenn nun Link1 aufgrund anderer Leserfelder auch "unsichtbar" ist, so habe ich ein Problem, da dieser nicht mitgelöscht wird... und die DB dadurch inkonsistent wird. Den Trick mit ChildCount kann ich bei den Artikeln nicht verwenden, da dies immer 0 ist
(Die Lösung ist hier natürlich, einfach gleiche Leserfelder zu verwenden)

ODER: kann Ein Dokument mehrfache Antwort auf ein Hauptdokument sein (z.B. Mehrfachwert in $REF ;-) )

ich hoffe mein Problem wird etwas klarer...

Genial wäre natürlich, wenn ich mittels ViewNavigator oder ähnliche Tricks prüfen könnte, ob für ein Suchkriterium was "unsichtbares" existiert.

ich schlaf nochmal darüber, vielleicht fällt mir noch was ein ;-)

Gruß
Roland

[DAU-in]

Muss denn sofort gelöscht werden bzw. darf der Anwender nicht löschen, wenn es Unterdokumente gibt, auf die der Anwender keinen Zugriff hat?
Ich würde da sonst alles über einen Agent laufen lassen (siehe ersten Beitrag von Bernhard), der in Ruhe alles abarbeiten kann.

[koehlerbv]

Du hast ein interessantes Problem, Roland, aber Dein Konstrukt kommt mir krude vor. Du hast readers items, damit sieht nicht jeder alle Dokumente. Du hast eine verschachtelte Struktur, damit kannst Du ChildrenCount etc. vergessen. Vielleicht geht noch etwas über eine (nur programmatisch benutzte) Ansicht mit Summenspalte. Da dieses Verfahren zur Zeit aber einen wirklichen Designfehler von Notes darstellt (gezählt werden auch eigentlich nicht einsehbare Dokumente), würde ich da nicht auf die Zukunft wetten.

Warum baust Du Dein Berechtigungskonzept nicht um? Wer berechtigt ist, überhaupt ein "oberes" Dokument zu löschen, muss auch Leser aller darunter liegenden Dokumente sein. Wer diese Berechtigung nicht hat, kann nur eine Löschanforderung stellen. Und die müsste - wenn Deine readers items Sinn ergeben sollen - dann ja auch noch mal manuell geprüft werden: Es kann doch nicht sein, dass mir einerseits ein Dokument ausdrücklich verborgen wird, ich dieses dann aber löschen darf.

Bernhard

[pram]

Hallo Bernhard

Du hast ein interessantes Problem, Roland, aber Dein Konstrukt kommt mir krude vor. Du hast readers items, damit sieht nicht jeder alle Dokumente. Du hast eine verschachtelte Struktur, damit kannst Du ChildrenCount etc. vergessen. Vielleicht geht noch etwas über eine (nur programmatisch benutzte) Ansicht mit Summenspalte. Da dieses Verfahren zur Zeit aber einen wirklichen Designfehler von Notes darstellt (gezählt werden auch eigentlich nicht einsehbare Dokumente), würde ich da nicht auf die Zukunft wetten.

Die Idee mit einer Summenspalte hatte ich auch schon, leider versagt dies, wenn alle Dokumente versteckt sind, da ich da die Zeile mit der Summe nicht finde  (und wie du schon angemerkt hast, ob es zuverlässig funktioniert ist auch fraglich)

Warum baust Du Dein Berechtigungskonzept nicht um? Wer berechtigt ist, überhaupt ein "oberes" Dokument zu löschen, muss auch Leser aller darunter liegenden Dokumente sein. Wer diese Berechtigung nicht hat, kann nur eine Löschanforderung stellen. Und die müsste - wenn Deine readers items Sinn ergeben sollen - dann ja auch noch mal manuell geprüft werden: Es kann doch nicht sein, dass mir einerseits ein Dokument ausdrücklich verborgen wird, ich dieses dann aber löschen darf.

Bernhard

Ja, es gibt pro Kapitel einen (oder mehrere) Kapitel-Verwalter und nur dieser darf das Kapitel löschen, dieser ist aber im Moment nicht zwangsläufig Leser/Autor der Artikel.

Der geplante Ablauf ist Momentan wie Folgt, damit sollte ich 99,9% der Fälle abdecken/abfangen können:

1. Beim Löschen eines Kapitels, prüfe die Berechtigungen aller Unterdokumente.
2. Schlägt eine Prüfung fehl -> gib eine Fehlermeldung aus:

- Der Artikel "xyz" darf nicht gelöscht werden, weil z.B. sein Ablaufdatum noch nicht erreicht wurde
ODER
- Der Artikel "xyz" sollte nicht gelöscht werden, weil sein Ablaufdatum noch nicht erreicht wurde. Da Sie DB-Administrator sind können Sie den Vorgang fortsetzen

3. Prüfe ob die Anzahl der geprüften Elemente = ChildCount ist, wenn nein, Meldung:
- Es gibt versteckte Elemente, Kapitel kann nicht gelöscht werden. Bitten Sie jemanden mit der Rolle [DB-Admin] das Kapitel zu löschen
ODER
- Da Sie DB-Admin sind, dürfen Sie das Kapitel löschen. Verwaiste Dokumente werden im Anschluß von einem Hintergrundagenten gelöscht.


ein Lösch-geplagter ...
   Roland

[DAU-in]

Ja, es gibt pro Kapitel einen (oder mehrere) Kapitel-Verwalter und nur dieser darf das Kapitel löschen, dieser ist aber im Moment nicht zwangsläufig Leser/Autor der Artikel.

was ist das denn für eine Wissensdatenbank, in welcher die Kapitelverwalter nicht wissen dürfen, was unter ihrer Federführung veröffentlicht wird?

Wenn ich da Kapitelverwalter bin, dann kann der Schulte lauter Artikel aufmachen, in denen steht: "Dau-in ist doof" und ich wunder mich denn ganzen Tag, warum um mich herum alle so gute Laune haben und weiss nicht warum?

Ich glaube, da liegt der Fehler im System.

[pram]

Hallo DAU-in

was ist das denn für eine Wissensdatenbank, in welcher die Kapitelverwalter nicht wissen dürfen, was unter ihrer Federführung veröffentlicht wird?

ja, langsam "entwirren" sich meine Gedanken  vermutlich wäre es das Beste (und auch logischste) den Kapitelverwalter immer als Leser einzutragen und nur das Löschen durch diesen zu erlauben, dann hätte ich die Probleme nicht. (Wäre da nicht der Kunde, der auf die Idee kommt und als Kapitelverwalter "*", also jeder, eintragen will)


Gruß
Roland