Um den OutOfOfficeAgenten in einem beliebigen MailFile zu aktivieren benötigt man neben dem Agenten in dem Mail-File im wesentlichen das OOO-Profil um dort die entsprechenden Einstellungen machen zu können.

Sub enableOOO(personDoc as NotesDocument)
  Dim mailfile As New NotesDatabase("","")
  Call mailfile.Open(personDoc.MailServer(0), personDoc.MailFile(0))
  If mailfile.Isopen Then
    Dim ooo_agent As NotesAgent
    Dim ooo_profile As NotesDocument
    Set ooo_profile = mailfile.Getprofiledocument("OutOfOfficeProfile")
    Set ooo_agent = mailfile.Getagent("OutOfOffice")
    'Just enable in OOO-Profile
    ooo_profile.BookBusyTime="0"
    If ooo_profile.Hasitem("AgentLastRun") Then
      Call ooo_profile.Getfirstitem("AgentLastRun").Remove()
    End If
    ooo_profile.CurrentStatus="1"
    ooo_profile.TaskState="1"
    ooo_profile.FirstDayOut=Today
    'Abwesend bis zum 01. nächsten Jahres. Anwendungsfall hier: Austritt eines Mitarbeiters mit entsprechender Benachrichtigung an die Kontakte des Mitarbeiters.
    ooo_profile.FirstDayBack=CDat("01.01."+Format(Year(Today)+1))
    ooo_profile.AdminP_Status=""
    ooo_profile.Notified=""
    ooo_profile.NotificationReport=""
    ooo_profile.OOO_PersonLeft="X"
    Call ooo_profile.ComputeWithForm(False,False)
    'Hier muss noch der entsprechende Text gesetzt werden (erfolgt in meinem Fall per Formel im OOO-Profile)
    'Save Profil und Agent
    ooo_agent.Isenabled = True
    Call ooo_profile.Save(True,False)
    Call ooo_agent.Save()
  End If
End Sub

Doc wird der Sub übergeben und ist in diesem Fall das markierte Personendokument aus der names.nsf.

Erweiterung: Damit der ausführende Admin keine Berechtigung auf dem Mailfile benötigt, kann diese Funktion auch in einem geschedulten Agenten (mit ServerID gesigned) aufgerufen werden .

Wenn bei Keyword Change in LN (Client) Lotusscript – Code ausgeführt werden soll geht das leider nicht mit den Events OnChange oder ähnlichem. Ein Workaround ist “Refresh Document on Keyword Change” anzuhaken bei dem zu überwachenden Feld und im PostRecalc-Event des Dokuments die gewünschte Funktionalität auszuprogrammieren. (z.B. Felder setzen, etc.) Siehe Screenshots untern.

RefreshOnKeywordChangeExample.nsf

Hier ein paar Punkte, die helfen können, zumindest bei neuen Datenbanken von der grünen Wiese…

• Niemals sollte ein User löschen dürfen.  “Softdeletion” sollte grundsätzlich ausprogrammiert werden. -> Auch bei Drücken von  Delete/Entf sollte der Code ausgeführt werden
• Ich schätze es wäre eine gute Idee grundsätzlich Historien von Dokumenten bei Änderungen mit zu speichern (Trade-Off: Speicherplatz)
• Das Pasten von Dokumenten in Views sollte immer überdacht werden und wenn möglich abgeschaltet, bzw. ausprogrammiert (was passiert, wenn ein Dokument gepastet wird? -Schlüsselwert umsetzen?)
• Script gehört IMMER in eine Script Library (DRY-Prinzip)
• Allgemeine Namen wie Main/Haupt/Subs/Functions/etc. sind VERBOTEN
  Was tut das? Nicht sprechend und damit doof für alle, die den Code nochmal anfassen müssen (inklusive einem selbst)
