GNOME Bugzilla – Bug 355953
CalDAV: Fails to save, retry or offer alternatives when communication fails
Last modified: 2017-08-24 15:58:41 UTC
Please describe the problem: If I have a remote CalDAV calendar open and I add an event to it but for some reason that event fails to be accepted by the remote server (e.g. the remote server is not behaving correctly at the moment, or the network is down, etc) then when I click "Save" the event data is lost. Permanently & silently. Since this involves the potential for unexpected data loss I have marked this as "Critical". Steps to reproduce: 1. Set up CalDAV calendar 2. Add an appointment from Evolution to confirm it is working. 3. Disable CalDAV server software or authentication to it 4. Ensure that the CalDAV calendar is selected as default for new appointments 5. Highlight a period of time 6. Type the name of an appointment 7. Press enter. => Appointment immediately disappears! Actual results: The most severe situation is when the user's password is no longer valid on the backend server. The backend server (in this case) returns an 'Unauthorised' response to the PUT request. Evolution seems not to notice the 'Unauthorised' response (although it is identical to the response which made it start sending authentication data in the first place). In this situation, Evolution never recovers and needs to be restarted, even if the password on the backend server is changed back, Evolution will no longer be sending it, and there doesn't seem to be a way to get it to send it short of stopping and restarting Evolution and evolution-data-server. A less severe problem occurs when I simply stop the CalDAV server. In this case the newly created appointment is silently dropped, as above, but Evolution manages to re-connect automatically when I restart the server. Expected results: In all such cases I would expect an error message to be presented to me, indicating that I had lost, or was about to lose my data. A better solution would be to offer to save it in a local calendar, so that I still have the data, and can move it to the remote calendar when I again have connectivity (or authentication) for it. I guess a still better solution would be to automatically save the data locally, with some indication that the remote connectivity is currently busted, and to PUT the data remotely when that connectivity is restored. Possibly this third choice is covered by the "Copy calendar contents locally for offline operation" option. Even if it is, however, I still consider this a bug due to the silent loss of data that can occur. Does this happen every time? Yep. Other information: I can provide TCP dumps of the transaction process on request. These appointments were all added through the "highlight some time period, type something, hit <enter>" approach. If you enter an appointment through the "New Appointment" dialog then the useful and infomative "Unknown Error" message comes up (at least when the server is off it does - I didn't try the authentication failure trick in that case), and the user must manually dismiss the dialog, or change to a working calendar. I am using a CalDAV server which I am currently developing.
Might be a bug in the auth logic. I will look at that (not sure when I find enough time though).
Does this still happen with 2.22 or 2.24? If not, it's probably OBSOLETE.
I've split this into two parts. Possibly separate bugs should be filed for these parts, as it seems to me that while there are some similarities in the emergent behaviour, there may well be two underlying problems here. Password Changed on Remote Server ================================== I still see much the same behaviour, for example when I change the password of the user, I see no prompt from Evolution asking me for the password for the CalDAV calendar. Having changed the password, I see no indication that the calendar has become read-only, or anything like that. I try and add a new appointment typing it directly onto the calendar and get no warning or error messages... and no appointment. The bug is definitely still present in Evolution 2.22.3.1 in some form, and I would be surprised if anything has been done about it to change things since. The only (very subtle) indication I get that something has changed, is that I do receive a prompt from gnome-keyring-manager asking me if it's OK to allow access to the keyring, but no subsequent prompt for a new password when the one stored in the keyring continues to fail. One slight improvement since I originally reported the bug is that if I add an appointment through the new appointment dialog, rather than typing it directly on the calendar, I receive the message 'Authentication required', and my appointment is not saved. It is not clear from that message how I am expected to supply my authentication credentials, without a prompt. If I then quit and restart evolution, the calendar with the changed password is disabled. If I try and reenable it then it is again disabled, with no warning or error message, or password dialog. Just for fun I then delete the calendar and re-add it. Even so I am *still* not prompted for a password for the calendar, and it is created disabled. I dread the idea that I might now have to choose the 'Forget Passwords' menu option, and re-enter the passwords for each and every one of my e-mail and my calendar accounts... Fortunately for me I'm a geek, and can happily navigate around gconf-editor and keyring-maint until I work out where that password is set, and manage to delete just the one, but I am pretty damn certain I wouldn't want to run through that over the phone with my mother... who is also much more likely not to remember all of her passwords. Expected behaviour: When evolution supplies authentication to the CalDAV server, and it receives a clear response indicating that the authentication has failed (i.e. there was no communication failure), then any saved password for that account should be removed automatically. Evolution should then prompt again for the account password. ================================================== Remote server is unavailable ============================ If I try and add an appointment directly on the calendar it is silently discarded. If I try and add one through the "New Event" dialog, I get the message "Unknown error". If I stop and restart Evolution while the remote server is unavailable, the calendars for that server are now disabled. This might seem a reasonable fallback, but it is far from ideal because (a) it only notices on startup, and (b) it requires me to manually notice and re-enable the calendars when my connectivity to that particular server is available. That second requirement is particularly annoying if, for example, I have a calendar server at home and one at work, and neither are accessible from the LAN of the other. Hoped for behaviour: When Evolution finds the remote calendar is inaccessible it switches it to a 'temporarily disabled' status, which is visually indicated by (e.g.) graying out the calendar name and possibly fading the event colour for that calendar. While the calendar is in this 'temporarily disabled' state, Evolution should continue to attempt it's periodic refresh, and then fully enable the calendar when it finds that it is once more accessible. Regards, Andrew McMillan.
Most apps know via NetworkManager that it is "offline" and e-d-s/evolution should not complain it can't reach the calendars. Also, I have marked them as "cache locally" but it still leads to lot of complaints by Evolution, the user is confused. And, it also results in the fact that I have to grep through my ~/.evolution to find my appointments while being offline while I did flag "cache locally for offline use."
Since the changes to bug #508501 the offline usage is there, in some shape. There is still a room for improvements, namely to offer what to do when conflicts happen, but it's out of scope of this bug report. *** This bug has been marked as a duplicate of bug 508501 ***