uidoc.send aus "fremder" Datenbank

[DatenDuck]

Hallo Welt!

Ich habe folgendes Problem beim Versenden von gespeicheten Entwürfen.
Siehe erstmal Code und Beschreibung dann weiter unten.

Code

	On Error Goto Errorhandler
	
	Dim session As New NotesSession
	Dim db As NotesDatabase
	Dim uiws As New NotesUIWorkspace
	Dim uidoc As notesuidocument
	Dim doc As notesdocument
	
	Set db = session.CurrentDatabase
	Set uidoc = uiws.CurrentDocument
	
	uidoc.Document.SaveMessageOnSend = True	
	uidoc.Send
	
	Set doc = uidoc.Document
	Call doc.Save(True,False,True)
	
	Dim ndc As NotesDocumentCollection
	Set ndc = db.GetProfileDocCollection("Güllehülle")
	Call ndc.AddDocument(doc)
	
	doc.SaveOptions = "0"
	Call uidoc.Close(True)	
	
	' ... hier noch x Zeilen weiterer Code - im wesentlichen mit der ndc -  die aber für's Versenden nicht wichtig sind
	
	Exit Sub

Das Problem ist, dass uidoc.Send nur dann funktioniert, wenn dieser Code aus einer Mail-DB aufgerufen wird in deren Vorgaben der aktuelle Benutzer als Besitzer eingetragen ist.
Wird der Code in einer DB ausgeführt in der der User nicht der Besitzer ist (also eine Mail DB die über entsprechende ACL Settings freigegeben ist) dann passiert beim Senden einfach gar nix...
In den Vorgaben wurde auch schon -Default- bei der Deligierung eingetragen, nutzt aber nix. Wird der Besitzer testweise geändert funktioniert das für den neuen Benutzer plötzlich, bis er eben wieder nicht mehr Besitzer ist.
Die Sache läuft auf unterschiedlichen Servern und mit unterschiedlichen Clients nicht.
Das ganze tritt wie gesagt nur mit gespeicherten Entwürfen auf. Wird ein Memo frisch erstellt und über den selben Code sofort versandt dann läuft alles wunderbar (für alle user).

Kann mir hierbei jemand helfen?

Vielen Dank schon mal.

Viele Grüße,
-Moritz

[koehlerbv]

Dein Problem ist das NotesUIDocument(.Save), Moritz. Du löst damit all die damit verknüpften Events der Mail-DB aus, die eben genau das von Dir beobachtete bewirken (schau Dir einfach an, was beim betreffenden Event passiert).

Willst Du Dich vom UI der Datenbank lösen, musst Du das Backend verwenden, dann aber auch sauber das (nach-)programmieren, was Du an Drumherum noch benötigst.

Bernhard

[DatenDuck]

Hallo Bernhard,

ich save doch gar nicht vom UIDoc?!

[koehlerbv]

Sorry, was ein Schreibfehler meinerseits - ich meinte natürlich Send.

Bernhard

[DatenDuck]

Hallo Bernhard,

sorry, so ganz verstehe ich Deinen Hinweis immer noch nicht.
In der Maske ist nur im QuerySend folgender (unveränderter) Code:

Code

Sub Querysend(Source As Notesuidocument, Continue As Variant)
	If(source.Document.HasItem("ActionInProgress")) Then
		source.Document.RemoveItem("ActionInProgress")
	End If 
End Sub

Die Designer Hilfe sagt mir zur UIDoc.Send Methode auch nicht wirklich viel mehr außer "Mails a document"...
Mich irritiert die Tatsache, dass das alles funktioniert, sobald man Besitzer der DB ist...
Im Backend arbeiten würde bedeuten den "Send" Mechanismus den es schon gibt neu zu erfinden und das finde ich irgendwie nicht sinnvoll.

[DatenDuck]

Hallo Bernhard, bzw. Welt,