• Beim Öffnen der Datenbank können und sollten “Standard LS Objekte”  (Session/Workspace/in Script genutzte Views) gesetzt werden, damit sie DB-weit zur Verfügung stehen UND auch überall genutzt werden. Also als Beispiel:

  
    Dim db_obj As Variant
    Set db_obj("session") = New NotesSession
    Set db_obj("db") = db_obj("session").CurrentDatabase
    Forall a In db_obj("db").Views
      Set db_obj(a.Name)=a
    End ForAll
  

  Initialisiert sämtliche DB Objekte in eine Liste. Bei kleineren Anwendungen kann man das so machen, bei grösseren würde ich die Liste der Views defninieren, die ich irgendwo im Script nutzen möchte. Dies verlagert Performanceengpässe innerhalb der Anwendung auf den Start der Anwendung. Ist letztlich wie häufig ein Trade-Off und kein Win-Win .

• Funktionen und Subs sollten LESBAR sein, also kurz und knackig (KISS-Prinzip) die Namen sollten das ausdrücken, was die Funktion tut.
• Code-Dokumentation sollte nur in Ausnahmefällen notwendig sein (KISS-Prinzip), die Funktionalität sollte sich aus Namen/Signatur der Funktion ergeben.
• Option Public ist VERBOTEN (mit LN85 Vorgabeeinstellung)
• Option Declare / Explicit ist PFLICHT (mit LN85 sowieso Vorgabeeinstellung)
• Langer Listen Globaler Variablen sind BAH
• Extrem lange Parameterlisten sind aber auch BAH
  -> ggf. Datenstruktur überdenken/anlegen/übergeben
• Replizierkonflikte sollten wenn möglich automatisch gelöst werden -> Agent, der an Hand von Parameterdokumenten oder auch “gesundem Agentenverstand” entscheidet, welches Dokument der Winner ist.
• Code auskommentieren ist verboten! Wenn man wirklich denkt, dass Code nochmal genutzt wird, besser in eine Datei auslagern und die direkt im Papierkorb deponieren… Und den dann am besten regelmässig leeren…
• Check-Out Kommentare/Code-Kommentare in einer vorgegebenen definierten einheitlichen Sprache -> sieht einfach schöner aus und erhöht die Wahrscheinlichkeit, dass jeder alles versteht (theoretisch)
• Jede Änderung sollte aus und eingecheckt werden.
  -> Am Ende eines Tages sollte nichts mehr ausgecheckt sein, nur so eine Idee, ich bekomme es auch nicht hin…
• Programmierung von JavaScript in <Computed Text> auf irgendwelchen dynamisch nachladenden Seiten ist zwar sehr mächtig aber auch irgendwie sehr evil (subjektiv), objektiv ist der Code einfach nicht mehr wartbar und verstösst gegen das KISS – Prinzip…
• Variants sollten wenn möglich vermieden werden. Wenn nicht möglich als solche definiert werden (erhöht die Lesbarkeit des Codes)
• Kurzschreibweisen für Feldzugriffe à la doc.Field(0) sollten vermieden werden (auch wenn ich das sehr gerne nutze birgt dies doch die Gefahr, dass der Code abbricht, weil das Feld nicht existiert, nutzt man Getfirstitem oder ähnliches wird einem eher bewusst, dass man da nochmal mit einem “HasItem” prüft, ob vorhanden…), das gilt hauptsächlich für den lesenden Zugriff… -> Auch eher veraltet, der Grundsatz. In 8.5 wird ein Leerstring zurückgegeben, wenn das Feld nicht existiert.
• Nutze Datentypen. Will sagen, wenn du ein Datum speichern willst speichere es als Datum und NICHT als Text, das gleiche gilt für Zahlen -> ist z.B. dann wichtig, wenn die Anwendung im Nachhinein internationalisiert werden soll….

Manches davon könnte Lotus Notes in einer zukünftigen Version sicherlich auch erleichtern… In irgendeiner schönen, vermutlich leider sehr utopischen neuen Zukunft…