ACL-Leser erstellen PUBLICACCESS-Dokumente und -Profile

Ich plane, für eine DB, die weltweit auf zig Notebooks und Servern verstreut liegt, eine Aufzeichnung, wer die Datenbank eigentlich wo benutzt. Dafür möchte ich im DB-Script eine Routine erstellen, mit der der Benutzer beim Öffnen der Datenbank ein Dokument erstellt, in dem steht:
- sein Name
- der Server (ggf nichts für lokal)
- das Datum
- das LastModified-Datum der ACL
Für Autoren und Editoren ist das überhaupt kein Problem, aber wie ist es mit Lesern, die nur öffentliche Dokumente schreiben können ?

Frage 1: Kann der Leser im Backend ein Dokument erzeugen und in diesem Dokument dann

doc.~$PublicAccess="1"

setzen und es abspeichern ? Oder wirkt das $PUBLICACCESS-Feld immer nur durch das Frontend ?

Das Letzte mache ich bereits seit Jahren erfolgreich, daß ich Leseraufzeichnungen für bestimmte Dokumente mache, indem der Benutzer ein neues Dokument erstellt (Maske ist PublicAccess, enthält ein paar berechnete Felder und ein SAVEOPTIONS-Feld mit Wert "1" und hat im POSTOPEN-Event folgenden Code:

Sub Postopen(Source As Notesuidocument)
Set doc=Source.Document
If Not Source.IsNewDoc Then Exit Sub
Call Source.Save
Call Source.Close
End Sub

Der Benutzer sieht beim Öffnen des Aufzeichnungsdokuments einen kurzen "blauen Blitz" - fertig.

Nachts sammle ich dann diese Leserrückmeldungen per Agent ein und schreibe sie in das gelesene Dokument.

Frage 2: Und wenn wir schon dabei sind: wie kann ein Leser mit dem Recht, öffentliche Dokumente zu erstellen, ein Userprofildokument erstellen ? Es geht mir dabei um die Wahl seiner Dialogsprache. Damit habe ich extreme Schwierigkeiten. Das will ums Verrecken nicht klappen. Weiß jemand Rat ?

Zu 1.: Daß die Maske die Eigenschaft "ÖFFENTLICH" haben muß, ist keine Frage. Damit kann ein Leser mit dem Recht, öffentliche Dokumente zu erstellen, immer ein Dokument erstellen (das hatte ich auch beschrieben). Die Frage ist, ob der Leser ein solches Dokument auch im Backend (ohne Maske bzw. ohne das Durchreichen des erstellten Dokuments durch das Frontend) erstellen kann, indem er in die Felder das Feld $PUBLICACCESS mit dem Wert "1" aufnimmt.

Zu 2.: ich habe es jahrelang mit NOTES.INI-Variablen gemacht. Für WEB-Anwendungen unbrauchbar - und bei jeder PC-Neuinstallation wieder ein unvorhersehbarer Zustand. Profildokumente werden gecached - und sind damit unglaublich schnell im Zugriff. Schon deshalb schwöre ich darauf.

In der Hilfe findet sich zwar der Satz
Ein Benutzer benötigt mindestens Autorzugriff in der ACL einer Datenbank, um ein Profildokument zu erstellen, das für alle Benutzer verfügbar ist.
Aber die Hilfe schweigt sich über die userspezifischen Profildokumente für Leser aus. Deshalb frage ich.

Zu Frage 1: $PublicAccess geht beim Erstellen eines neuen Dokuments definitiv nur durchs Frontend. Eine einfache Überlegung macht das auch bereits klar. Nehmen wir eine Anwendung mit Maske1.

Maske1 ist nicht für PublicAccess freigegeben. Wenn die Konstruktion der Erzeugung eines Dokuments im Backend durch das einfache Setzen des Felds $PublicAccess auf "1" funktionieren würde, könnte jeder Leser, der öffentliche Dokumente schreiben kann, sich einen Agenten erstellen, mit dem er ein Dokument der MASKE1 erzeugt, indem er einfach dieses Feld einbaut. Das Backend weiß ja nichts von der Existenz von Masken und deren Restriktionen.

Zu Frage 2: zu eigenen User-Profilen für Leser, die öffentliches Autorrecht haben, habe ich noch keine Lösung gefunden.

Ein bereits erstelltes allgemeines Profil, das in $PublicAccess eine "1" hat, kann von Autoren öffentlicher Dokumente auf jeden Fall auch benutzt werden - und damit kann man kurzzeitige Werte zwischenspeichern - für jeden etwas Anderes, jeder cachet es sich ja und bemerkt die Verwendung des gleichen Basiselements durch andere Benutzer gar nicht. Damit kann man Cookies in manchen Webanwendungen ersetzen.