GNOME Bugzilla – Bug 657615
Update attendee status doesn't store the change
Last modified: 2021-05-19 11:01:07 UTC
Sequence: 1. Create a recurrent meeting 2. Edit a single ocurrence- change the time 3. Open the message saying the attendee accepted the meeting 4. Press 'Update attendees status' Expected: Nothing Actual: The edited recurrrent moves back to it's original time. after refreshing the calendar it goes back to the right time. Need to disable the 'Update attendee status' button, since attendee status on the server side can't be changed.
Thanks for a bug report. I do not see what you see, in 3.9.90, the time doesn't change for me, but I see the detached instance twice for some reason.
I forgot to mention, even the evolution's UI shows the attendee status as updated, then the next refresh the value is back in "needs action", thus the change is not saved on the server. Let's have this bug for this issue.
Created attachment 252665 [details] [review] non-functional es patch for evolution-ews; This should make it work, theoretically, but it doesn't. I see that the server validates the XML blob and throws error when the part for attendee status is invalid, but it ignores the change otherwise. I tried with 2007, 2010 and 2013 servers, none does what I'd expect from it. I also tried to write into item:ResponseObjects, but the server returns an error: ErrorInvalidPropertySet - Set action is invalid for property. Thus bad luck too. I do not see any other way of providing response for attendees, the creating of MeetingResponse object didn't help either, thus I'd say it's an issue with Exchange servers, which should understand and update attendee status based with the way this patch works (it's the simplest way, where I would even make the LastResponseTime optional).
David, could you involve your support centre/IT for this, please? I believe it's a bug in EWS on the server.
Any chance I could have a clear 'smoking gun' comprised of only EWS traffic showing the misbehaviour please?
Created attachment 253826 [details] protocol.zip Here is a protocol I recorded. The files are named in a convention: XXX_F_T.xml, where - XXX is an index of the request/response - F is from where it came ('c' for client, 's' for server) - T is to where it came ('s' to server, 'c' to client) Example: 000_c_s.xml is what came first from client to server, while 000_s_c.xml is what the server returned to the client for the 000 request. 000 - shows what has the server stored for the meeting's attendee (GetItem) 001 - updates the attendee status to Declined (UpdateItem) 002 - repeats the 000, to verify what the server did with the request (GetItem) Despite the fact that the UpdateItem finished successfully, and the ChangeKey was also updated, the refetch of the CalendarItem shows the same response type for the attendee.
I think Exchange expects that it will *see* the email response from the invitee, and this status update should be done *automatically* by Exchange. I'm not sure Exchange is set up to handle the case where the response actually comes in to a different, non-Exchange, email address. Thus, the 'manual' update of attendee status by the EWS client isn't something they have tested... Can you confirm that the 'message saying the attendee accepted the meeting' mentioned in step 3 of comment 0 is actually coming in to a non-Exchange mailbox?
(In reply to comment #7) > Can you confirm that the 'message saying the attendee accepted the meeting' > mentioned in step 3 of comment 0 is actually coming in to a non-Exchange > mailbox? Correct, I receive the reply elsewhere. As you know, the thing is that the server should be able to import meetings in any state, not force "Unknown" recipient responses, when the response was not received by the server itself.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/evolution-ews/-/issues/ Thank you for your understanding and your help.