ich tüftele nach wie vor an dieser Problematik rum und ich hätte noch mal eine Frage.
Diese ganze "Besitzer" Sache ist doch im Grunde nur eine besondere Eigenschaft einer Mail Datenbank oder!?
Das heißt, im Grunde ist das keine wirkliche Erweiterung des Notes Berechtigungskonzept (da gibt es ja keine Besitzer) sondern ein paralleles Feature das bei bestimmten Situationen in Anspruch genommen wird. Im konkreten Fall z.B. dafür um die "gesendet im Auftrag von... " Eigenschaft eines Memo-Dokuments zu füllen.
Ich frage mich jetzt, wieso das dazu führt, dass eine Standard LotusScript Methode in diesem Sonderfall nicht mehr funktioniert!? Ein Entwurf ist ja so gesehen auch kein „besondereres“ Notes Dokument als ein normales Dokument, nur dass es halt in einem besonderen Ordner liegt!?
Liege ich mit meinen Gedanken denn einigermaßen richtig oder gibt es eine plausible Erklärung dafür, dass bei unterschiedlichen Besitzern bestimmte Methoden nicht genutzt werden können bzw. mit „Entwurfsdokumenten“ nicht durchgeführt werden können?
Versenden kann man ja jedes beliebige Notes Dokument und wieso verhält sich dieser Mechanismus in Mail-DBs anders als in anderen DBs?

[koehlerbv]

Hallo Moritz,

jo, das Verhalten liegt oder läge an der Mail-DB - hier ist nichts hardcoded.

Da Du hier im 7er Forum schreibst: Der QuerySave-Code, den Du postest, ist aber nicht der originale - da fehlt ein Teil.
Der fehlende Teil erklärt aber auch nicht das von Dir vorgefundene Verhalten.

Ich hoffe, ich finde am Wochenende Zeit, mir die Sache mal selbst vorzunehmen. Was ich aber bisher noch nicht verstehe, ist Deine Ablehnung der Backend-Methode Notes.Document.Save: Was meinst Du da gross nachprogrammieren zu müssen?

Bitte erinnere mich per Mail, wenn ich nicht alsbald dazu komme, mit Dein Problem genauer vorzunehmen.

Bernhard

[DatenDuck]

Hallo Bernhard,

der Code den ich gepostet habe ist alles was ich in der Schablone gefunden habe.. Scheinbar dann keine Originalschablone, was mich etwas irritiert und bei Zeiten dazu bringen wird mal mit ner echten 7er Schablone zu testen!
Noch ne Gegenfrage zu Deinem "Deine Ablehnung der Backend-Methode Notes.Document.Save". Meinst Du jetzt sicher Save, oder doch wieder Send?  Gegen Backend Save habe ich nix und wird ja im Code auch schon gemacht. Gegen Backend Send habe ich insofern was, als dass ich ja dann komplett selbst prüfen muss ob das doc versendbar ist und es nach dem Senden dann entsprechend verschieben muss usw. usw.

[koehlerbv]

Moritz, ich sollte mich aus diesem Thread zurückziehen, da er offensichtlich und unverständlicherweise bei mir sofort eine geistige Umnachtung auszulösen scheint ... Natürlich schrieb ich wieder "Save" und meinte "Send".

Noch ein Satz dazu: NotesUIDocument.Send (Send! Send! Send! Nicht Save! Wirklich nicht!) hat doch noch nichts mit verschieben etc. zu tun, sondern macht unterm Strich nichts weiter wie ein NotesDocument.Send (ha - ich habe die Kurve gekriegt  ) - ausser, dass es noch das entsprechende Event der Maske triggert.

Ich hoffe, ich finde Zeit, mir das wirklich demnächst mal am praktischen Fall vornehmen zu können.

Mea culpa,
Bernhard

[pram]

Was spricht dagegen, das Backenddokument zu versenden?

(Bei der Mailschablone erinnere ich mich irgendwie an DWA oder FormsX.nsf, welche bei manchen Sachen "reinpfuschen", aber das ist glaub ich nur im Web)

Gruß
Roland

[DatenDuck]

Backend finde ich unpraktisch. Die ganze frontend Validierung muss erfolgen (also ob Empfänger, CC oder BCC angegegeben sind usw.). Das Dokument muss gespeichert werden und wenn es nicht versendet werden kann, manuell gelöscht werden.
Die Rückmeldung, dass der Empfänger fehlt usw. muss selber gebaut weden.

uidoc.send macht das alles für mich.

[pram]

