When I open an existing calendar event in one of my CalDAV calendars, which I have not created myself, don't make any change to anything displayed in the dialog and then click on "Save and Close", I get the following error message:
Error Code: MODIFICATION_FAILED
Description: Status Code: 403, The user lacks the required permission to perform the request.
<?xml version='1.0' encoding='UTF-8'?>
<error-description xmlns='http://twistedmatrix.com/xml_namespace/dav/'>Organizer cannot be changed</error-description>
I have not changed the "organizer" of that event. There is not even a field that would allow me to change the organizer.
I run into the same error when trying to make any modification, even though I'm allowed to make certain modifications to events (the server will accept certain kind of modifications when I use another CalDAV software), however, since the server always thinks I'm also trying to modify the "organizer", the whole modification attempt fails.
PS: The Category "General" is probably wrong, but I'm not quite sure whom to blame for this modification. It might be the dialog UI, it might be the CalDAV integration, the component that manages the event database. So I'm sorry for probably choosing the wrong category, I hope someone with more knowledge about this project can fix it for me.
Might be fixed by Lightning 1.2.1 which is due in the next few days.
Unless it is fundamentally different from this version
it doesn't seem so.
TGOS which CalDAV server are you using?
iCal Server; I think Mac OS 10.7 Server.
It looks like the Organizer has the following form:
ORGANIZER;CN=<Some Name>;EMAIL=<Some E-mail Address>;SCHEDULE-STATUS=1
Lighting seems to modify it on "open" and when I try to re-save the entry (modified or not), the ORGANIZER line seems to have a different form and that causes the initial error.
So to concrete the bug report: Lighting should probably never modify any part of the original ICS file, that has not changed. Unless I change the organizer somehow, there is no reason why Lighting should touch this line at all.
Could you possibly test if this has worked in Lightning 1.1 with Thunderbird 9? We did a few last minute changes that may have regressed this.
The problems seems to be related to bug 607906; lighting cannot handle "urn:uuid" and if that is found in the ORGANIZER line, and it is when using iCal Server, Lightning seems to corrupt the event before storing it locally. When performing any change to the event, Lighting tries to store the event back to the server with the already "corrupted" ORGANIZER line, which fails, since I don't have permission to alter ORGANIZERS for events on that server.
This is not an old issue, it's known for one and a half year and and makes Lighting effectively useless for anything but "viewing" events from an iCal Server, since editing, confirming and even scheduling new events doesn't work correctly, if it works at all.
I believe this is the same root issue as Bug 735619, the event dialog always attempts to set the event organizer to the calendar's default organizer.
This problem still exists on Lightning 1.7b2
Unfortunately I don't have a test server for this that uses the urn: syntax. If someone wants to give me temporary access to their sever, I'm happy to take a look.
I emailed Philipp with credentials for accounts on our server running Oracle Communications Calendar Server version: 7u2-7.15
I think this can be reproduced with an iCloud account.
I have created an event with iOS 5.1.1. Opening it in Lightning and closing it without any modifications asks if the modifications should be saved.
Diffing the files gives the following:
Created attachment 666370 [details] [diff] [review]
Makes sure the organizer is only updated when the calendar is changed, and only if the new calendar has a default organizer set.
It gets a bit more complicated with an apple server. One of the problems is that the user id is changed to urn:uuid:user01 and we compare that with the email address set for that server, which might be firstname.lastname@example.org. I couldn't reproduce the actual issue since I don't have an apple server with those sorts of sharing permissions, but we are setting SENT-BY even though we shouldn't.
Ideally there needs to be some default acl manager for caldav calendars that uses the calendar-user-address-set as the list of users. This is out of scope for beta though.
I'll try to get the sharing permissions set later on, but if this continues I'm going to just comment those lines in beta and drop the SENT-BY feature.
Created attachment 666930 [details] [diff] [review]
Fix - v2
I've added another few lines that use the EMAIL property to get the email, which helps decide if SENT-BY needs to be passed. This will at least fix apple servers.
I'm going to push this version to beta, if you see anything critical in there please let me know asap.
comm-central changeset f4792e945e0c
Backported to releases/comm-aurora changeset 69eb48adc271
Backported to releases/comm-beta changeset 4f5858015a0c