Last Comment Bug 723610 - When modifying an event, Lightning also tries to also modify the organizer (and fails)
: When modifying an event, Lightning also tries to also modify the organizer (a...
Product: Calendar
Classification: Client Software
Component: General (show other bugs)
: Lightning 1.2
: All All
: -- normal with 1 vote (vote)
: 1.8
Assigned To: Matthew Mecca [:mmecca]
Depends on:
Blocks: 742454
  Show dependency treegraph
Reported: 2012-02-02 10:27 PST by TGOS
Modified: 2012-10-02 06:06 PDT (History)
7 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

Fix v1 (1.43 KB, patch)
2012-09-30 13:43 PDT, Matthew Mecca [:mmecca]
no flags Details | Diff | Review
Fix - v2 (2.02 KB, patch)
2012-10-02 04:36 PDT, Philipp Kewisch [:Fallen]
philipp: review+
Details | Diff | Review

Description TGOS 2012-02-02 10:27:30 PST
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:

Description: Status Code: 403, The user lacks the required permission to perform the request.

<?xml version='1.0' encoding='UTF-8'?>
<error xmlns='DAV:'>
  <valid-organizer-change xmlns='urn:ietf:params:xml:ns:caldav'/>
  <error-description xmlns=''>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.
Comment 1 TGOS 2012-02-02 10:30:18 PST
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.
Comment 2 Philipp Kewisch [:Fallen] 2012-02-02 12:17:58 PST
Might be fixed by Lightning 1.2.1 which is due in the next few days.
Comment 3 TGOS 2012-02-02 12:40:28 PST
Unless it is fundamentally different from this version

it doesn't seem so.
Comment 4 Felix Möller 2012-02-05 13:54:33 PST
TGOS which CalDAV server are you using?
Comment 5 TGOS 2012-02-06 04:42:20 PST
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
 .2:urn:uuid:<Some UUID>

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.
Comment 6 Philipp Kewisch [:Fallen] 2012-02-06 09:15:05 PST
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.
Comment 7 TGOS 2012-03-02 06:01:21 PST
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.
Comment 8 Matthew Mecca [:mmecca] 2012-03-25 10:08:46 PDT
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.
Comment 9 JJ 2012-07-30 08:11:55 PDT
This problem still exists on Lightning 1.7b2
Comment 10 Philipp Kewisch [:Fallen] 2012-08-08 07:20:20 PDT
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.
Comment 11 Jesse Thompson 2012-08-09 10:13:26 PDT
I emailed Philipp with credentials for accounts on our server running Oracle Communications Calendar Server version: 7u2-7.15
Comment 12 Felix Möller 2012-09-12 15:07:23 PDT
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:
-ORGANIZER;CN=Möller Felix;
Comment 13 Matthew Mecca [:mmecca] 2012-09-30 13:43:46 PDT
Created attachment 666370 [details] [diff] [review]
Fix v1

Makes sure the organizer is only updated when the calendar is changed, and only if the new calendar has a default organizer set.
Comment 14 Philipp Kewisch [:Fallen] 2012-10-02 03:26:58 PDT
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 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.
Comment 15 Philipp Kewisch [:Fallen] 2012-10-02 04:36:44 PDT
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.
Comment 16 Philipp Kewisch [:Fallen] 2012-10-02 06:04:21 PDT
comm-central changeset f4792e945e0c
Comment 17 Philipp Kewisch [:Fallen] 2012-10-02 06:04:42 PDT
Backported to releases/comm-aurora changeset 69eb48adc271
Comment 18 Philipp Kewisch [:Fallen] 2012-10-02 06:06:03 PDT
Backported to releases/comm-beta changeset 4f5858015a0c

Note You need to log in before you can comment on or make changes to this bug.