Mailregeln

  • wie wärs mit


    Set notesDocumentCollection = notesDatabase.GetProfileDocCollection( profilename$ )


    ... und dann die profile dokumente kopieren ?


    vlg flo.

    - Florian (Vogler)
    ICODEX Software AG :: the developers of the one state-of-the-art Lotus Notes client management solution INTEGRATE!People......

  • <anfall>wow, esc löscht ein textfeld war grad fertig mit endlos text *aaarrrrggghhhhh*


    scheiss browser... wer auf die dämliche idee gekommen ist alles ins web zu heben bei der besch... usability - keine ahnung<anfall ende>
    (meine ich nicht auf dieses forum bezogen sondern allgemein bezogen auf webhype und browsertechnologie deren usablity seit anbeginn weit hinter denen eines notes clients zurückbleibt ...)


    ===


    also, das mit dem copyallprofiles ist keine gute idee, weil das alles etwas komplizierter ist als gedacht:


    zwei dinge spielen hier mit:


    1.) mail rules
    2.) cal profile


    beim hinzufügen, ändern & entfernen von mail rules wird aus der mailrole aufsetzend auf den feldern OrderNum und $FilterFormula ein entsprechendes Feld $FilterFormula_[OrderNum] erstellt.


    zusätztlich wird im cal profile der wert von $FilterFormulaCount an die zahl aller mail rules angepasst - seltsamerweise ist bei mir (notes 7) die erste $FilterFormula (ohne _[num] suffix) leer ("") - ist das bei euch auch so ?


    ===


    naja, werd mal ein script basteln und unter http://www.icodex.com/vofsblog in den nächsten tagen veröffentlichen ...
    stay tuned.


    vlg, flo.

    - Florian (Vogler)
    ICODEX Software AG :: the developers of the one state-of-the-art Lotus Notes client management solution INTEGRATE!People......

  • Ganz so simpel ist es nicht, da nicht alle tatsächlich vorhandenen Regeln auch aktiviert sein müssen. Regeldokumente und Profile bilden hier eine Einheit die nur im Kontext bearbeitet werden darf. Wenn ich zentral Regeln vorgeben möchte dann muß ich entweder sicherstellen daß User keine eigenen Regeln haben oder aber dies im Script berücksichtigen. Was wiederum dann die Frage nach der Priorität (Reihenfolge) zwischen Vorgabe und Benutzerregeln aufwirft. Nicht zuletzt müssen die Profile benutzerspezifisch erzeugt werden da sonst im simpelsten Fall das nicht richtig funktioniert und im schlimmsten Fall die Einstellungen des Users zerschossen werden. Also: Vorsicht und viel Testen.


    PS: weitere Anmerkung: Die Profile haben sich sowohl in den 5er als auch 6er Versionen mehrfach geändert, was Aufbau und Inhalt der Felder angeht. Insofern immer die exakte Version der verwendeten Schablone (nicht des Clients) dazuschreiben!!! Ansonsten Exitus Profilius.

  • Hi Carsten,


    was meinst du mit zentralen regeln ?
    meinst du gemäss deinem beitrag
    http://www.dominoforum.de/modu…t_id=22362#forumpost22362
    die (mail)router config ?


    wenn ich jetzt ein script schreibe, das mail rules von einer mail db in beliebig viele andere mail dbs verteilt, dann wäre das doch eine lösung, oder ? (option prepend or append, alles andere unmöglich)


    man kann ja usern die wahl lassen ob sie es dann disablen ;)
    >> problemfälle doppelt abgesichert


    das löst auch das problem der reihenfolge was ja ein echter hund ist ... (irgendsowas haariges ist immer dabei).


    die nummerierung dürfte nur "enabled" state rules einbeziehen, oder ?
    und zu guter letzt:
    hast du details zu ein paar der vielen versionsunterschiede ?


    vlg flo.

    - Florian (Vogler)
    ICODEX Software AG :: the developers of the one state-of-the-art Lotus Notes client management solution INTEGRATE!People......

  • Mailrules können sowohl in der Mail-DB des Users (ab Notes 5) als auch im Domino Directory (ab Domino 6) des Servers hinterlegt sein. Letztere sind dann eben simpel die Server Mail Rules und werden auch zentral für jede Mail (in- und outbound) ausgeführt, sie beziehen sich im Gegensatz zu denen der User aber auf die mail.box(en).


    Wenn du ein Script zum Verteilen schreibst dann muß dieses Script sowohl die Rule Dokumente je DB anlegen als auch zusätzlich das Kalenderprofil anpassen (nicht kopieren!!!). Im Kalenderprofil befinden sich sowohl die benutzerspezifischen Einstellungen und Vorgaben je Mail-DB als auch alle Rules in ihrer ausführbaren Form (und damit alle Infos was Anzahl, Aktivierung, Reihenfolge und Formel an sich betrifft. Die Ruledokumente im Ordner Regeln dienen nur als GUI zum komfortablen Bearbeiten durch den User, gelesen werden diese vom Router aber nie da dieser nur auf die Profile zurückgreift [Performance]).


    Desweiteren bekommen Ruledokumente eine interne Nummer in der DB in der sie (manuell) erzeugt wurden, die beim Kopieren mit übernommen werden würde und sich mit Nummern in der Zieldatenbank überschneiden würde. In dem Falle kann man würfeln was passiert wenn der User eine von beiden ändern will bzw. welche überhaupt zur Ausführung kommt. Redboxes sind in dem Zusammenhang dann öfter mal drin.


    Die Nummerierung (im Profil) bezieht zwar prinzipiell nur aktivierte Rules mit ein aber trotzdem können Lücken zwischen 2 Nummern auftreten wenn z.B. eine Rule zwischen 2 anderen später deaktiviert oder die Reihenfolge geändert wird.


    In den Profilen werden Ordnerelemente in Form ihrer Note-ID angegeben, diese kann in jeder DB selbst für gleichnamige Ordner unterschiedlich sein, genaugenommen nicht nur kann sondern dem ist so. Damit würde z.B. eine kopierte Rule mit dem Inhalt "Wenn ... dann verschiebe Mail in Ordner ABC" nie funktionieren können weil ABC nur im Regeldokument aber nicht im Profil steht - dort steht die NoteID von ABC.


    Zu den Unterschieden nur kurz soviel und mal auf Rules reduziert (ich hatte schon öfter Kunden mit Mailproblemen von daher weiß ich eher aus dem Kopf daß es in den Templates immer kleine aber feine Unterschiede gab) :


    - Notes 5 kann max 50, ND 6 max 100 Regeln pro DB (wobei ND6 eine zentrale Vorgabegrenze für allzu fleißige User erhalten kann);
    - unterschiedliches Verhalten von ursprünglich pre6 und 6er Datenbanken, teils aus dem Compiler und teils aus dem reduzierten Umfang der 5er Rules resultierend;
    - Bugs in diversen SPR's die Feld- und Funktionsänderungen nach sich zogen, z.B. SPR#STER5MB4LG, SPR#LCUN5DXJDQ mit direkter Auswirkung und weitere mit indirekter Auswirkung.