[Calendar] Retry item download on ErrorBatchProcessingStopped error
As discussed on the mailing list (https://mail.gnome.org/archives/evolution-list/2018-September/msg00068.html) there seems to be a bug / regression in evolution 3.28.x.
I've got some calendars from other users where I have access to and evolution fails to parse all entries in it. The one in question fails with this in the http payload:
<m:GetItemResponseMessage ResponseClass="Error"> <m:MessageText>Access is denied. Check credentials and try again.</m:MessageText> <m:ResponseCode>ErrorAccessDenied</m:ResponseCode> <m:DescriptiveLinkKey>0</m:DescriptiveLinkKey> <m:Items/> </m:GetItemResponseMessage>
The http request itself is successful, answered with status 200.
As evolution is going todo batch processing any other id's requested will get answered after this error with this:
<m:GetItemResponseMessage ResponseClass="Warning"> <m:MessageText>Item was not processed as a result of a previous error.</m:MessageText> <m:ResponseCode>ErrorBatchProcessingStopped</m:ResponseCode> <m:DescriptiveLinkKey>0</m:DescriptiveLinkKey> <m:Items/> </m:GetItemResponseMessage>
The appointment in question is a series one and I tried to open the appointment with different tools:
If I open the series it works. If I want to open just the current occurrence it fails with:
You don't have permission to perform this action.
But the series is fine.
It does show the entry in question in the overview and I can open the appointment there and it shows the same details (description, attendees etc.) like OWA if I choose the whole series in OWA. I am not asked if I want to open the series or just the occurrence.
Just behaves like Evolution 3.10.x.
Does not show that entry at all.
As 3.10.x was able to display the series without an error this sounds like a regression. It would be nice if this can be fixed I a way, that it is not ignored at all but works again list in the past. And it would be nice if there is a batch processing error for only some of the requested id's that those who was aborted by the server because of a previous error would be requested by evolution again, because those don't necessarily are erroneous.