865726 - Only last address of calendar-user-address-set / email is taken into account when determining if invited

Status: NEW

(Calendar :: Provider: CalDAV, defect)

Description

[Igor Vitorac]

It seems that latest Lightning (1.9.1) has again (?) problem with Invitee email address received from CalDAV.

- I am using Thunderbird ESR 17.0.5 and Lightning 1.9.1
I can remember (not 100% sure) that there was such problem in previous Lightning versions (between 1.2.3 and 1.9.1). But I am 100% sure that combination Thunderbird ESR 10 and Lightning 1.2.3 was working perfectly.

- I use SOGo (ver 2.0.4b) as calendar server and connecting from Lightning with CalDAV

- I have 2 emails defined in Thunderbird:
[e-mail] (this one is primary and defined as email in Lightning Calendar properties)
[e-mail]

- I have both email defined in SOGo SQL user source, so SOGo is aware of both.
- My SOGo is installed at sogo.example.com

- Email address defined in calendar properties in Lightning is [e-mail]

Problem:
- When I create event and I want to invite somebody, I can see that my address is displayed as wrongly as [e-mail] (last/second email) in invitee list.
- When I receive email invitation from somebody else, Lightning will respond again with wrong email [e-mail] (last one)

New test:
- Then I removed [e-mail] (last email) from my profile in SOGo user source, so only one has left [e-mail]. Cleared memcached on SOGo server; Started TB/Lightning and Lightning was showing correctly email address ([e-mail])! This time CalDAV server was sending only one email and that email was taken.

So, seems that SOGo (during CalDAV conversation) is sending both emails ([e-mail] and [e-mail] ) to Lightning and Lightning is using only the last one (for sending invitations and for responding to invitations).

These are very similar/related bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=539916
https://bugzilla.mozilla.org/show_bug.cgi?id=540410
but seems that Lightning now displays always option to Accept/Decline invitation, however behavior with invitee email address is back again.

Just to mentioned that recently we used Thunderbird ESR 10 + Lightning 1.2.3 and we did not have problems as described above.

Comment 1

[Arnaud LE NORCY]

Hello,

I have exactly the same problem!

Thunderbird ESR 17.0.5 and Lightning 1.9.1
My calDAV server is sogo 2.0.5

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Yeah, this is what's causing bug 859383 for me.

Is there anyone in Lightning-land willing to fix this?  This is one of the main things stopping me from being able to use Lightning without going into our Zimbra web instance all the time, because I have essentially random control over my calendar via Lightning.  I would be willing to toss up a bounty, if a brib^H^H^H^Hbounty is needed!

Or, alternatively, if someone can point me at the relevant source, I can find some time to fix it myself as well.

Comment 4

[Philipp Kewisch [:Fallen][📱📆]]

The code is likely here: http://mxr.mozilla.org/comm-central/source/calendar/providers/caldav/calDavCalendar.js#2021

There seems to be some very simple logic to pick an email address, but looks like it doesn't work in all cases.

The comment about using the ACL manager means we now have an ACL manager, which is not being used everywhere because it was originally targeted only as a hook for an extension.

The simple solution is to improve the logic to pick one of the email addresses. Optionally add a calendar property to allow the user to specify a fixed email address via prefs.

The more complete solution would involve some UI changes, allowing the user to pick an identity where appropriate.

I don't think I will have time to fix this myself. It would be cool to have you back in calendar land though :-)

Comment 5

[Igor Vitorac]

Vladimire, that would be great if you find some time to fix this.

I found many discussion how Lightning should use email when sending invitations and responding to invitations.

From my point of view, ideally, Lightning should use email address defined in Calendar properties. 
If user has many calendars and many email accounts, user will configure appropriate email for each calendar. So, it will be up to user to set the proper email and it will give the user the biggest flexibility to configure calendar behavior. Otherwise, what is the point of Email definition in Calendar properties, right?

Bottom line for ideal scenario:
- User configures email per calendar (already implemented). This should tell the Lightning what is the user email (user id) to be used for the organizer/participant value for the events in that particular calendar.
- During creation of event user needs to chose calendar where to create event (already implemented)
- When sending invitation and when choosing which email to use for the organizer (user itself), Lightning must use email configured in Calendar properties (TO BE IMPLEMENTED)
- When calendar event invitation arrives in Inbox, Lightning asks in which calendar to store the event (it worked few version before, I have not checked it now)
- When sending email notification for the Acceptance for the event, Lightning should use email (user id / participant) defined in calendar properties. (TO BE IMPLEMENTED)

Thanks,
Igor

Comment 6

[Philipp Kewisch [:Fallen][📱📆]]

