490303 - Invites are not sent when using Sun Calendar Server and the meeting arranger is wrong

Status: RESOLVED FIXED

(Calendar :: Provider: WCAP, defect)

Description

[Jani]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; fi; rv:1.9.0.9) Gecko/2009040821 Firefox/3.0.9
Build Identifier: Problem is in every build since 0.8 which works fine (Tried it with the final 0.9 and now with the latest 1.0pre) Thunderbird is 2.0.0.21 and with the 1.0pre I'm using 3.0b2

Ok,

I'm in no means a developper and prob can't tell you all the right things but this bug is preventing us from moving from Lightning 0.8 to 0.9 so I need to file this bug.

We are using atm 0.8 version of the thunderbird plugin in our company. It works fine with our Sun Calendar Server (6.3 patch rel 121657-30). When upgrading to 0.9 and with the latest 1.0pre we encountere a following problem:

When creating a new event and inviting people to attend to it, no invitations are sent. When checking the event from the calendar server it doesn't show it as being done by you but as you would have invited yourself to the meeting.

When opening the event again in lightning and closing it you are promted for saving changes even if no chages are done.

Reproducible: Always

Steps to Reproduce:
1.Start creating a new event
2.Select people to invite
3.Save the event
Actual Results:  
You appear to invite yourself instead of making your own event and inviting others.

Expected Results:  
You create a new event for yourself and invite others.

I did trace the difference in the query sent by thunderbird to the sun calendar server and one major thing is different. When it is working in 0.8 we are sending this value: orgCalid	[e-mail]
and when it is not working in 0.9 and 1.0 pre we are sending only this value:
orgEmail	mailto:[e-mail]
Otherwise the sent packages look quite the same. There is some timezone info that is different, but I assume that it has nothing to do with this.

So to me it looks like lightning is a bit unsure who I am and acts like I'm only some random inviter instead of beeing me.

Making events where no one is invited work just fine in 1.0pre so it only goes wrong when you invite people.

The only file I can find using that orcalId is this:calWcapCalendarItems.js
There are differences with the code between 0.8 and 1.0pre (Quite obvius).

I'm hoping that some one can figure out what's going wrong

Comment 1

[Daniel Boelzle [:dbo]]

This works for me. Could you please provide a log file?

Comment 2

[Jani]

Would love to, what kind of log file? Can I get a log file out of lightning?

Comment 3

[Jani]

Attachment: Http requests and replys and example events from Sun Calendar server

Here is some info that I gathered. The http requests of both 0.8 version and 1.0pre version and also one error from Sun Calendar server. The error on the calendar server is one that is expected, since no calendar with MAILTO: can really exist.

Comment 4

[Daniel Boelzle [:dbo]]

