Created attachment 626509 [details]
INBOX>183143 is an example iMIP message that triggers this behavior.
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20100101 Firefox/12.0
Build ID: 20120420145725
Steps to reproduce:
1. Configure a CalDAV account with Lightning and link it to your email account in the calendar properties.
2. Configure the server to send iMIP messages for all users (even if users are hosted on the same service residing on the same domain).
3. One user invites the other local user to an event.
4. Upon receiving the iMIP notification the "This message contains an invitation to an event" bar appears with 3 options: Accept, Decline and Tentative
5. Lightning has not been synchronized, so it is not aware of the event.
5. Click Accept
When accepting an event via iMIP into a CalDAV account which is already aware of the event, an error occurs:
Status Code: 403, The user lacks the required permission to perform the request.
<?xml version='1.0' encoding='UTF-8'?><D:error xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav" xmlns:M="urn:ietf:params:xml:ns:carddav">
The error is almost irrelevant. Essentially, the error means that the event has already been processed. It could be worded better. However, ideally the error condition should be avoided.
If Lighting is synchronized prior to viewing the iMIP message, then the bar says: "This message contains an event that as already been processed". Only one button appears: Open. At which point, Lightning's interaction with the event is correct. This is the desired behavior.
So, I think that a possible resolution to this situation is that Lightning should synchronize the associated CalDAV calendar immediately upon receiving an iMIP message. This would prevent the Accept/Decline/Tentative buttons from appearing, which will prevent the user from entering into this error condition.
Approval from Oracle on this:
"Sound good. I would think in general, the client would want to sync before a store, if online."
Generally yes, I think this would be good. The downside is that this might lead to very many refreshes. Just think you have a folder full of invitations and are looking for the correct one, so you click on the first then use arrow keys to scroll down. This would lead to very many refreshes and even if we queue them, there will be one after the other. Especially for uncached calendars this will become a problem and drain performance even more.
Created attachment 638613 [details] [diff] [review]
Fix - v1
I do have an intermediate solution though. This patch watches the calendar the item was found on and if the user manually syncs then the imip bar will be updated.
One thing to think about, I am not observing all possible calendars with this patch. So in case there are 2 potential calendars this item could be on, it is found to be on calendar A, then is deleted, the user syncs, then it is re-added on calendar B, the user syncs, the item will not be found until you click on another email and back to the original email. I think this case is very uncommon though.
Pushed to comm-central changeset 2e67745910d8