Beiträge von koehlerbv

    IsPublicAddressbook hängt von der Schablone ab.


    Da Du ein Exit Forall verwendest, bekommst Du selbstverständlich nur das erste Adressbuch zurückgeliefert, dass session.Addressbooks beinhaltet.


    Wenn Du das Server-Adressbuch benötigst, kannst Du es doch direkt mit Server und FilePath instantiieren.


    Bernhard

    Ich weiss nicht, ob Armin a.k.a. CosMag hier noch einmal hereinschaut (bei AtNotes hat er sich gleich wieder abgemeldet), aber einen Diskussionsbeitrag ist die Geschichte doch noch wert:


    Das "gemeine Doppel- oder Multiposting" geht meist für alle Seiten nach hinten los, wenn man es nicht richtig angeht (dazu unten mehr).


    Zunächst die Wirkung auf die Hilfsbereiten:
    - Diese opfern ihre Zeit (An "dnotes", diese ist bei nahezu allen guten Leuten sehr knapp bemessen, und wenn man dann noch idealistisch und hilfsbereit ist ...), und dann stellen sie ggf. fest, dass eine Frage bereits in einem anderem Forum geklärt wurde und sie von diesem Thread nichts wussten ... Purer Frust: "Warum habe ich meine Zeit vergeudet!"
    - Es erwächst der Eindruck, dass ein Multiposter die Mitglieder eines Forums eigentlich für zu doof hält (oder dies zumindest in Erwägung zieht), seine Frage zu beantworten. Auch das ikst frustrierend.
    - Was würde passieren, wenn Kollege X um 11 Uhr so nacheinander durch fünf Büros marschiert und fünf Kollegen fragt: "Du, ich habe heute von 12 bis 14 Uhr eine Telefonkonferenz. Könntest Du mir vielleicht einen Döner mitbringen?". In solch einer Situation haben wir wenigstens noch die persönliche Konfrontation: Spätestens der freundliche Kollege B, der als zweiter den Döner anschleppt, wird Kollege X ordentlich die Meinung geigen!


    Jetzt aber die Auswirkung für den Multiposter selber:
    Das ist ganz einfach: Sowie solch ein Multiposting bekannt wird, wird sich niemand mehr mühen - jemand anderes könnte ja längst die Lösung geboten haben ... Schade um die Zeit. Das ist genau das, was wir derzeit in diesem Thread erleben und in anderen Threads (egal in welchem Fachforum) bereits erlebt haben.
    Der Multiposter erlebt also: "Wer sich selber eine Grube gräbt ..."


    Genau deswegen steht zum Thema "Multiposting" eine dicke Warnung in jedem Forum in den Nutzungsbedingungen bzw. -hinweisen.


    In wirklich wichtigen Fällen können Multipostings selbstverständlich dienlich, erforderlich und korrekt sein! Die einzigsten Anforderungen: Es muss wirklich wichtig sein (was interessiert uns, dass der Manager X seine Mails in grüner Farbe schreiben will?), und alle müssen auf die jeweiligen Threads in den Foren hingewiesen werden. DAMIT hat dann keiner mehr ein Problem!


    Mein Fazit: Multiposts sind sowohl undurchdacht als auch egoistisch - sofern man nicht alle Beteiligten gleich informiert.


    Euch allen wünsche ich jetzt ein frohes Osterfest und richtig ruhige und erholsame Tage,
    Bernhard

    Das ist interessant ... Ich habe es eben gerade nochmals getestet: $AutoForward fehlt, der Rest (wie oben beschrieben) ist vorhanden.
    Was machen wir beide da anders, taurec? Ich schicke Dir gerne einen DB-Container mit solch einem Mail (am idealsten gleich in MayflowerSoftws DocViewer).
    Ich würde mich freuen, wenn wir da dran bleiben könnten.


    Bernhard

    Jetzt wird's interessant: Im ausgehenden Mail gibt es RecNoOutOfOffice, und im empfangenen wird daraus $AutoForward = "1".
    Im gesendeten Mail gibt es noch einen Unterschied: tmpImp2 ist auf "2" gesetzt.


    Warum der Router das allerdings nochmals umsetzt, wo es doch sowieso "in der Familie" bleibt, ist mir noch ein Rätsel. Dass er umsetzt, ist aber sicher, und aus meiner Sicht wäre damit doch RecNoOutOfOffice zu setzen (damit der Router sein Futter hat).


    Bernhard

    Auf den ersten Blick scheint es zunächst, dass bei derartigen Mails das Item RecNoOutOf Office auf "1" gesetzt wird. Tatsächlich werden aber weitere Items belegt:
    $devopt_basic_moods = N
    $Moods = N
    DeliveryReport = B


    Diese scheinen aber lediglich durch die Aktionen in der Dialogmaske für die Zustelloptionen gesetzt zu werden.
    Zudem ist RecNoOutOfOffice offensichtlich Notes-proprietär.


    HTH,
    Bernhard

    Die Sumierung ist an den kompletten Ansichtsindex gebunden. Bei einer single category embedded view: No way.
    Du kannst aber on the fly die Summe aus den betreffenden Dokumenten berechnen und in Deiner Maske in einem Feld darstellen.


    Bernhard

    Noch ein Unterschied: Die Vererbungen fehlen.


    Da hat nur jemand fleissig level 1 der Klassenstruktur aus der DesignerHelp abgepinselt ohne jeglichen erkennbaren Mehrwert. Und das noch nicht mal korrekt - NotesRichTextTab sortiert sich dort auf einmal unter RichTextTab ein. Was ggf. noch fehlt, mag ich jetzt nicht prüfen.


    Wo dann noch die schnellere Findgeschwindigkeit sein soll: Keine Ahnung.


    Bernhard

    In der LOG.NSF sollten da noch weitere Informationen stehen (wenn der log level nicht zurückgesetzt wurde). Schau dort nochmal nach (vor allem, ob da etwas steht von "rejected by policy reasons").


    Dass Ihr auf einer Blacklist gelandet seid, ist durchaus denkbar (betreibt Ihr unwissentlich einen open relay? Wurde das sicher überprüft?). Der MX-Record könnte auch falsch sein. Hat das Versenden an die problematischen Adressen den schon einmal korrekt funktioniert?


    Bernhard

    Man darf hieraus aber nicht den Schluss ziehen, dass die Formelsprache tatsächlich NULL kennt. Vielmehr erfolgt der Vergleich mit dem Inhalt der (angeblichen) Variablen NULL. Da es diese nicht gibt, ist sie leer, und daher ...
    Die Syntax, wie sie beispielsweise taurec gepostet hat, ist also die sauberere (denn wehe, jemand käme auf die Idee, eine Variable oder ein Feld mit NULL zu benamsen.


    Bernhard