Das Notes Forum

Domino 9 und frühere Versionen => ND8: Entwicklung => Thema gestartet von: Glombi am 15.10.13 - 14:36:22

Titel: Programmatisch erzeugte Mails nicht in Inbox anzeigen
Beitrag von: Glombi am 15.10.13 - 14:36:22
Hallo zusammen,
gibt es eine Möglichkeit, eine Mail (in diesem Fall ein Kalendereintrag) an eine Maildatenbank programmatisch zu senden, so dass diese nicht in der Inbox angezeigt wird?
Vielleicht gibt's ein Systemfeld, dass der Router auswertet.

Da es beliebige Maildatenbanken als Empfänger gibt, scheidet eine Mailregel aus.

Danke für alle sachdienlichen Hinweise!

Andreas
Titel: Re: Programmatisch erzeugte Mails nicht in Inbox anzeigen
Beitrag von: Klafu am 15.10.13 - 15:20:22
Hallo Andreas,

vielleicht hab ich dein Anliegen nicht ganz verstanden aber eine Mailregel ist keine Alternative, oder?



Bitte ignorieren. War wohl grad nich ganz bei der Sache  :-\
Chris
Titel: Re: Programmatisch erzeugte Mails nicht in Inbox anzeigen
Beitrag von: marschul am 16.10.13 - 09:02:39
Hallo Andreas,

um das einfach per Parameter oder Zusatzfeld abzufangen, ist mir nix bekannt.
Da würde vermutlich nur das Umgehen des Routers bleiben, sprich: Kopieren der Dokumente direkt in die Ziel-DBs. Falls durch das Mailrouting generierte Felder benötigt werden, könnte man per Server-Mailregel entsprechende Mails (z.B. identifizierbar aufgrund eines bestimmten technischen Absenders) in eine separate DB umleiten, um sie anschließend von da aus per Agent zu verteilen. In die Kategorie eben mal schnell und ganz einfach passt das allerdings nicht mehr ;)

Titel: Re: Programmatisch erzeugte Mails nicht in Inbox anzeigen
Beitrag von: Glombi am 16.10.13 - 09:34:37
Ja, das direkte Erstellen in der Mail-DB klappt auch, setzt aber voraus, dass die Rechte in der ACL passen.

Es hätte ja sein können, dass es ein Systemfeld gibt, das der Router auswertet.

Andreas
Titel: Re: Programmatisch erzeugte Mails nicht in Inbox anzeigen
Beitrag von: Andrew Harder am 16.10.13 - 11:55:24
Ist machbar, man müsste nur:
1. ein neues Feld einführen
2. Dieses in einem entsprechend getriggerten Agenten abfragen und entsprechnde Dokumente mit einem
Code
RemoveFromFolder("($InBox)")
wieder rausnehmen.

Da eine Mailregel nicht in Frage kommt, gehe ich aber davon aus, das ein ausrollen eines Agenten in die Mailfiles der User wahrscheinlich keine Alternative darstellt?
Titel: Re: Programmatisch erzeugte Mails nicht in Inbox anzeigen
Beitrag von: CarstenB am 22.01.14 - 16:16:53
Hallo Andreas,
hast du eine Lösung für dein Problem gefunden?

Ich stehe vor der gleichen Aufgabenstellung, da ich in fremden Mail-DBs Kalendereinträge anlegen muss, auf die dem aktuellen User aber die Schreibrechte fehlen.

Gruß
Carsten
Titel: Re: Programmatisch erzeugte Mails nicht in Inbox anzeigen
Beitrag von: Andrew Harder am 22.01.14 - 23:34:12
Sorry, das ich dazwischen funke, aber ich hätte da eine Anmerkung und eine Frage dazu.

Anmerkung:
Routerfeld gibt es wohl leider keines - korrigiert mich wenn ich da Mist schreibe.
Das wäre mal eine Anregung an IBM. Namen hätte ich auch schon eine Idee ;)

Fragen:
Erstellst Du die Mail selbst per Script?

Falls selbst angelegt, könnte man das per Agent lösen.

Code
Sub Initialize
 ' pre-delivery agent
  Dim session As NotesSession
  Dim doc As NotesDocument
  Set session=New NotesSession
  Set doc = session.DocumentContext
  If doc.HasItem( "PreventInbox" ) then
    Call doc.RemoveFromFolder( "($Inbox)" )
  End If
End Sub

Dann muss halt ein Feld "PreventInbox" beim anlegen der Mail/des Kalendereintrag angelegt werden, bevor man das Dokument absendet.
Titel: Re: Programmatisch erzeugte Mails nicht in Inbox anzeigen
Beitrag von: koehlerbv am 23.01.14 - 01:05:38
Warum eigentlich so kurz gesprungen? Wenn schon ein C&S Schema-korrektes Dokument erzeugt werden kann, warum kippt man dies nicht einfach in eine spezielle DB, die nichts (keine Ansichten, keine Masken, nur einen Agenten) enthält und in der die lieben User wie in der MAIL.BOX nur Einlieferer sind?
Ein braver Agent in dieser DB schaut dann im entsprechenden Item der zugeliferten Dokumente nach, welcher Mail-DB das Teil einzukopieren ist und nach überprüften Volltreffer wird das Dokument dann sofort aus dieser Helferlein-DB reseziert.
Somit passen die Rechte (der tapfere Agent ist entsprechend signiert) und der Router darf / braucht nicht mehr mitzuspielen.

Bernhard

PS: Zumindest einschaltbar würde ich natürlich protokollieren, was der 007 so treibt, daher also doch Maske(n) und Ansicht(en).
Titel: Re: Programmatisch erzeugte Mails nicht in Inbox anzeigen
Beitrag von: CarstenB am 23.01.14 - 13:37:47
@Andrew:
Ja, die Einträge erstelle ich per Script. Ein Feld hinzuzufügen wäre also möglich. Der Agent müsste ja in der Mail-DB laufen. Bin mir nicht sicher, ob wir das machen wollen, da die Funktion auch nur für einen Teil der User benötigt wird.

@Bernhard:
Der Vorschlag über ein zentrale DB zu gehen, wo das ganze per Agent weiterverteilt wird klingt gut! Vielen Dank dafür.

Alternativ überleg ich noch, ob ich nicht die Mailregeln per Script anlege. Könnte ggf. die schnellste Lösung sein.
Titel: Re: Programmatisch erzeugte Mails nicht in Inbox anzeigen
Beitrag von: CarstenB am 23.01.14 - 15:12:17
Alternativ überleg ich noch, ob ich nicht die Mailregeln per Script anlege. Könnte ggf. die schnellste Lösung sein.

Unsinn, was ich zuvor geschrieben habe... habe gerade festgestellt, dass mich Mailregeln gar nicht weiterbringen würden, da es dort die Aktion "aus Ordner entfernen" gar nicht gibt.
Titel: Re: Programmatisch erzeugte Mails nicht in Inbox anzeigen
Beitrag von: Andrew Harder am 25.01.14 - 01:21:15
Ich kann mich noch dunkel an ein Ticket erinnern, in dem ein User sich beschwert hatte, das einige Mails nicht im Eingang waren, sondern nur unter Alle Dokumente sichtbar waren.
Grund war damals eine Mailregel gewesen, die fleißig versucht hatte die Mail in einen Ordner zu schieben, den der User irgendwann einmal gelöscht hatte.

Ist aber eine unsichere Sache, sobald IBM das mal in den nächsten Jahren merkt und den Router das prüfen lässt, würde der Trick nicht mehr gehen.

Das nur als Info, nimm lieber die Lösung von Bernhard, die ist zukunftssicherer.