Benutzeraktion "Save and File...": Ordner wird immer wieder erstellt...

[Tode]

Ich habe hier ein sehr seltsames Phänomen, das ich mir nicht wirklich erklären kann:
Es werden immer wieder eingehende Mails in einen Ordner geschoben.

Soweit so gewöhnlich: Eine Regel scheint das zu tun (obwohl es weder ein Regeldokument noch ein Eintrag in den $Formula- Items des Kalenderprofils dafür gibt, das einen Hinweis darauf geben könnte).

Jetzt kommt das ungewöhnliche: Wenn man den Ordner löscht, dann wird er wieder neu angelegt... Und das macht normalerweise eine Regel NICHT, das macht eigentlich nur der Script- Befehl "MoveToFolder" mit entsprechendem Parameter....

Jetzt habe ich den Ordner umbenannt statt gelöscht... Dann werden die Mails in den umbenannten Ordner zugestellt (wobei ich ihm den alten Namen als Alias gegeben habe, das könnte also durchaus die Ursache sein)...

Hat jemand ne Ahnung, was das sein könnte? Agenten habe ich jedenfalls in der Datenbank keine gefunden...

[koehlerbv]

Passiert das Neuanlegen des Ordners oft genug, so dass man aus dem Erstelldatum des Designelements und das Agent-Log der in Frage kommenden Dominos evtl. über die Uhrzeit auf einen Agent schliessen könnte? AgentEZ wäre dann ggf. auch hilfreich ...

Bernhard

[Tode]

agentEZ habe ich schon angeschmissen: Es gibt keinen Agenten, der sowas verursachen könnte. Aber ich habe jetzt einen Verdacht: ich habe mir die Mails in dem Ordner mal angeschaut, und es sieht so aus, als ob die Mails manuell editiert werden, nachdem sie eingegangen sind. Und dabei bekommen sie ein "tmpSendandFileFolder", und in dem steht der falsche Ordnername... in diese Richtung ermittle ich mal weiter...

[Pfefferminz-T]

Regeln könntest Du ausschliessen, indem Du auf dem Server den Parameter DEBUG_MONITOR=32 setzt. Dann wird in die eingehende Mail ein Feld $FilterBy geschrieben, in dem die ausführende Mailregel geschrieben wird.

Könnte die Manipulation auch von einem Agent in einer anderen Datenbank oder einen 3rd-party-Server Task kommen?

[Tode]

Super Tipp, das mit dem DEBUG_MONITOR...

Natürlich könnte auch ein Agent in einer anderen Datenbank das verursachen, aber wie gesagt: ich habe mit agentEZ den ganzen Server abgesucht und keinen Agenten gefunden, der auch nur den Anfangsverdacht erfüllt, er könnte verantwortlich sein (auf dem Server laufen zum Glück praktisch keine Applikationen, und die 70 Agenten, die aktiv sind, waren recht schnell geprüft)...

EDIT: Mist... ich sehe grade, ich bin aus Versehen im 9er Bereich gelandet. Könnte ein Admin das mal in den 8er Bereich verschieben? Es handelt sich nämlich um 8.5.2 Server und 8.5.2er Mailtemplates (der Kunde hat keine Subscription mehr)

[koehlerbv]

Hat da jemand die "File and Send" Action missbraucht? Die Ergebnisse im Analyzer sind im Original auch überschaubar, das sollte sich finden lassen, vor allem in Verbindung mit dem bekannten Foldername.

Bernhard

[Tode]

Ich muss mit den Benutzern sprechen...

Im Übrigen bin ich hier gerade auf etwas gestossen, da müsste man eigentlich einen Call bei IBM aufmachen:
Wir haben in letzter Zeit doch häufiger Views gefunden, bei denen die Items $Name und $Title auseinanderlaufen.
Ich habe gerade einen sehr einfachen Weg gefunden, das mit einem 9.0.1er Designer zu provozieren: Einfach mit F2 oder durch langsamen Doppelklick einen Ordner in der Ordnerliste umbenennen: Dann wird zwar das $Title- Item geändert, das $Name- item bleibt aber auf dem alten Namen. Wenn man den Ordner dann im Designer öffnet und einmal neu speichert, wird das "gerade gezogen", ebenfalls wenn man direkt im Client umbenennt, tut man das nicht, hat man den Verhau...

[koehlerbv]

Ich habe gerade einen sehr einfachen Weg gefunden, das mit einem 9.0.1er Designer zu provozieren: Einfach mit F2 oder durch langsamen Doppelklick einen Ordner in der Ordnerliste umbenennen: Dann wird zwar das $Title- Item geändert, das $Name- item bleibt aber auf dem alten Namen.

