Das Notes Forum
Domino 9 und frühere Versionen => ND6: Entwicklung => Thema gestartet von: Alexis am 29.01.04 - 09:10:31
-
Hallo Forum,
ich suche eine Anregung zur Ermittlung, welcher User ruft welches Dokument auf.
Problemstellung: In einer speziellen Form befindet sich ein Excel-Tool als Attachment. Die Frage stellt sich nun, wie oft und wer benutzt dieses Tool im Unternehmen.
Diese Funktion kann m.E. in der Form selbst (versteckt) eingebettet sein, so dass es nur im Editmode zu sehen ist.
Kann mir jemand einen Anstoß geben?
Alexis
-
guckst du:
http://eknori.dyndns.org/knowledge/devidea.nsf/Alpha/E8AEA878FB01076B8025689700280E0B?OpenDocument (http://eknori.dyndns.org/knowledge/devidea.nsf/Alpha/E8AEA878FB01076B8025689700280E0B?OpenDocument)
-
Hm, diese Aufgabenstellung ist aber nicht ganz trivial.
Zunächst: Das Attachment kann man sich ja auch lösen, und dann kann die Verwendung nicht mehr gezählt werden.
Willst Du bei jedem Öffnen (im EditMode) diesen Vorgang speichern, sind Replizier- bzw. Speicherkonflikte vorprogrammiert.
Was man machen könnte: Im PostOpen ein @MailSend in eine Mail-In-Datenbank - so ist man
- vor Replizier- und Speicherkonflikten sicher
- man ist nicht auf den EditMode angewiesen.
Mit LS kann man natürlich noch raffiniertere Sachen machen (Log-Dokumente oder Items mit Item.Name = UserName und so zählen und ...
HTH,
Bernhard
-
@eknori: Gerade die Methode b) ("Who_Read"-Feld) schreit nach Speicher- und Replizierkonflikten ...
Bernhard
-
Hallo Enkori, hallo Berhard,
Danke für den Lösungsvorschlag (sind ja eigentlich zwei). Er trifft genau meine Anwendung! Super als Basis für weitere Gemeinheiten.
Alexis
-
Hallo,
hab doch noch ein unbewältigtes Problem in diesem Zusammenhang:
Wenn User ein von mir "überwachtes" Dokument aufrufen, erhalten sie die Fehlermeldung, dass sie nicht autorisiert sind, die Aktion auszuführen.
Die Aktion ist vermutlich das (unerlaubte) Schreiben (User-Name, Datum, etc.) in ein seperates Logfile-Dokument, das ebenfalls Bestandteil der Datenbank ist.
User haben natürlich weitgehend nur Reader-Rechte.
Any idea ???
Alexis
-
So what - was erwartest Du ? Wenn Deine Anwender nur Leserrechte haben, können sie natürlich kaum schreiben.
Ergo: Nachdenken über die Zugriffsrechte Deiner User, oder Zugriffe in eine Mail-In-DB übermitteln, oder öffentliche Dokumente erstellen einrichten ...
Bernhard
-
Für sowas sollte man eigene Dokumente verwenden, nicht in das Dokument reinschreiben! Was ist, wenn das Dokument gelöscht wird? Was, wenn der User gar nicht bearbeiten darf?
Am besten ausserhalb in einer eigenen Datenbank, in der alle User das Recht "Depositor" (Einsteller) haben. Dann ist auch die Revision zufrieden.
Andreas
-
Andreas, das ist ja genau das, was ich vorher schon geschrieben habe. Logging in öffentliche Dokumente der selben DB oder per Mail-In (weil: sie könnten ja off-line arbeiten) in eine andere DB.
Da ist viel machbar, und das ist nicht mal so kompliziert. Was aber ein "No-No" ist: Logging in das betreffende (gelesene) Dokument selbst.
Alexis: Schreib' mal genaueres. Da geht was ...
Bernhard
-
Hi Bernhard,
ich wollte es nur nochmal betonen ;)
Andreas
-
Hallo Bernhard, Andreas, Eknori und Leser,
ich denke, die Sache ist jetzt mit Eurer Hilfe nun rund. Die ursprüngliche Aufgabe hat sich dabei in der Diskussion praktisch erweitert auf die Problemstellung:
Wer öffnet bestimmte Dokumente in einer Datenbank?
1. Der folgende Code von Eknori greift für Benachrichtigung bei Zugriff auf besagtes Dokument per Mail_In und Listing der Leser im Dokument selbst (wegen der Rechte). Letzteres ist nicht so praktisch bei einem Dokument mit Attachment, das sich per Autostart öffnen soll.
http://eknori.dyndns.org/knowledge/devidea.nsf/Alpha/E8AEA878FB01076B8025689700280E0B?OpenDocument
2. Will man ein seperates Log-Dokument führen (so wie ich), dann bietet sich ein seperates Dokument-Format an, was öffentlich lesbar ist (unabhängig von anderen Rechten). Zu beachten ist dabei (war mir so nicht bekannt) das Anlegen eines speziellen Feldes $PublicAccess als "Computed when composed" mit Anfangswert "1". Damit wird dieses Dokument schreibbar für alle Leser. Das Dokument lässt sich natürlich wiederum einfach vor den Usern verstecken.
Danke für Eure Anregungen.
Alexis
-
always a pleasure....
-
... und wenn dann noch ein nettes und ausführliches Feedback kommt ...
-
Hallo Forum,
ein gewisses Feedback halte ich für eine Selbstverständlichkeit, auch weil die viele anderen Leser vom Erfolg/Misserfolg "hören" wollen.
Anregung an die Admins: Postet doch denjenigen eine freundliche (Standard-)Mahnung, die das nicht beherzigen.
Ich finde das Forum und besonders die Profis unter Euch Spitze. Keine Fragestellung ist Euch zu dumm, keine Diskussion zu lang.
Alexis
-
Hi Alexis,
Dein Verhalten ist vorbildlich :D
Die Admins wären aber überfordert, wenn alle Threads nachgehalten werden müssten.
Die üblichen Verdächtigen sind irgendwann bekannt und dann wird bei denen eben die Antwortqualität leiden...
Andreas
-
Hallo Forum,
ich muss doch noch einmal den Fall hochholen.
Zur Erinnerung
Problemstellung: <Wer benutzt in der DB welches Dokument?> erfassen.
Lösung: User, Zeitstempel, Doku-Subject per LotusScript in ein "verstecktes" Log-Dokument ($PublicAccess) der selben DB schreiben im Event "Terminate".
Feines Problem: Es treten einige wenige Speicherkonflikte auf. Für mich nicht ganz nachvollziehbar:
13:34 Eintrag im Logdokument korrekt
13:47 nächster Eintrag dito
Dazwischen 13:43 Eintrag als Save-Conflict-Dokument!
Meine Überlegung war, dass beim Event Terminate kaum die Möglichkeit von Speicherkonflikten auftreten dürften.
Wo ist der Haken?
Alexis
-
Du schreibst in EIN Log-Dokument ??
-
Hallo Bernhard,
richtig, ich schreibe in ein Dokument.
Überwacht wird derzeit auch nur eine Maske (Form) in der das Script läuft.
Alexis
-
Aber das schreit ja regelrecht nach Replizierkonflikten: Einer ändert ein Dokument auf Server A, der andere auf Server B, und der dritte ändert lokal ...
Bernhard
-
Jouw Berhard,
ich war in der vergangenen Problematik immer auf Save-Probleme fixiert. Aber das wird ein Replizierproblem sein. Du hast natürlich Recht.
Frage: Kann man Server-abhängig unterschiedliche Log-Dokumente ansprechen? Das wäre doch eine gangbare Lösung?
Alexis
-
Frage: Kann man Server-abhängig unterschiedliche Log-Dokumente ansprechen? Das wäre doch eine gangbare Lösung?
Hallo, Alexis,
serverabhängige Log-Dokumente kann man sicherlich machen. Eine sichere Lösung ist aber auch das noch nicht (kommt aber in der Realität auf Eure Userzahl an).
Den Namen des Servers bekommst Du ja mit
NotesSession.CurrentDatabase.Server
heraus.
Problem: Wenn die Leutchen lokal arbeiten, dann bekommst als Antwort immer "" - einen Leerstring. Das kann man natürlich auch umgehen, in dem man sowas bildet wie
If NotesSession.CurrentDatabase.Server = "" then
szServer = NotesSession.UserName
else
szServer = NotesSession.CurrentDatabase.Server
End If
Aber wie Du schon siehst: Auch hier wird das unübersichtlich. So liegt der Schluss nahe, dass zu machen, was wirklich sicher ist: Jeder Zugriff erzeugt ein eigenes Log-Dokument.
Diese könnte man ja auch periodisch zusammenfassen und das Ausgangsmaterial dann löschen.
Insgesamt stellt sich aber die Aufwand-Nutzen-Frage ... Wozu überhaupt dieses Logging ?
Bernhard
-
Hallo Bernhard,
Danke für Deine Antwort. Das bringt mich wieder ein Stückchen weiter.
Warum das alles?
Die Datenbank um die es sich hier handelt ist eine Informationsquelle für unser Unternehmen, und unterliegt einer ständigen Veränderung hinsichtlich Struktur und Inhalt.
Zuerst war die Fragestellung, wer von den 2000 LN-Usern der Company benutzt ein bestimmtes Tool, das in der Datenbank als Attachment enthalten ist und wie oft wird darauf zugegriffen.
Danach kam mir die Idee, überhaupt den Userzugriff etwas weiter zu analysieren. Wieviele Mitarbeiter lesen welche Bereiche in der Datenbank. Das ist hinsichtlich Akzeptanz, User-Freundlichkeit, Transparenz schon interessant.
Gruß
Alexis
-
Dann würde ich sagen: Jedes Zugriff erzeugt ein (kleines) Log-Dokument(chen), dort speicherst Du "Wer, wann, was". Dann kannst Du Dir Log-Ansichten bauen und kategorisieren nach Deinen Themenbereichen (muss natürlich mitgeloggt sein und der Struktur Deiner DB entsprechen), nach den Usern usw.
HTH,
Bernhard
PS: Über eine periodische Konsolidierung der Docs würde ich aber auf jeden Fall nachdenken - bei 2.000 Usern bläht sich die DB bei Logging auf jeden Fall auf. Logging-Ansichten sollten daher auch unbedingt nur für bestimmte User zugänglich sein, und die Log-Docs sollten ein entsprechendes Leser-Feld haben (damit kann zwar jeder Docs erstellen, aber eben nicht mehr lesen und damit auch nicht mehr replizieren (müssen))
-
Hallo Bernhard,
Deine Anregung ist interessant, umgeht die Replikationsproblematik und ist technisch sogar für mich machbar. Ich werde das mal checken.
Nochmals Danke.
Damit schließe ich dieses Thema ab, bin aber sicher, dass ich schon bald wieder im Forum "Hilfe" schreie.
Alexis
-
Hallo,
ich habe die problemstellung zwar nur überflogen, hoffe aber trotzdem nicht total vorbei am thema zu liegen....
wenn ich wissen möchte, wie oft ein dokument gelesen wird, dann so:
im PostOpen Event der Maske:
Akt:=@GetProfileField("ReadCounterGlobal";"Global";@Text(@DocumentUniqueID));
@If(@IsError(Akt)|Akt=""|@IsError(@TextToNumber(Akt));@Set("Akt";0);@Set("Akt";@TextToNumber(Akt)));
@Set("Akt";Akt+1);
@SetProfileField("ReadCounterGlobal";"Global";@Text(Akt);@Text(@DocumentUniqueID))
und zum anzeigen im Dokument ein berechneter Text:
Reads:=@GetProfileField("ReadCounterGlobal";"Global";@Text(@DocumentUniqueID));
@If(Reads="";"0";@IsError(Reads);"?";@Text(Reads))
auf diese art braucht der anwender keine schreibrechte auf der db und es funktioniert ansich wunderbar; lediglich zum "auswerten" müsste man dann noch einen agent basteln
-
Das geht so nicht - sowie mehr als eine Replik existiert, geht das Ganze krachen.
Bernhard