(In reply to comment #2)
> Would love to, what kind of log file? Can I get a log file out of lightning?
<https://wiki.mozilla.org/Calendar:WCAP_Provider#Logging>

Comment 5

[Jani]

Attachment: WCAP logs from 0.8 and 1.0pre (0.8 works, 1.0pre doesn't)

Here are the WCAP logs using Very Verbose logging options.
I had to clean it up a bit, but I hope you can see the issue.
According to those logs it's just setting the organizer wrong.

I'm not sure if this problem is caused by the fact that my username is in this like [e-mail] or myusername when there is no such email address, there is only [e-mail]

Comment 6

[Jani]

Just to answer my own question:
I made an email alias of [e-mail] and now the entry is created ok.
Now it still doesn't send invitations to others because it is trying to send them to [e-mail] when it should use [e-mail]

we can workaround this by creating the alias for all users, but is this really the way this should work?

Comment 7

[Jani]

Attachment: Log of WCAP on 1.0pre working with the mail alias (partly)

Log file of the succesful entry after adding the email alias. Other people still not invited.

Comment 8

[Stefan Sitter [:ssitter]]

Is the email account configurable for WCAP calendars like for other calendars? If yes choose the calendar entry in the left pane in Thunderbird and choose Properties from the context menu. Ensure that the correct account is selected for this calendar.

Comment 9

[Jani]

Yes it is, but if I've understood correctly the invitations are not sent by Thunderbird itself, but the Sun Calendar server. The email account selected is [e-mail], so in that sense it's ok.

Comment 10

[skre]

I'm using Sun Calendar 6U2 and TB3 with Lightning 1.0b2pre. I've also problems inviting people but I don't think it's related to the address.

WORKAROUND: After saving the event simply edit the header (add or remove at least one character) and the event will be stored via WCAP and the invitations will be send by Sun Calendar.

I've no idea why but it works.

Jani: could you please check this behaviour at your site?

Comment 11

[dbirdman]

From the logs provided...

-/ with lightning 0.8 :

### WCAP log entry: 2009/04/28 12:03:58 /mozilla.org/20071231_1/Europe/Helsinki isDate=0
[calWcapNetworkRequest id=8eef8af5-578f-48ec-b24e-bed0567816a3-26, parent-id=8eef8af5-578f-48ec-b24e-bed0567816a3-25 
(https://calendar.domain.fi/storeevents.wcap?appid=mozilla-calendar&id=XYDzSJQSUGA&dtstart=20090428T100000Z&X-NSCP-DTSTART-TZID=X-NSCP-ORIGINAL-OPERATION=X-NSCP-WCAP-PROPERTY-REPLACE^Europe%2FRiga&dtend=20090428T110000Z&X-NSCP-DTEND-TZID=X-NSCP-ORIGINAL-OPERATION=X-NSCP-WCAP-PROPERTY-REPLACE^Europe%2FRiga&isAllDay=0&rrules=&rdates=&exrules=&exdates=&attendees=RSVP=TRUE^PARTSTAT=ACCEPTED^MAILTO%3Amyuserid%40domain.fi;RSVP=TRUE^PARTSTAT=NEEDS-ACTION^ROLE=REQ-PARTICIPANT^CN=Firstname%20Lastname^MAILTO%3Afirstname.lastname%40domain.fi&orgCalid=myuserid%40domain.fi&summary=Test%20logging%200.8&categories=&desc=Test%20with%200.8%20and%20log&location=Teslocation&icsUrl=&priority=0&icsClass=PUBLIC&status=0&transparent=0&attachments=&alarmStart=&alarmPopup=&alarmEmails=&tzid=Europe%2FRiga&storetype=1&mod=4&method=2&replace=1&fetch=1&relativealarm=1&compressed=1&recurring=1&emailorcalid=1&fmt-out=text%2Fcalendar&calid=myuserid%40domain.fi), isPending=true, status=NS_OK]


-/ with lightning 1.0 pre

### WCAP log entry: 2009/04/28 12:21:55 Europe/Helsinki isDate=0
[calWcapNetworkRequest id=3c7ea1c2-931e-4c00-9979-577ee233f042-39, parent-id=3c7ea1c2-931e-4c00-9979-577ee233f042-38 
(https://calendar.domain.fi/storeevents.wcap?appid=mozilla-calendar&id=g44%2Bu1Ui9Yc&dtstart=20090428T100000Z&dtend=20090428T110000Z&isAllDay=0&rrules=&rdates=&exrules=&exdates=&attendees=RSVP=TRUE^PARTSTAT=NEEDS-ACTION^ROLE=REQ-PARTICIPANT^CN=Firstname%20Lastname^mailto%3Afirstaname.lastname%40domain.fi&orgEmail=mailto%3Amyuserid%40domain.fi&summary=Test%20with%20logging%201.0pre&categories=&desc=Test%20with%201.0pre%20and%20logs&location=Testlocation&icsUrl=&priority=0&icsClass=PUBLIC&status=0&transparent=0&attachments=&alarmStart=&alarmPopup=&alarmEmails=&tzid=Europe%2FRiga&storetype=1&mod=4&method=256&smtp=0&smtpNotify=0&notify=0&replace=1&fetch=1&relativealarm=1&compressed=1&recurring=1&emailorcalid=1&fmt-out=text%2Fcalendar&calid=myuserid%40domain.fi), isPending=true, status=NS_OK]

Spot the different attribute 'method' between the two : 

0.8:  method=2    -> 'REQUEST'
1.0:  method=256  -> 'UPDATE'

The argument "method=256" sent by Lightning 1.0pre is causing Sun Calendar not to display this event. The value "256" is for UPDATE which means just update the event in this calendar and not propagate the changes to attendees/organizer. It seems that CS is labeling the event as "UPDATE" which is incorrect. It should be one of REQUEST, REPLY and PUBLISH. A bug has already been submitted to Sun for the Calendar Server and will be addressed in an upcoming patch.

In the meantime, I'm not sure if Lightning is sending method=256 intentionally or not. Just wanted to make sure Lightning folks are aware of what "method=256" really means.

Comment 12

[Oddgeir Bell]

I made a change in calWcapCalendarItems.js, and it seems to work now, atleast for us. Really don't know if this is the best way to fix it, but atleast it seems to work. Would be nice if anyone with some real knowledge of Lightning could look into it, and if it's acceptable, add it to the source...

original code:
// xxx todo: mbu initially sets this ownerId:
if (!orgCalId) {
	var orgId = getOrgId(item);
	if (!orgId || (orgId == this.ownerId)) {
		orgCalId = calId; // patch to this calid
	}
}

The problem: getOrgId(item) returns mailto:emailaddress, and when it's compared to this.ownerId on the next line, it fails, since this.ownerId is just emailaddress, with no "mailto:".

Quick fix:
// xxx todo: mbu initially sets this ownerId:
if (!orgCalId) {
	var orgId = getOrgId(item);
	if (orgId != null && orgId.indexOf("mailto:") != -1) {
		// starts with mailto:
		orgId = orgId.replace("mailto:", "");
	}
	if (!orgId || (orgId == this.ownerId)) {
		orgCalId = calId; // patch to this calid
	}
}

Basically, just remove mailto: ....

Comment 13

[Philipp Kewisch [:Fallen][☁️📆]]

Daniel, any thoughts?

Comment 14

[Daniel Boelzle [:dbo]]

I suspect I cannot reproduce the issue because the calendar server I can access does not use mail addresses as calendar ids. I think the cleanest fix would be to check whether PRIMARY-OWNER is actually an email address (e.g. test for @) and properly prefix the id (mailto:). We should also compare ignoring case. I hope to find some time before the weekend...

Comment 15

[Daniel Boelzle [:dbo]]

Attachment: patch - v1

Thanks for investigating, I opt to go with a similar fix suggested by Oddgeir Bell: Removing the mailto prefix for that specific comparison (and doing it ignoring case) seems the least invasive fix to me. We need to consider that we're about to release 1.0 and regressions hurt badly at this stage.

Since I can't reproduce the problem, it would be nice if interested parties (on this bug) could double check whether the attached patch fixes the issue for them (and does not regress new stuff...). Just patch those few lines in your thunderbird's profile directory, i.e.

<profile-dir>/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/calendar-js/calWcapCalendarItems.js

Thanks!

Comment 16

[Daniel Boelzle [:dbo]]

(In reply to comment #11)
> In the meantime, I'm not sure if Lightning is sending method=256 intentionally
> or not. Just wanted to make sure Lightning folks are aware of what "method=256"
> really means.

I intentionally just UPDATE outbound iTIP (via iMIP) messages.

Comment 17

[skre]

The patch works fine! THX!

Comment 18

[Philipp Kewisch [:Fallen][☁️📆]]

Comment on attachment 422536 [details] [diff] [review]
patch - v1

Thanks for testing. Codewise this patch looks fine. r=philipp

Comment 19

[Philipp Kewisch [:Fallen][☁️📆]]

Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/64e010f050bd>

-> FIXED