Kennst Du das AtNotes-Board zur !HELP!-Applikation?
Da antworten Dir die Macher von !HELP! direkt.
HTH,
Bernhard
Kennst Du das AtNotes-Board zur !HELP!-Applikation?
Da antworten Dir die Macher von !HELP! direkt.
HTH,
Bernhard
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
Schon wieder jemand, der denkt, er sei gaaaaanz wichtig und Doppelpostings schaden ja nicht:
AtNotes
Armin, lies bitte die Forumsregeln. Wenn Dir nicht klar ist, warum Doppelpostings Ärger und Verdruss schaffen, suche hier im Forum nach dem Begriff "Doppelposting".
Bernhard
Ich war mal so frei und habe eine Mail geschickt
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
Nein, das war zu diesem Zeitpunkt noch nicht gesetzt (R6.5.4).
Bernhard
PS: Interessantes Thema, mit dem ich mich zuvor auch noch nie beschäftigt habe.
Ich habe Mails aus einer MAIL.BOX bei einer Arbeitsumgebung ohne direkte Serververbindung herauskopiert - und dort standen die o.g. Items noch drin. Woher hätte ich auch sonst diese Erkenntnis gewinnen sollen?
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
Mit @Command ([FileImport]) hast Du auf dem Server definitiv keine Chance, da kannst Du probieren, was Du willst.
Es geht nur über LotusScript (oder Java).
Bernhard
Neben der Frage von Myron: Ich habe mal einen kurzen Blick geworfen und gleich gesehen, dass eines der wichtigsten Items für das Notes C&S - $BusyName - nicht belegt wird.
Meines Erachtens ist die Idee, mit LS-Code zu dealen, wenn man nach eigener Aussage keine Kennung davon hat, eine äusserst schlechte.
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
Dirk, wir kennen doch beide die Struktur hinter "NSF". Daher: No way.
Wenn Du es nicht explizit auf Dokumentenebene speicherst (und permanent pflegst) oder (erformancefressende MoveToFolder-Operationen in Erwägung ziehst): Es geht nicht.
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
Das geht nicht, da immer nur die in der aktuellen Arbeitsumgebung eingestellte Mail-DB abgefragt wird.
Über neue Dokumente (Mails) in DB 2 könntest Du Dich natürlich per Mail informieren lassen, wobei nun wieder das eingebaute Procedere greift.
Bernhard
Schau Dir mal diese Links an:
http://atnotes.de/index.php?topic=26551.0
Eventuell findest Du Dich gleich mit Hilfe des ersten Links wieder.
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
Wo ist denn der Unterschied zur DesignerHelp? Und die geht dann ja auf Wunsch sofort auch noch tiefer ...
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