Details

Reviewers

Group Reviewers

Commits

rS305b6551edc5: Update our attendee status based on the busyStatus
rSfca289caff4f: Update our attendee status based on the busyStatus
rSeffc8fd2e2a2: Update our attendee status based on the busyStatus
rS5788298e11b7: Update our attendee status based on the busyStatus

Summary

It seems, for outlook the busystate is the attendee state.
This means we shouldn't set STATUS based on it, but we should update our
attendee status.

If we are not an attendee, we have to avoid adding an extra attendee
though.

To get consistent behaviour in both directions, we also set the
busyStatus based on the attendee status, which makes sure that we get
the same result no matter if the webclient or outlook is used to set to
tentative or accepted.

Diff Detail

Repository

rS syncroton

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

mollekopf requested review of this revision.Jul 28 2023, 1:57 PM

mollekopf created this revision.

Harbormaster completed remote builds in B43820: Diff 12827.Jul 28 2023, 1:57 PM

mollekopf added a reviewer: Syncroton Developers.Jul 28 2023, 1:57 PM

I'm afraid that, if an organizer updates his event, this will add organizer as an extra attendee, looking at update_attendee_status() code.

This revision now requires changes to proceed.Jul 28 2023, 2:16 PM

Another thing is the BusyStatus property spec. does not make sense. https://learn.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-ascal/9a37b42c-6762-4d3e-9e05-9c9221a1cd06 Note that the description is different if it is a part of an Exception.

Set the attendee status based on busyStatus, and don't set STATUS in ical.

Harbormaster completed remote builds in B43835: Diff 12833.Jul 28 2023, 4:30 PM

Two notes:

I don't know if this actually needs to be outlook specific
We ignore this whole conundrum in getEntry, but maybe we should be mapping the users attendee status to busyStatus (I'm not aware of a case where it matters though).

In D4481#53852, @mollekopf wrote:

Two notes:

I don't know if this actually needs to be outlook specific

We ignore this whole conundrum in getEntry, but maybe we should be mapping the users attendee status to busyStatus (I'm not aware of a case where it matters though).

It matters when we set the event status to tentative, which will result in a tenative attendance in outlook, and on the next sync the attendee will be marked as tentative as well.