HTTP API confirmation details

[sam]

Hi Martin,

as announced elsewhere: I'm hacking a bit the OXtender for TB and one pending issue is getting confirmations work properly. The implementation there (using simply the 'users' array) is pretty broken and might be a historical stuff from ox5 or whatever. Looking at the HTTP API docs in oxpedia, I'm still a bit confused how to do it properly. I see following 3 arrays there:

221 'users': basically list of participant with type and mail

220 'participants': also a kind of participant list, but this time no type info, but with confirmation status and message included

226 'confirmations': hmm, seems like participants but no IDs, just external users ?

Huh ? What is this all about ? Why are there 3 separate arrays, could you please give more detailed explanation ?

Another question: if I try to use action=update and try change the confirmation using e.g. the 'participants' array data, nothing happens (I can change other stuff in update). Are these read-only status data ? If yes, why not getting an error code ?

If I look at the 6.18.1 OX Webclient communication, I see it is using a separate action=confirm request. Is that the only way to change the confirmation in OX6 ?

An the last one: can appointment owner himself change his confirmation status in OX6 (this is explicitly prevented in OXtender code with a comment about not being possible in OX6 - which I do not believe) ?


Thanks a lot.

[Viktor Pracht]

• 'participants' is the list of participants as entered by the user, with groups, resources etc.
• 'users' is the list of participants who are internal users and can therefore confirm an appointment. It's a separate array because every member of a group listed in 'participants' has their own confirmation status and is therefore listed here separately. Each user is listed at most once.
• 'confirmations' is an extension of the 'users' array to include external users who can now confirm by replying to an iCalendar invitation. It's a separate array to keep the contents of the 'users' array backwards compatible.

Another question: if I try to use action=update and try change the confirmation using e.g. the 'participants' array data, nothing happens (I can change other stuff in update). Are these read-only status data ? If yes, why not getting an error code ?

Changing 'participants' should work. That's the normal way to invite and uninvite somebody. Are you sure the appointment is not changed? What does the JSON request looks like?

If I look at the 6.18.1 OX Webclient communication, I see it is using a separate action=confirm request. Is that the only way to change the confirmation in OX6 ?

For all practical purposes, yes. Changing the 'users' array may have worked sometime in the past, but the semantics were never fully defined and it did not support confirming appointments in shared folders.

An the last one: can appointment owner himself change his confirmation status in OX6 (this is explicitly prevented in OXtender code with a comment about not being possible in OX6 - which I do not believe) ?

Actually it's the opposite: Users can normally change only their own confirmation status. In addition, when confirming an appointment in a shared calendar, the confirmation is actually in the name of the calendar's owner. This is supported only by the action=confirm interface, and AFAIK the major reason why simply changing the 'users' array is pretty much broken by design.

[sam]

Hi Viktor,

thanks for the explanation. Let me summarize:

[LIST][*]'participants' is the list of participants as entered by the user, with groups, resources etc.

...so this is where I can see all participants (internal, external), but the groups are not decoded into single participants here

[*]'users' is the list of participants who are internal users and can therefore confirm an appointment. It's a separate array because every member of a group listed in 'participants' has their own confirmation status and is therefore listed here separately. Each user is listed at most once.

...ok, so here I actually see all single participant state, but _only_ for internal users, based on userID. The 'confirmation' here is supposed to be a readonly value ?

[*]'confirmations' is an extension of the 'users' array to include external users who can now confirm by replying to an iCalendar invitation. It's a separate array to keep the contents of the 'users' array backwards compatible.

...and here I shall look for the status of all external participants, based on their mail address (instead of ID). Why is here a 'type' attribute included, if here we get only external participants ? The 'status' here is a readonly value ?

Changing 'participants' should work. That's the normal way to invite and uninvite somebody. Are you sure the appointment is not changed? What does the JSON request looks like?

uhm, well changing participants works, but OXtender as it is written by Sebastian used action=update to change the confirmation as well, adding a status value 'confirmation' into the participants array - where it is actually not defined at all. Then I tried to patch this into 'users' but that did not have any effect (silently accepted), not even an error code.

Actually it's the opposite: Users can normally change only their own confirmation status. In addition, when confirming an appointment in a shared calendar, the confirmation is actually in the name of the calendar's owner. This is supported only by the action=confirm interface, and AFAIK the major reason why simply changing the 'users' array is pretty much broken by design.

Well, TB/lightning has a single callback "modifyItem" for any changes in Event dialogue. Including any changes of confirmation. So does this mean, we have to use both the "action=update" and "action=confirm" to save everything ? I also see that doing just "action=update" will likely reset the confirmation status to "CONFIRMED"
by default. Bah, thats gonna be complicated to check for all changes in detail...

[Viktor Pracht]

Yes, the data in 'users' and 'confirmations' should be treated as read-only.

Well, TB/lightning has a single callback "modifyItem" for any changes in Event dialogue. Including any changes of confirmation. So does this mean, we have to use both the "action=update" and "action=confirm" to save everything ? I also see that doing just "action=update" will likely reset the confirmation status to "CONFIRMED" by default. Bah, thats gonna be complicated to check for all changes in detail...

Yes, but only if the confirmation actually changed.
Normally, the changes have to be checked anyway, and only modified fields are sent to the server. This should also prevent unintended changes to the confirmation status.

[sam]

Hi Viktor,

thanks, yes that makes sense. However, it wil be a bit tricky to check all changes in detail in this case... seems like rewriting pretty much of old OXtender code.

But there is still one trouble remaining: if there is an existing appointment and a user has some other status than confirmed (e.g. tentative or canceled). If I now try to change something and send the update to server, the user status is always reset to 'confirmed'. Even if I dont touch the confirmation stuff. Here is e.g. one such action=update request which will lead to reset of confirmation status:

{"title":"test2","start_date":1296806400000,"end_d ate":1296810000000,"location":"bbb","note":"","sho wn_as":1,"private_flag":false,"categories":"","ala rm":-1,"participants":[{"id":"62","type":1},{"id":"66","type":1}],"id":"10496","ignore_conflicts":true}

I mean, if I'm not supposed to touch the participants array here because it did not change, ok, but still it should become 'none' or 'unconfirmed' then and not confirmed by default ?

[Viktor Pracht]

The purpose of confirmations is to ensure that all participants agree on the details of the appointment. Whenever an appointment is changed, the participant performing the change is implied to agree with their own change.

All other participants have agreed to the old version of the appointment, but not to the changed one (e. g. new time, location or agenda). Therefore the server resets all other confirmations.