Asche auf mein Haupt - habe die Funktion noch nie verwendet und die dritte Spalte der Hilfe irgendwie nicht wahrgenommen.
Da schaltet man sich den 21 Zoll-Monitor auf lesefreundliche 640*480 und wundert sich, wenn man von der Welt nicht mehr alles mitkriegt. Vielleicht ist das ein unterschätzter Teilaspekt der Festsellung, daß eine große Gefahr von rechts droht.
Die größte Gefahr von rechts kommt immer dann, wenn man nicht hinschaut.
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.
Ich glaube, daß Diali @Clienttype als Funktion gemeint hatte. Die @Browserinfo brauchst du erst dann, wenn du bestimmte Browsermerkmale bei der Webverwendung benötigst.
Aber ein wenig Vorsicht erscheint mir geboten: vor ein paar Tagen hatte ich im Initialize eines DB-Scripts ein EVALUATE("@Clienttype") versucht - und dabei kam immer "None" als Rückgabewert.
Ein EVALUATE({@IsMember("$$WebClient"; @UserRoles)}) erscheint mir da verläßlicher.
Ich habe oben ein Beispiel gegeben. Versuch einmal herauszufinden, wann die letzte Änderung der ACL war, ohne die ACL als Dokument-Note zu holen.
Bei Aktionen habe ich das von Diali beobachtete Verhalten auch schon erlebt. Bei anderen Fällen greife ich durchaus auch schon einmal auf die Globals eines Objekts zurück, Beispiel: Beim QUERYOPEN einer Maske weiß ich, ob es sich um ein neues Dokument handelt oder nicht, beim QUERYSAVE oder QUERYCLOSE nicht. Wenn ich also diese Information dort brauche, mache ich das mit einer globalen Variable - und das funktioniert gut.
Leider bei AKtionen nicht - und wenn man mit ScriptLibraries arbeitet, muß man diese bei den Aktionen in den Options auch einbinden, soweit ich mich erinnere.
Die ID der ACL ist bei allen Notes-DBs gleich.
Set acldoc=db.GetDocumentByID("FFFF0040")
Set ACLMOD=New NotesDateTime(acldoc.LastModified)
Damit kannst du allerdings dann nur auf die DOKUMENT-Eigenschaften der ACL-Note schauen, nicht aber die Methoden der NOTESACL-Klasse anwenden.
Nehmen wir an, ein Dokument ist TAUREC, DIALI, LN4EVER und BOFH zugeordnet. In der Maske steige ich (als LN4ever) ein und sehe meine Dokumente (über session.username verfügbar). Jetzt schaue ich mir die Dokumente von DIALI an, dessen Aufgabenbereich geändert wurde oder der aus Altersgründen ausgeschieden ist. Ich sehe in der eingebetteten Ansicht seine Dokumente und möchte ihn aus der SINGLECATEGORY löschen (lassen).
Woher soll der Agent, den ich in der eingebetteten Ansicht starte, wissen, daß ich mir gerade die SINGLECATEGORY von DIALI anschaue und dessen Eintrag aus den Dokumenten entfernen möchte ? Die Maske bestimmt zwar, was ICH aus der Ansicht präsentiert bekomme, aber die Ansicht selbst juckt das wenig.
Die eingebettete Ansicht (und alle zu ihr gehörenden Objekte) haben ja m.E. nach keine direkte Rückgriffsmöglichkeit auf Dokumentinhalte der Maske, in die sie eingebettet ist. Daher plane ich den "Trick" mit der gemeinsamen Script-Library, die diese inhaltliche Verbindung zwischen den beiden getrennten Welten herstellen soll.
Genau das war mein "Bauchgefühl". Allerdings darf ich dabei nicht hoffen, daß die Aktion von sich aus weiß, auf welcher Kategorie sie in der Ansicht ausgeführt wird (der Wert der SingleCategory stammt ja aus einem Feldinhalt der Maske). Das möchte ich durch die Verwendung einer gemeinsamen Script-Bibliothek in Maske und Ansicht erreichen.
Wenn ich im Postopen der Maske (sowie im Exiting-Event des Maskenfelds) den aktuellen Feldinhalt der SingleCategory in eine globale Variable der von Maske und Ansicht verwendeten Script-Bibliothek aufnehme, kann ich ihren Inhalt bei der Aktion, die ich in der Ansicht auslöse, abrufen.
Muß ich in der Aktion dann auch noch einmal die Verwendung der Script-Bibliothek in den Global Options definieren ?
Wenn man SPOFU-Ansichten (Shared, Private on first use) wegen der mit dem Ansichts-Update und der Ansichtsverwaltung verbundenen Probleme umgehen möchte, kommt man recht schnell zu Masken mit eingebetteten Ansichten, in denen man nur die "Userkategorie" darstellen läßt.
Wenn der Benutzer Dokumente nicht mehr seinem Namen zugeordnet haben möchte, muß ich ihm eine Möglichkeit geben, seinen Namen aus diesen Dokumenten zu entfernen. Dafür soll er in der eingebetteten Ansicht die Dokumente markieren und dann in der Maske (oder in der eingeblendeten Aktionsleiste der eingebetteten Ansicht ?) eine Aktion auslösen, die die gewählten Dokumente als UNPROCESSEDDOCUMENTS in einer Collection enthält.
Er erstellt dann mit dieser Aktion ein PUBLICACCESS-Dokument, das seinen Namen sowie die IDs der gewählten Dokumente enthält und nachts nimmt ein Agent ihn aus der Kategorienliste heraus. Damit haben auch Leser der DB die Möglichkeit, sich wahlfrei Dokumente zuordnen zu können.
Geht das ?
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 ?
Die Designer-Hilfe ist und bleibt dein bester Freund:
Beschriftung - Wenn Sie eine dynamische Beschriftung der Aktionen wünschen, geben Sie eine Formel in das Beschriftungsfeld ein. Die dynamische Beschriftung wird dann als Name einer Schaltfläche, eines Eintrags mit Kontrollkästchen oder im Aktionsmenü angezeigt. Beachten Sie, dass die dynamische Beschriftung nur in Lotus Domino Designer 6 oder höher möglich ist. In früheren Versionen werden die Namen als Beschriftung verwendet.
Es geht um die Maskenauswahlformel der aktuell verwendeten bzw. der Vorgabeansicht.
Ein @Command([Compose];"Maskenname") ersetzt das "Maskenname" durch die Maskenauswahlformel. Deshalb riet ich zur Einführung einer @IsNewdoc-Bedingung.
Und wenn du in die Maskenformel noch einen Ausschluß für @IsNewdoc reinmachst, hilft das vermutlich auch.
Es gibt verschiedene Szenarien, unter denen dieses Verhalten auftritt.
- Agent schreibt neue Felder in Dokumente, aber es gibt noch kein Dokument, das dieses Feld enthält.
- in Maske oder Teilmaske wurde ausgewählt, daß die Felder nicht in den Feldindex mit aufgenommen werden.
Sind die gelöschten Dokumente noch als Soft-Deletions vorhanden ? Dann ist die Meldung verständlich.
Wenn man den Haken bei ANSICHT - REPLIKSYMBOLE STAPELN wegnimmt, kann das schon einmal für etwas Entspannung sorgen.
Aber eigentlich ist diese ganze Nachkalkulations-DB doch heute schon eine einzige verhunzte Katastrophe.
Mir fällt in den letzten Wochen verstärkt auf, daß unerfahrene Notesprogrammierer und Praktikanten vor Projekte gesetzt werden, denen sie nicht gewachsen sein können und mit wachsender Verzweiflung in verschiedenen Foren Einzelhilfen anfordern, die die aktuell größte Not irgendwie lindern sollen.
Es ist ein sehr zweischneidiges Schwert, dort den Kollaps mit solchen "Hilfen" hinauszuschieben.
Deshalb an dieser Stelle mein ganz klarer Rat an Lotusbluete:
Laß dir helfen. Ein erfahrener Berater kann dir die wesentlichen Fehler richten und auch die bereits bestehenden Dokumente in eine ordentliche Antwortstruktur bringen (Teil-Kostensummenbildung), Datenbank- und Userprofildokumente anlegen, damit deine Feldvorbelegungen klappen. Das ist kein Hexenwerk, aber es ist dringend an der Zeit.
Vielleicht noch ein kleines Beispiel, das den sinnvollen Einsatz von RESUME NEXT in einem Agenten, der über eine DocumentCollection läuft, rechtfertigt
On Error Goto ErrHandler
Set doc=dc.GetFirstdocument
While Not doc Is Nothing
Call Schleife_Tu_Etwas
Set doc=dc.GetNextdocument(doc)
End While
Exit Sub
ErrHandler:
... Fehler dokumentieren
Resume Next
Vielleicht gibt es die gottgleichen Programmierer, deren Programme auch in kompliziertesten SCHLEIFE_TU_ETWAS mit defekten oder gelöschten Dokumenten usw. immer fertig werden.
Die Programme aller anderen Programmierer fallen bei solchen Programmen immer auf die Schnauze - und das heißt nichts anderes als daß der Agent beim fehlerhaften Dokument rausfliegt.
Es ist sinnvoll, den Fehler zu dokumentieren, aber es ist nicht sinnvoll, darauf zu setzen, daß keine Fehler auftreten.
Wichtig bei dem Konstrukt ist, daß die Schleife sehr kurz ist und man nicht mit Fehlerbedingungen vorhandene Dokumente weiter vermurkst.
Letztlich ist das oben beschriebene Konstrukt genau das, was Formelsprachenagenten auch machen, wenn sie über eine Dokumentauswahl laufen. Wenn es einen Fehler gibt, brechen sie auf diesem Dokument ab und machen bei dem nächsten Dokument weiter.
Der entscheidende Satz deiner Botschaft lautet
"Das Archiv liegt auf einem Fileserver." Damit kommt immer genau ein Mitarbeiter an die Datenbank. Voraussetzung sind entsprechende Rechte auf das FS-Share.
Für Notes ist das ein lokaler Zugriff - und da ist es wurscht, was du für Rechte in der ACL einträgst. Jeder ist Manager, es sei denn, du hast eine konsistente ACL eingestellt.
Darf ich den Satz "zur Zeit ist jeder Editor ohne Löschrechte" so verstehen, daß der Zugriff für - Default - auf Editor ohne Löschrechte steht ? Dann liegen die fehlenden Zugriffsmöglichkeiten an fehlenden Rechten auf dem FS-Share (kein Schreibrecht vermutlich) oder der Art und Weise, wie das Archiv dorthin "verfrachtet" wurde (Datenbank korrupt, weil bei laufendem Notes-Servertask über das Filesystem mit dem Explorer kopiert).
Wenn allerdings DEFAULT auf KEIN ZUGRIFF steht, dann müssen alle Mitarbeiter namentlich in der ACL stehen, denn ein Fileserver kann natürlich keine Gruppen auflösen (wie auch ?).
Welchen Grund gibt es, daß dieses Archiv nicht auf einem Domino-Server steht ? Eine Notes-DB mehreren Benutzern auf einem Fileserver zur Verfügung zu stellen, ist eine der schlechtesten Möglichkeiten, Notes-Datenbanken zu betreiben.
Für ein Archiv reicht als Basisrecht LESER, wenn sichergestellt ist, daß es keine Mails mit ausstehenden Empfangsbestätigungen (RETURNRECEIPT="1") mehr in der DB gibt.
Lieber Chris,
nicht die Menge an Beiträgen qualifiziert uns. Damit hast du völlig recht. Aber die Philosophie leht uns, daß wir nicht denken können, was wir nicht sprechen können. Und jetzt schau dir den folgenden Satz von dir daraufhin noch einmal an:
"Also Anwender kopiert im Home Office seine NSF auf ein Medium, geht damit zu seinem Arbeitsplatz kopiert diese in das passende Verzeichniss und arbeitet grad weiter, also er druckt seine Dokumente aus.
Es handelt sich dabei um keine Replik sondern eine Datei (im Sinne einer Kopie)"
Und der letzte Satz belegt ziemlich deutlich, daß dir der Unterschied zwischen einer Repllik und einer Kopie im Sinn von Notes nicht klar ist.
Es gibt Milliarden von Menschen, denen dieser Unterschied nicht klar ist, und die leben alle munter weiter. Der Unterschied zwischen denen und dir ist, daß dieser Unterschied dir klar sein muß, damit du einer Lösung deines Problems näher kommen kannst.
Und wenn er dir nicht klar ist, dann brauchst du (externe) Hilfe., denn wie willst du selbst das Problem lösen, wenn du es nicht einmal beschreiben kannst ?
Existieren das zugehörige Archiv und das Archivprofil ?
