Über diese Datenbank - About this database - document

[MrXYZ]

Hi @ALL,

wieder mal eine spezielle Frage.

Wenn ich in den Datenbankeigenschaften "Bei Änderung Dokument 'Über Datenbank' anzeigen" aktiviere, wird bei Änderungen das Dokument beim Öffnen der Datenbank angezeigt.

Wie kann ich beispielsweise dieses Dokument ohne diese Option steuern ?

Beispiel: Das "Über diese Datenbank" Dokument enthält eine eingebettete View mit News. Wenn eine News dazu kommt, soll das "Über diese Datenbank" Dokument angezeigt werden. Mit der oben angegebenen Option handelt es sich hierbei aber nicht um eine Änderung, sondern ein neues Dokument. Ich würde gerne als Administrator dieser Datenbank ein Flag oder etwas Ähnliches setzen, damit der User beim nächsten Öffnen der Datenbank das "Über diese Datenbank" Dokument angezeigt bekommt.

Für die normale Option "Über diese Datenbank" Dokument , die aktiviert werden kann, wird dem Anwender nur einmal dieses Dokument angezeigt.
Wo werden die Informationen des Benutzers gespeichert, dass er die Änderungen gelesen hat?

Für einen Ansatz wäre ich dankbar !

[ata]

Hallo,

das sind gleich mehrere Fragen:

1. Wie kann ich beispielsweise dieses Dokument ohne diese Option steuern ?
2. Wo werden die Informationen des Benutzers gespeichert, dass er die Änderungen gelesen hat?

zu2.:
Da gibt es keinen Ort, das musst du loggen - mit all den Randerscheinungen über die Aussagekraft..

zu 1. muß ich mal schauen...

Toni

[ata]

zu 1.
Mit "@Command( [HelpAboutDatabase] ) " lässt sich das Dokument öffnen...

Toni

[MrXYZ]

Danke für die Info, aber das brauche ich nicht. Siehe oben, wenn neues News-Dokument angelegt wurde, soll einmal !! dieses "Über diese Datenbank" Dokument angezeigt werden.

[koehlerbv]

Da Designelemente auch "nur" Dokumente sind, reicht es aus, wenn man eines dieser Designelemente als NotesDocument instantiiert und erneut speichert. Das triggert dann (durch eine veränderte interne Tabelle) das Öffnen des AboutDatabase-Dokuments.
Ich halte das aber nicht für einen idealen Ansatz. Besser wäre es, wenn man hierzu ein ganz normales Dokument oder eine Seite verwendet, die aufgebaut ist wie das AboutDatabase-Dokument. Im DatabaseScript/PostOpen kann man nun ermitteln, ob ein neues Dokument vorhanden ist und dann bei Bedarf diese Maske öffnen. Möglichkeiten, sich den letzten "News-Stand" pro User zu merken, gibt es ja auch zuhauf.

HTH,
Bernhard

[ata]

Dazu müsste in allen relevanten News hinterlegt sein, wer dieses Dokument schon gelesen hat. Dann müsstest du schauen, ob in einem dieser Dokumente der aktuelle User nicht drin steht und dann im Postopen der Datenbank ggf. das Dokument öffnen...

Toni

[koehlerbv]

Nö, Toni. Man muss nur das letzte Erstellungs-/Modifikationsdatum der News wissen - und userbezogen, wann die Seite oder Maske letztmalig präsentiert wurde.

Bernhard

[MrXYZ]

Hallo Bernhard,

genau das habe ich bereits ausprobiert. Wir haben ein virtuelles Feld in das AboutDatabase Dokument gespeichert, aber das klappt nicht bei allen Anwendern. Ausserdem werden lt. Notes Peek mehrere dieser Dokumente angelegt und nicht, wie es eigentlich sein sollte, die Sequenz des AboutDocuments erhöht.

Der Ansatz mit einem änhlichen Dokumenttyp klingt verlockend. Alternativ haben wir über Userprofile nachgedacht.

[MrXYZ]

Da Designelemente auch "nur" Dokumente sind, reicht es aus, wenn man eines dieser Designelemente als NotesDocument instantiiert und erneut speichert. Das triggert dann (durch eine veränderte interne Tabelle) das Öffnen des AboutDatabase-Dokuments.
Ich halte das aber nicht für einen idealen Ansatz. Besser wäre es, wenn man hierzu ein ganz normales Dokument oder eine Seite verwendet, die aufgebaut ist wie das AboutDatabase-Dokument. Im DatabaseScript/PostOpen kann man nun ermitteln, ob ein neues Dokument vorhanden ist und dann bei Bedarf diese Maske öffnen. Möglichkeiten, sich den letzten "News-Stand" pro User zu merken, gibt es ja auch zuhauf.

