Abgelehnte Einladung: Wo wird die Information gespeichert?

[Tode]

Vielleicht weiß es ja jemand, sonst muss ich Googeln:

Wenn ich eine Einladung ablehne und der Einladende diese neu plant, dann bekomme ich ja keine Information mehr, es sei denn, ich habe das Häkchen gesetzt, dass ich informiert bleiben will.

WO wird diese Information gespeichert? Denn in den "Recipients" und allen anderen Feldern beim Chair bleibt der Name desjenigen der ablehnt stehen, und Ytria zeigt mir kein Feld, in dem der Name, der abgelehnt hat, drin steht...

Hintergrund: Ein Mitarbeiter hat sich beschwert, dass er eine Einladung nicht erhalten hat. Wir haben geprüft: Er steht in den Recipients und HÄTTE sie erhalten müssen, in der Mailverfolgung sehen wir aber, dass er die Mail nicht erhalten hat. Es handelte sich um eine Neuplanung, deshalb unser Verdacht, dass der Mitarbeiter die erste Planung abgelehnt hatte, ich würde das aber auch gerne irgendwie belegen können...

[Driri]

Ich würde vermuten, daß Notes das wie beim Status der eingeladenen Personen auch über die Antworten verwaltet.

Aber vermuten != wissen, sorry. 

[byte]

vielleicht hilft dir das weiter ?

http://www-01.ibm.com/support/docview.wss?uid=swg21454780

bzw

https://www-10.lotus.com/ldd/ddwiki.nsf/dx/cs_schema_workflow

https://www-10.lotus.com/ldd/ddwiki.nsf/dx/cs_schema_glossary#$CSFlags

NoticeType   Text   Type of notice being sent. While the data type is for a string, only the first character of this item is used for determining what kind of notice it is.

For R&R in R7 or later, the only valid values to use are ‘I’ on the initial invitation or ‘U’ on an update / reschedule notice. The Rooms & Resource Manager will handle changing it when the request is processed.

Valid values are:
A = User accepted request
B = Chair has accepted a counter proposal
C = Chair cancelled event
D = User is delegating request; sent to Chair
E = Participant would like fresh copy of event. Notice is refreshed info from Chair or Update info from Chair.
When participant is requesting info, the $CSFlags contains ‘r’. When Chair is responding to request, the $CSFlags contains ‘u’.
If Chair is merely sending an update, $CSFlags will not contain either of these flags.
F = User has completed request
G = User wants to add event to calendar (may not be stored on disk, only in memory use.)
H = User is deleting event
I = Invitation request
J = Chair declines a counter-proposal request
K = Chair is sending updated info to all invitees
L = User is delegating request; Notice is sent to delegee
N = Event is being confirmed by Chair
P = User has tentatively accepted the invitation
R = User declined the invitation
S = Status update from Chair
T = User is counter-proposing request
U = Chair has rescheduled the event
W = Waiting for reply from user
X = Placeholder for "Extended NoticeType"; may not be in actual use.
Y = Chair wants to remove rooms/resources
Z = User has been removed (may not be stored on disk, only in memory use.)