Hmm, stimmt, das hatte ich vergessen, darum machen wir alle Checks und Berechnungen soweit es geht im Backend.
<werbung>Würde die Mail-DB FOF ( http://fof.foconis.de ) verwenden wär das nicht passiert.  </werbung>


Aber nun noch was konstruktives (wenns auch nur Vermutungen sind)

Könnte es sein, das das entsprechende Dok aufgrund der ACL-Einstellungen nur lesbar ist.
AFAIK wird ein Dokument beim Senden gespeichert.
1. kann man das Dokument speichern? (ich tippe stark darauf, dass der Benutzer nur Autor ist, aber nicht im Autorenfeld des Doks steht)
2. Kannst du dies mal debuggen und schaun ob er beim uiDoc.send in die entsprechenden Events springt (wirst schon gemacht haben, evtl ist aber noch wo ein "on error resume next" versteckt, so dass auch keine Fehlermeldung kommt)
3. Kannst du das Backenddokument mal zum Test versenden

Gruß
Roland

[koehlerbv]

Roland, ein Dokument wird mit NotesUIDocument.Send nicht gespeichert.
Weiters gibt es normalerweise keine Autorenfelder in Memos oder Drafts.
Und wenn nicht etwas in der DB total im Eimer ist, dann werden natürlich die entsprechenden Events getriggert.

Der Hinweis auf das FOF ist zudem hier völlig deplaziert.

Bernhard

PS: Werbung kann auch nach hinten losgehen, wenn sie im falschen Kontext steht. Und hier stand sie im falschen Kontext (Deiner Mutmassungen) 

[pram]

Hallo Bernhard,

ja das mit Send/save is so ne Sache, da verwechselt man gern mal was 
Fakt ist aber, dass beim Senden einer Mail (durch Klick auf dem Button) diese gespeichert wird. Da steht bei mir folgender Code drin:

Code

MEMO_SEND:="1024";
FIELD ActionInProgress:=MEMO_SEND;
@If(@Command([FileSave]);@Command([FileCloseWindow]);@Return(""))

Evtl löst ein fieldSettext und anschließender save das Problem ja.

Ein $keepPrivate Feld kann übrigens das Senden auch verhinden. (Es sollte aber dann eine entsprechende Meldung kommen)

Was mich aber wirklich wundert (obwohl bei Notes wundert mich manchmal gar nichts mehr) ist, dass das Event beim uiDoc.send nicht ausgelöst wird und dass laut OP auch kein Fehler auftritt.

Gruß
Roland

[DatenDuck]

Hallo Leute,

also der Debugger verhält sich folgendermaßen:
- Bis zum uidoc.send alles OK
- Beim Aufruf von .send springt der Debugger in den Memo.QueryOpen Event, der aber im Debugger leer dargestellt wird. (Warum leer umd warum QueryOPEN?)
- Beim nächsten Sprung steht er gleich am Ende der If Schleife im Memo.QuerySend Event.
- Beim nächsten Sprung lande ich im Debugger in einem leeren Event der Memo Maske!?!
Danach ist die Ausführung beendet und der gespeicherte Entwurf nicht versandt.
Öffne ich den Debugger dann für irgend einen anderen Code (z.B. beim schließen des Fensters ohne zu speichern) ist der untere Bereich des Debuggers (Variables Tab) komplett zerschossen und der Text steht kreuz & quer in dem Bereich.
Dieses Verhalten ist in R7 und in R8 relativ ähnlich (zu der "Zerschossenheitsgrad" weicht etwas ab)

[DatenDuck]

Hallo Forum,

ich wollte nur mal schnell eine Erfolgsmeldung zu dieser Sache bekannt geben!
Das Problem beim Versenden eines in einer "fremden" Datenbank gespeicherten Entwurfs lag an einem Feld "MailOptions" das mit dem Wert 0 in den gespeicherten Entwürfen existiert...
Ich checke nun ob es sich beim Versenden um ein neues Dokument oder einen gespeicherten Entwurf handelt und im Falle eines Entwurfs entferne ich das MailOptions Item.
Der ursprüngliche Code funktioniert dann auch für Entwürfe so problemlos wie für normale Mails (und das sowohl in der eigenen also auch fremden Datenbanken).

[koehlerbv]

Danke für die Rückmeldung, Moritz.

Verblüffend ist das aber schon, denn MailOptions hat ja eigentlich gar keinen Bezug zum aktuellen Benutzer oder Besitzer der Mail-DB. MailOptions = "0" bedeutet eigentlich immer: "Nicht senden".

Bernhard

[DatenDuck]

Noch verwirrender ist ja auch, dass das serienmäßige senden eines Entwurfs schon immer funktioniert hat (und ich denke MailOptions=0 war auch schon vorher in den Entwürfen)

[koehlerbv]

Rischtisch. Da müsste man jetzt im Code der entsprechenden Events des betreffenden Mail-Designs forschen ... Auf jeden Fall ist das hier offensichtlich etwas "schräg" designed (so architekturmässig) ... Es adelt Dich, dass Du dem Verhau trotzdem beigekommen bist!

Bernhard