Where is meeting participant status stored?

HCL Domino Domino Forum
1

Can anyone tell me how Notes derives the meeting participant status when it shows the “View Invitee Status” in C&S. I have a problem that we have made some changes to the code, and suddenly the status of all participants goes back to “No response” after we add a new participant. I cannot find anywhere a field or value where the status is stored. The process of what (OwnerCheckSchedules) does is completely hidden from debugger, so I have no way of tracking where it gets the info from.

All help gratefully received.

2

Subject: where is meeting participant status stored?

Attendee responses are stored as response documents to the original meeting invitation in the Chair’s calendar. Check the Meeting Threads view.

3

Subject: RE: where is meeting participant status stored?

Thanks. I assume you’re talking about the ($Meetings) view (alias Meetings), but nothing changes in the view after I have added a new participant - the responses are still there. However, the status has reverted to “No response” when I do View Invitee Status.

Any other ideas, please?

4

Subject: RE: where is meeting participant status stored?

Without digging into the code, it would appear that you managed to break the link between the original invitation and the responses. I believe that the “View Invitee Status” code works by doing a lookup into that view (or perhaps some other) and reports on all those invitees that have responded, while indicating a “No response” for those invitees for whom a response is missing in the response hierarchy.

All I can suggest to you is to dig around in those views. Perhaps you have broken some link unintentionally.

5

Subject: RE: where is meeting participant status stored?

the responses being the thumbs up and thumbs down emails. click one of these responses open and then go to View > Parent Preview, the meeting that they are attached to should display in the preview pane below it, any errors?

6

Subject: logic is now understood

Thanks for the inputs. The logic is simple - my problem has nothing to do with the views and pointers. After much head-scratching, I’ve figured it out. Here’s how it works …

When creating an invite, SequenceNum=1. Responses from invitees (Accept/reject/whatever) have that same SequenceNum. (Adding new invitees keeps the same SequenceNum. ) Rescheduling increments it by 1. Now, the original doc has a different Sequencenum, so the older responses (other than Reject) are ignored. This is correct, because it means they now have had another chance to accept/reject so earlier response is no longer valid.

It’s all perfectly logical. My bug was that I was bypassing native code and incrementing SequenceNum for pure “add invitee” actions (for a number of other reasons).