When modifying an event, Lightning also tries to also modify the organizer (and fails)



8 years ago
7 years ago


(Reporter: spamcop, Assigned: mmecca)


(Blocks 1 bug)

Lightning 1.2
Dependency tree / graph



(1 attachment, 1 obsolete attachment)



8 years ago
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='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.

Comment 1

8 years ago
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.

Comment 3

8 years ago
Unless it is fundamentally different from this version


it doesn't seem so.

Comment 4

8 years ago
TGOS which CalDAV server are you using?

Comment 5

8 years ago
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.
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

7 years ago
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.


7 years ago
OS: Mac OS X → All
Hardware: x86 → All

Comment 8

7 years ago
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.


7 years ago
Blocks: 742454

Comment 9

7 years ago
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.

Comment 11

7 years ago
I emailed Philipp with credentials for accounts on our server running Oracle Communications Calendar Server version: 7u2-7.15

Comment 12

7 years ago
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;EMAIL=mail@felixmoeller.de:urn:uuid:280137405

Comment 13

7 years ago
Posted patch Fix v1 (obsolete) — Splinter Review
Makes sure the organizer is only updated when the calendar is changed, and only if the new calendar has a default organizer set.
Assignee: nobody → matthew.mecca
Attachment #666370 - Flags: review?(philipp)
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 user01@example.com. 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.
Posted patch Fix - v2Splinter Review
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.
Attachment #666370 - Attachment is obsolete: true
Attachment #666370 - Flags: review?(philipp)
Attachment #666930 - Flags: review+
comm-central changeset f4792e945e0c
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.0
Backported to releases/comm-aurora changeset 69eb48adc271
Target Milestone: 2.0 → 1.9
Backported to releases/comm-beta changeset 4f5858015a0c
Target Milestone: 1.9 → 1.8
You need to log in before you can comment on or make changes to this bug.