Beiträge von CarstenH

    <off topic> Muerte: berliner sind halt eh die besten *g*</off topic>


    ...was mich zu der frage bringt: was hast du unter 5.0.11 mit softdeletions in maildb's zu schaffen? die kamen doch erst in den 6er mailtemplates *kopfkratz*

    Wenn die Fehlermeldung korrekt zitiert wurde: Du hast simpel einen falschen Zertifizierer beim Registrieren des Users verwendet oder greifst auf den falschen Server zu.


    Wären Zugriffsrechte das Problem dann wäre die Ausschrift sinngemäß (je nach Notesrelease leicht unterschiedlich) "Sie sind nicht zum Zugriff auf diesen Server berechtigt."

    freundlich hin oder her...aber es geht *g*


    ok - dann noch ein andrer "trick" der geht auch mit simpler einladung ;=)


    - zuerst schreibt man die einladung wie gehabt
    - danach schreibt man die personen, die extern sind, mit einem kleinen, absichtlichen fehler in der adresse:


    z.B. HansMeiser@EXTERN, MaxMeier@EXTERN usw. (wichtig: die adresse darfs natürlich nicht geben)


    Ergebnis:
    - die Einladung geht normal raus (kommt zwar wieder zurück - kann man mit ner regel oder einem domänen-dokument serverseitig aber verhindern)
    - der Mailrouter zählt bei der Reservierung alles richtig
    - eine spätere Änderung geht per Einladung
    - man sieht (bei sinnvoll gewählen Namen) tatsächlich welche personen noch so kommen werden ohne diesen die mail geschickt zu haben ;=)


    ps: nein, ich hab nix getrunken - wollt nur zeigen dass es notes auch freundlich kann *gg*

    Leider nicht mit "Boardmitteln". Das Mailrouting wird von sehr vielen Einstellungen beeinflußt.


    Eine sehr simple Topologie-Darstellung findet man im Admin-Client unter Nachrichten->Mail->Mailrouting-Topologie (geht nur wenn auf dem Server der Task "maps" läuft).


    Allerdings ist das weder vollständig noch in irgendeiner sinnvollen Form verwendbar.


    Aber vielleicht gibts ja ein 3rd-party-tool mit dem entsprechenden feature das ich noch nicht kenne ;=) wenn nicht müßte man mal eins entwerfen, scheint ne marktlücke entdeckt worden zu sein *g*


    ps: ich bin davon ausgegangen dass mailrouting gefragt war.

    Zitat

    Wenn ich das aber richtig verstehe habt Ihr aber auch die Mail-DB des Users dann auch auf h:\?


    keine panik...ein normaler user (ausgenommen mobile user etc.) hat seine mail-db natürlich weiterhin auf dem (notes)server. warum sollte das anders sein nur weil das DATA-verzeichnis woanders liegt ;=)

    voausgesetzt die weitergeleitete mail wurde aufgehoben (gespeichert) geht folgendes:


    originalmail suchen und in irgendeiner ansicht/ordner mit dem cursor drauf stellen (nicht öffnen!)


    - strg festhalten
    - jetzt links die ansicht mail-verlauf suchen und anklicken


    -> cursor steht auf dem mail-thread beginnend mit dem original, darunter alle antworten in korrekter reihenfolge

    ohne design-änderung gehts nur über die persönliche vorlage, dort kann man kopf und fuß völlig frei gestalten.


    allerdings müßte man dann beim mail schreiben auch immer die vorlage benutzen...wenn mans nur ab und zu braucht (z.b. für interne ankündigungen etc) ginge das.


    effektiver wärs sicher eines der hinterlegten bilder in der schablone auf dem server auszutauschen. dann gehts auch mit der normalen mail-funktion.

    Was spräche dagegen in solchem Fall die Reservierung direkt in der Ress.-DB vorzunehmen.
    Die eigentliche Einladung wird dann nur mit dem Ort gefüllt statt die integrierte Raumreservierung zu verwenden.

    Ok...damit kommen gleich etliche probleme:


    - rep.-formel pro user in der server-db anlegen fällt aus da alle mit der gleichen id zugreifen.


    - leser- und designelemente fallen aus selbigen grund aus.


    - @environment fällt aus da es nicht in auswahlen verwendbar ist (übrigens auch alle anderen @funktionen die nicht ausschließlich auf die zu selektierenden dok's zugreifen)


    dann bliebe aus meiner sicht nur ein script, das einmalig von der user-workstation aus die lokale replik der datenbank erzeugt und dabei die replikationsformel auf beliebiger basis generiert. wichtig dabei ist dass die replikationsformel selbst unter keinen umständen mitrepliziert werden darf da ja jeder user eine eigene hat - für den server aber es sich immer um die gleiche person handelt weil alle die gleiche id verwenden. complicated - i know ;=)


    abhängig von der anzahl der user wärs sicher stabiler und weniger aufwand wenn man einfach x technische user-id's erzeugt. nur nochmal als anmerkung...

    variante 1 kostet allerdings eine lizenz ;=)


    variante 2 (mail-in) kostet ein dokument


    variante 3: zusätzlichen alias (email-adresse user1@... oder nur simpel user1 reicht auch) im personendokument von user2 im feld Kurzname hinzufügen. kostet nur eine zeile ;=)

    die desktop-einstellungen, wann dokumente gelöscht werden sollen (unter vorgaben) sind eine reine client-einstellung und gelten für alle datenbanken unabhängig von soft-deletions. diese einstellung läßt sich als richtlinie hinterlegen hat aber - wie erwähnt - keinen einfluß auf das angesprochene 48h-dilemma.


    die soft-deletions und die damit verbundene aufbewahrungszeit werden beim anlegen der mail-db einmalig aus der schablone übernommen. danach kann man sie jederzeit ändern (minimum entwicklerrechte notwendig)


    mit dem adminclient ists am simpelsten, im datei-reiter alle betreffenden mail-db's zu markieren und die eigenschaft auf einmal zu ändern. für zukünftige mail-db's ändert man simpel die schabloneneigenschaft. (achtung bei serverupdates - dann auch änderung erneut nötig).

    es gibt aus meiner sicht 3 lösungsansätze die mir sofort dazu einfallen:


    a) leserfelder
    vorteil: keine superkompliziert zu wartenden rep.-formeln
    nachteil: der user kann auch serverseitig die anderen dok's nicht sehen.


    b) selektive rep.-formel pro user
    vorteil: ähm...keiner
    nachteil: etliche, z.b. schwer zu warten, user kann formel verseh. od. abs. ändern, formel wird dort berechnet wo sie gerade läuft - führt zu "unerklärlichen" ergebnissen


    c) sel. rep. mit gemeinsam-persönlicher (private on 1st use) ansicht in der server-db
    vorteil: user sieht serverseitig alles, lokal nur seins
    nachteil: bei sehr vielen usern wird die serverseitige db um etliches größer.


    noch was zur sel. rep.-formel pro user: könnte man den user mittels button und ein wenig script selbst erzeugen lassen, aber ist nur schwer zu warten das ganze...schon gar nicht nachträglich ohne weiteres änderbar.


    noch ne anmerkung zum feldinhalt - wenn bereits ein username drin steht, warum nicht mittels agenten auf den echten namen ändern lassen?

    simpelste (wenn auch nicht meine favorisierte) lösung ist, bei der installation das DATA-verzeichnis aufs home-lw des users zu legen. nicht zu verschweigender nachteil aller fileserverbasierten lösungen ist jedoch ein totalabsturz des notesclients wenn der fileserver auch nur für ne sekunde weg war. dynamisches re-connect klappt nicht bei offenen lokalen notes-db's. ist novell stabil und das netz+server schnell genug (gigabit eth ist ideal) dann ists ne sichere lösung. nebenbei hat man die chance des users client mit allen einstellungen täglich sichern zu können.

    natürlich steht im personendokument nicht das echte kennwort des users! die funktion ist vielmehr ein sicherheitsfeature die den unbemerkten diebstahl/weitergabe von id-dateien verhindern soll. normalerweise würde es unbemerkt bleiben wenn jemand eine kopie meiner id an einem anderen pc verwendet.


    sobald ich mein kennwort erstmalig am client ändere wird eine prüfsumme (die aus dem geänderten kennwort errechnet wird) im feld PasswordDigest abgelegt. wenn sich nun ein beliebiger client authentifiziert wird vom server (falls im serverdokument "kennwörter überprüfen" aktiviert ist) im personendokument geschaut ob die kennwortprüfung für die person aktiv ist und, wenn ja, ob bereits eine prüfsumme im digest-feld steht. wenn das alles zutrifft wird die bei der authentifizierung übermittelte prüfsumme mit der zuletzt hinterlegten prüfsumme verglichen. stimmen sie nicht überein schlägt die authentifizierung fehl.


    hat man tatsächlich 2 id's (z.b. eine auf dem office-pc und eine kopie auf dem laptop) braucht man lediglich das kennwort der kopien dem "original" (damit ist in dem fall die kopie gemeint, auf der man das kennwort zuletzt erfolgreich geändert hat - deren prüfsumme also zum vergleich verwendet wird) anzugleichen und alles läuft wieder. löscht man im personendokument das feld mit den prüfsummen nur leer dann hat man das "problem" bei der nächsten änderung gratis wieder.