Imagine a user somehow gets hold on a calendar event containing an invite for that user as attendee. Initially, the partstat for that user / attendee is set to NEEDS-ACTION. Now, the following two scenarios should result in same result, but does not:
A: The user uploads the event unchanged, after that the user changes parstat to ACCEPTED and then uploads the event again. In this case, Sabre\VObject\ITip\Broker::parseEvent will generate an iTip message that eventually can be sent to the organizer (depending on how the CalDAV server is set up)
B: The user changes partstat to ACCEPTED right away and then uploads the event (just a single upload). In this case Broker::parseEvent does not generate an iTip message
I propose the solution to this problem is to modify Broker::parseEvent in such a way that it will also generates an iTip message in scenario B. I will create a merge request for that shortly after this.
Imagine a user somehow gets hold on a calendar event containing an invite for that user as attendee. Initially, the partstat for that user / attendee is set to NEEDS-ACTION. Now, the following two scenarios should result in same result, but does not:
A: The user uploads the event unchanged, after that the user changes parstat to ACCEPTED and then uploads the event again. In this case, Sabre\VObject\ITip\Broker::parseEvent will generate an iTip message that eventually can be sent to the organizer (depending on how the CalDAV server is set up)
B: The user changes partstat to ACCEPTED right away and then uploads the event (just a single upload). In this case Broker::parseEvent does not generate an iTip message
I propose the solution to this problem is to modify Broker::parseEvent in such a way that it will also generates an iTip message in scenario B. I will create a merge request for that shortly after this.