Das erklärt insbesondere in einem der Fälle sehr viel. Vor allem, wenn man einen hierarchisch oben stehenden Folder umbenennt und dann unten drunter der Verhau automatisch fortgesetzt wird - und dann versucht, auf dem selben Wege weiter unten wieder Ordnung in die Wirrnis zu bringen.

"Wenn Dir sovoel Gutes wird beschert, ist das bei IBM 'n Einspruch wert!"

Danke, Torsten.

Bernhard

[Tode]

Ich wärme den Thread hier nochmal auf: Letzte Erkenntnis ist: Es wird durch eine Benutzeraktion "Save and File..." auf einem der Clusterpartner verursacht: Die Mail wird zur besseren "Wiederfindbarkeit" mit einem sprechenden Subject versehen (es handelt sich um eingehende Faxe mit einem Standard- Subject), und bei einer bestimmten Benutzerin kommt es immer mal wieder vor, dass der Ordner wieder erstellt wird, wenn Sie auf dem Clusterpartner2 arbeitet...

Jetzt mal eine Frage: Kennt Ihr eine EInstellung, mit der sich der NotesClient den letzten Order merkt, den man bei "Save and FIle" oder "Send And File" ausgewählt hat?

[Andrew Harder]

Meines Wissens gibt es hierfür keine Einstellung.
Aber: Im jeweiligen Dokument merkt sich der Notes Client bei beiden Buttons den Ordner im Dokument und benutzt dabei das gleiche Feld.

Code

FIELD tmpSendandFileFolder := @PickList([Folders]:[Single];"":"");

Mit einer Ansicht kannst Du bestimmt das bauen was Du möchtest

[WildVirus]

Ich hab grad mal in meine Notes.ini geschaut, da gibt es einen Parameter

ATCOMMANDFOLDER_FOLDER_NAME

Da stand ein Ordnername bei mir dahinter. Habe dann eine Mail in einen anderen Ordner verschoben und siehe da, jetzt steht der neue Ordnername dort. Allerdings nicht über "Senden und Ablegen", sondern über "In Ordner verschieben".

Dabei fällt mir ein, gab es nicht früher mal eine Funktion, dass ich als Absender dem Empfänger einer Mail (als noch Kategorien üblich waren) die von mir gewählte Kategorie in einem $......-Feld mitgeben konnte. Evtl. geht das auch für Ordner.

Wird die Mail jungfräulich erstellt oder über eine Vorlage ? Welche $Felder sind gesetzt ?

Ist nur eine Idee, hab die Infos zu der alten Funktion leider nicht mehr gefunden.

CU,
Axel

[Tode]

Inzwischen habe ich die ini des Betroffenen Benutzers bekommen, und der INI- Eintrag ist nicht vorhanden. Dass die Dokumenten das Feld "tmpSendAndFileFolder" mit dem falschen Ordnernamen hatten, habe ich ja bereits geschrieben. Es handelt sich bei den Mails um eingegangene Faxe (Usermanipulation auf Absenderseite kann ich hier also ausschliessen), die vom Empfänger bearbeitet werden, um das Subject sprechender zu machen und dann per Save and File abgelegt werden... Und dabei kommt es eben immer wieder zum erstellen des fehlerhaften Ordners... Eines hatte ich bisher vergessen, sehe ich gerade: der User will die Mail im Ordner "c. Test" ablegen, der auch existiert. Aber die Mail landet in "c. test81", der scheinbar durch genau diese Aktion angelegt wird...

[Tode]

UPDATE: Also wir haben das mal weiter runtergestrippt und jetzt die von Andy gepostete Zeile im Button "Save and File..." in Verdacht:

Code

FIELD tmpSendandFileFolder := @PickList([Folders]:[Single];"":"");

Ich fürchte, dass der @Picklist- Befehl die beiden Zahlen dazu"mogelt"...

Der Client ist 8.5.2 wie gesagt. Ich habe allerdings keinen Bug- Report gefunden, dass @Picklist "seltsame" Dinge tut.

Nur nebenbei: Die Zahl hat sich in der Zwischenzeit geändert... Früher wurde immer der Ordner "Triage80" angelegt, jetzt heisst der Ordner "Triage81".

Könnte es was damit zu tun haben, dass -aus irgendeinem obskuren Grund- Die Anzahl ungelesene Dokumente in den Ordnernamen mit "reingerechnet" wird? Denn das würde von der Zahl ungefähr stimmen...

Noch was: Bei der Benutzerin, die bisher unsere "Hauptverdächtige" war, haben wir bookmark, desktop, cache und workspace- Verzeichnis weggelöscht... Und noch am gleichen Tag wurde der Ordner wieder angelegt... von einem ANDEREN Benutzer... Also der Verdacht, dass es irgendwas am Client selbst ist, scheint sich auch nicht zu bestätigen...

So langsam bin ich wirklich ratlos.