(In reply to Igor Vitorac from comment #5)

> From my point of view, ideally, Lightning should use email address defined
> in Calendar properties. 
> If user has many calendars and many email accounts, user will configure
> appropriate email for each calendar. So, it will be up to user to set the
> proper email and it will give the user the biggest flexibility to configure
> calendar behavior. Otherwise, what is the point of Email definition in
> Calendar properties, right?
Ah yes, the calendar properties email. This is something where the acl manager could be used nicely. If a non-default acl manager is created for caldav that provides the email addresses, then the properties dialog could not only show the email addresses from the identities, but also those of the acl manager. Possibly not show the addresses from the identities, but then again users could complain they can't set up their emails right.

Comment 7

[Klaus Stengel]

Attachment: Add CalDAV-Identities to ACL-Manager

In order to make this work in our SOGo installation, I created the attached patch. It will feed the identity list retrieved from the server back into the local ACL-Manager, so you can select which e-mail address should be used for each calendar. This also fixes the problem that people sometimes appear multiple times in the participant list with different addresses after changing the status on an invitation. In our setup, e-mail notifications are generated on the server, so I haven't tested what happens if Thunderbird is supposed to send notfications itself.

Comment 8

[Philipp Kewisch [:Fallen][📱📆]]

Comment on attachment 8427612 [details] [diff] [review]
Add CalDAV-Identities to ACL-Manager

Review of attachment 8427612 [details] [diff] [review]:
-----------------------------------------------------------------

r- for now, I think we should discuss the acl manager changes here. Also, given this doesn't fully fix the bug, I'd suggest filing a new bug instead and continuing discussion and patches there.

::: components/calDavCalendar.js
@@ +2139,5 @@
> +                            thisCalendar.mCalendarUserAddress = addr; // Use first one as default
> +                        }
> +                        if (thisCalendar.mCalendarUserAddressList.indexOf(addr) === -1) {
> +                            thisCalendar.mCalendarUserAddressList.push(addr); // Collect others in list
> +                        }

I'd suggest to instead save all addresses in an array and make sure the default entry is at the beginning of the array. Then you can drop the mCalendarUserAddress property and use the array instead.

::: components/calDefaultACLManager.js
@@ +84,5 @@
>          let addresses = [ id.email for each (id in identities) ];
> +        let server_addrs = this.mCalendar.calenderUserAddressList;
> +        if (server_addrs != null) {
> +            addresses = addresses.concat(server_addrs);
> +        }

The calendar is not necessarily a caldav calendar and is usually a wrapped instance (wrapped by the calICalendar interface). Therefore in many cases, this will just be ignored.

I believe SOGo (with the connector/integrator) is using a custom ACL manager anwyay, doesn't the code there provide a custom implementation of getUserAddresses that returns the caldav addresses?

Comment 9

[Philipp Kewisch [:Fallen][📱📆]]

I don't quite recall why I wanted it to happen in a different bug. I'm duping 540410 against this bug since it has a patch, but I like the title of that one more.

Comment 13

[wreck]

Is there something preventing the inclusion of this patch? I'm running into this issue currently and this bug has been open for 7 years.

Comment 14

[Philipp Kewisch [:Fallen][📱📆]]

The issues in comment 8 need to be resolved before we can include this patch.

Comment 15

[Olivier Mueller]

Hello and thanks Igor for the ticket!

Just a short comment to confirm the issue is still open, in my case with the caldav server from Zimbra 9.0.0_GA_3960, and the latest thunderbird client to date, 78.5.0 (under Mac OS and Linux). I just spent several hours trying to debug and understand the behaviour of thunderbird. With a single mail address, everything works as expected. But once an alias (or more) is defined in zimbra, the caldav client from thunderbird is unable to answer correctly to invitations from other people.

The header fields:
Originator: mailto:[e-mail]
Recipient: mailto:[e-mail]

And VCALENDAR entries:
ORGANIZER:mailto:[e-mail]

are wrong, and should be using "[e-mail]" instead. It is the case both ways, when trying to reply to an invitation, but also when trying to send an invitation to another account.

It seems the latest working version of thunderbird + lightning was version 52.2 (June 2017). Some clients here would like to be able to upgrade to a more recent version of Thunderbird, so a fix here (or even a temporary workaround) would be more than welcome.

Testing with other caldav clients were fine so far (for example with Mac OS 11 Big Sur Calendar.app).

Best regards, Olivier

Comment 16

[Rainer]

I just wanted to file this as a bug and saw that it has already been reported - 10 years ago! And that it is still unfixed.
I also saw a related (maybe identical) bug 1587736.

I have exactly this problem in Thunderbird 102.4.2.
My main email address is, let’s say, [e-mail]. I also have an alias [e-mail]. In Thunderbird, I associate all subscribed calendars with the address [e-mail] in the calendar properties.
When I create a calendar event and click the button “Invite attendees”, the first line of the calendar overview is prefilled with [e-mail] (most probably the last address in the “calendar-user-address-set”).

This is annoying/strange in a number of ways:

1. This forces me, every time, to manually change the prefilled address into the correct one ([e-mail] in this case) to ensure it goes out from the correct sender.
2. I suspect that this is responsible for a large number of “Party crashing?” messages I get when trying to accept invites sent to me ([e-mail]).
3. I was not even aware that a “calendar-user-address-set” exists and that it reveals (potentially all) my aliases. I have never used my aliases in the configuration of any accounts/calendars in Thunderbird. So for the unsuspecting user this might even be a privacy leak.

I have had this problem for around three years. I always thought that it is a bug of my email provider (Kolab Now). But after changing to Mailbox.org, the problem continues.

Many business users have aliases. This bug, even though not catastrophic, makes the use of calendar invites a real pain. I would very appreciate if this was given a higher priority.