HTH,
Bernhard

Wo genau finde ich diese interne Tabelle ? Genau das suchen wir, damit der User nur einmal diese Info angezeigt bekommt !

[koehlerbv]

Was ist den ein "virtuelles Feld"?
Was aber auf jeden Fall korrekt ist: Das getriggerte Öffnen des AboutDatabase-Dokuments funktioniert nicht zuverlässig.

Bernhard

PS: An diese interne Tabelle und den daher bezogenen entscheidenden Wert kommst Du nicht heran.

[MrXYZ]

... shit happens :-((

Zu Deiner Frage (unser Ansatz, um eine Veränderung im AboutDocument zu erzwingen !):
   
Dim session As New NotesSession
   Dim ws As New NotesUIWorkspace
   Dim db As NotesDatabase
   Dim doc As NotesDocument
   
   
   Set db = session.CurrentDatabase
   Set doc = db.GetDocumentByID("FFFF0002")
   doc.status = "0"
   Call doc.Save(True,False)
   

[ata]

... ich denke hier geht was aneinander vorbei. Das About-Dokument ist vom Sinn her auf jeden Fall das falsche Mittel. Besser wäre wie es Bernhard vorgeschlagen hat, ein Dokument mit einer eingebetten Ansicht zu verwenden.

Das Logging, wer welche News gelesen hat sollte nach meiner Ansicht in den News-Dokumenten gepflegt werden, denn nur so ist gewährleistet, daß jeder User diese News gelesen/geöffnet hat...

Toni

[koehlerbv]

Das AboutDatabase-Dokument ist wirklich nicht der ideale Platz, Toni.

Aber: Die Informationen, wer was gelesen hat, würde ich niemals in den Dokumenten selber speichern. Vielleicht sind die User kann nicht editierberechtigt, und vor allem: Das brüllt geradezu nach Replizierkonflikten.
Wo und wie man das ablegt, hängt davon ab, was die Anforderungen sind: Jeder hat alles gelesen (vermutlich gar keine gute Idee - vor allem auf diesem Wege) oder "Es gibt Änderungen, seitdem Sie das letzte Mal die News präsentiert bekamen". Aber diese Anforderungen kennen wir noch nicht.

Bernhard

[ata]

Das brüllt geradezu nach Replizierkonflikten.

... da hast du natürlich Recht - also dann bleibt dir pro User nur die Möglichkeit über ein Profildokument/Userdokument zu gehen, und es dort mitzuloggen...

Toni

[MrXYZ]

Im Prinzip reicht eine Page mit einem eingebetteten View der letzten News. Diese Page darf nur einmal angezeigt werden und nur dann, wenn eine neue News vorliegt (Dokument im embedded view).

Ich glaube, um ein Userprofil, das das letzte Datum des Öffnens der Page speichert und einen Vergleich zu aktuellesten Datum der aktuellsten News, kommen wir nicht herum.

Also im Kurztext Wenn DatumletzterLeseZugriff <DatumAktuellsteNews -> Anzeigen Page

Das DatumLetzterLeseZugriff würde dann im Userprofil abgelegt.

[ata]

... so in der Art sehe ich das auch - dann hätte er zumindest die Chance gehabt die News zu lesen...

Was passiert bei mehreren neuen News seit dem letzten Lesen?

Toni

[koehlerbv]

Was passiert bei mehreren neuen News seit dem letzten Lesen?

Na, das neueste Dokument ist auf jeden Fall jünger als das letzte userbezogene Öffnen. Da ist es doch wurscht, ob nun acht Dokumente neu sind oder nur eins.

Bernhard

[ata]

Wo werden die Informationen des Benutzers gespeichert, dass er die Änderungen gelesen hat?

 ... das heißt für mich - die News werden gelesen - jede - oder nicht?

Toni

[koehlerbv]

Jo, Toni - hier haben wir es wieder mal: Das Problem mit den unsauberen / zweideutigen Problem-/Anforderungsbeschreibungen. Geschrieben wurde auch:

Diese Page darf nur einmal angezeigt werden und nur dann, wenn eine neue News vorliegt.

Darüber muss sich aber der Threadersteller den Kopf zerbrechen bzw. sollte dies ganz klar aufmalen. Lösungen hätten wir für die bisher naheliegenden Fälle ("zeige, wenn es Neues gibt" oder "zeige, wenn es ungelesenes gibt").

Bernhard

[ata]

"zeige, wenn es Neues gibt" oder "zeige, wenn es ungelesenes gibt"

... genau das meinte ich mit...

Was passiert bei mehreren neuen News seit dem letzten Lesen?

Toni