Open Bug 475886 Opened 16 years ago Updated 1 year ago

When accepting/declining an invitation, generated mail should use the account the invite was received on

Categories

(Calendar :: E-mail based Scheduling (iTIP/iMIP), defect)

Product:
Calendar
Component:
E-mail based Scheduling (iTIP/iMIP)
Version:
Lightning 0.9
Type:
defect

Tracking

(Not tracked)

People

(Reporter: kkauper, Unassigned)

References

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 Build Identifier: 2008091719 In Thunderbird, I have a single Lightning calendar, but three email accounts, say A, B & C. The calendar is configured with its "email" set to A, in the calendars properties dialog. Whenever I receive an event invitation in Lightning, and attempt to accept/decline the invitation, the accept/decline messages are always sent via email A, *even when the invitation is received via email B or C* -- this is not the behaviour I'd expect, nor what the event organiser would expect, since the reply is coming from a different account. Accept/decline messages should be sent via the email account via which the invitation was received. Reproducible: Always Steps to Reproduce: 1. Setup two email accounts in Thunderbird (A & B) and one calendar with its email set to A. 2. From a different account, send a meeting invite to the B account. 3. Accept the invitation. 4. Observe from which account the reply email was sent. Actual Results: Accept email sent via account A Expected Results: Accept email sent via account B
Version: unspecified → Lightning 0.9
(In reply to comment #0) > Whenever I receive an event invitation in Lightning, and attempt to > accept/decline the invitation, the accept/decline messages are always sent via > email A, *even when the invitation is received via email B or C* -- this is not > the behaviour I'd expect, nor what the event organiser would expect, since the > reply is coming from a different account. IMO this is rather an enhancement than a bug: The transport protocol (iMIP) is independent of the iTIP protocol used for scheduling, i.e. the iTIP messages' ORGANIZER and ATTENDEE properties are relevant.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: x86 → All
Component: General → E-mail based Scheduling (iTIP/iMIP)
QA Contact: general → email-scheduling
Severity: enhancement → normal
Wouldn't implementing this on the attendee side be as simple as looking at the invitation recipient address and using that in the response? No new UI needed. If we're also talking about organizing new events, then that's obviously a bit more involved, since there would have to be a UI element for choosing the desired email identity to use as the organizer's email. But fixing this even just for attendees would be a big step forward. And strictly speaking that's how the bug is currently defined.
> since there would have to be a UI element for choosing the desired email identity to use as the organizer's email. There should not be any UI to select the email responding the invitation. This should be automatic. If I'm sending an invitation, why would another person RSPV it? it doesn't make sense.
(In reply to Alejandro from comment #25) > There should not be any UI to select the email responding the invitation. Read my comment more closely. That's exactly what I'm saying. > If I'm sending an invitation, why would another > person RSPV it? I'm not sure what you mean. If I'm the one organizing the event, i.e., sending out invitations, then I should be able to choose which one of my email addresses appears as the sender of the invitation. My calendar is primarily associated with my personal email address, but if I'm setting up a work-related meeting, I would like attendees to see my corporate identity as the organizer.

Just figured out that even if one sets the mail identity of the calendar to the address to which the invite was sent, the message text in the message response will still contain the default mail address while the FROM address will be the one configured in the calendar settings. This means that setting the calendar identity to the correct address is not a complete workaround as the default identity will still be revealed.

(In reply to Lorenz Froihofer from comment #29)

Just figured out that even if one sets the mail identity of the calendar to
the address to which the invite was sent, the message text in the message
response will still contain the default mail address while the FROM address
will be the one configured in the calendar settings. This means that setting
the calendar identity to the correct address is not a complete workaround as
the default identity will still be revealed.

Can you please file a separate bug for this? Please include a description what identity assocciations you have set, on to which calendar the invitation was added when you accepted it. Please also attach the sent reply. You may redact it, but please make sure the structure and e-mail address relation to your calendar settings is retained.

I can't believe this bug is 10 years old already.

(In reply to [:MakeMyDay] from comment #30)

(In reply to Lorenz Froihofer from comment #29)

Just figured out that even if one sets the mail identity of the calendar to
the address to which the invite was sent, the message text in the message
response will still contain the default mail address while the FROM address
will be the one configured in the calendar settings. This means that setting
the calendar identity to the correct address is not a complete workaround as
the default identity will still be revealed.

Can you please file a separate bug for this? Please include a description what identity assocciations you have set, on to which calendar the invitation was added when you accepted it. Please also attach the sent reply. You may redact it, but please make sure the structure and e-mail address relation to your calendar settings is retained.

Is there a separate Bug for this? I have a similare Problem...

(In reply to edlly from comment #32)

(In reply to [:MakeMyDay] from comment #30)

(In reply to Lorenz Froihofer from comment #29)

Just figured out that even if one sets the mail identity of the calendar to
the address to which the invite was sent, the message text in the message
response will still contain the default mail address while the FROM address
will be the one configured in the calendar settings. This means that setting
the calendar identity to the correct address is not a complete workaround as
the default identity will still be revealed.

Can you please file a separate bug for this? Please include a description what identity assocciations you have set, on to which calendar the invitation was added when you accepted it. Please also attach the sent reply. You may redact it, but please make sure the structure and e-mail address relation to your calendar settings is retained.

Is there a separate Bug for this? I have a similare Problem...

Yes, created bug 1524055 as suggested in comment 30.

Still running into this bug in 2019. This is a privacy issue for me, as accepting requests sent to one identity is leaking information about the calendar's identity.

(In reply to Bram from comment #34)

Still running into this bug in 2019. This is a privacy issue for me, as accepting requests sent to one identity is leaking information about the calendar's identity.

Not just for you, this is a privacy issue, plain and simple. And having a bug like this for 11 years doesn't look good. I know this is an open source project and some people do this on their free time, but such issues should have priority over others.

I simply stopped responding to calendar invites from TB on my business email because it replies with my personal email and it makes me look ridiculous. I always reply from gmail directly. Maybe now that TB team has grown bugs like this will be solved? One can hope.

It's not even solely a privacy issue. It's a functional one as well. On a lot of these invitation systems, if you reply from a different address that wasn't invited, your confirmation won't be accepted.

(In reply to Phil Stracchino from comment #37)

It's not even solely a privacy issue. It's a functional one as well. On a lot of these invitation systems, if you reply from a different address that wasn't invited, your confirmation won't be accepted.

which makes total sense! So let's hope they take this one for the next release, 11 years i way to long for an issue to be open

I've that bug using caldav calendars setup not related to any of my currents emails account.
Using Thunderbird 60.7.0 / Ligtning version 6.2.7

  • Calendar calendar1 properties

  • Thunderbird email account1

Received event invitation in mailbox account1 accepted and registered in calendar1. The outgoing email contains mismatches between the calendar account username (user@server1.tld) and the account email adress (user@server2.tld). See the following email source :

MIME-version: 1.0
From: Username <user@server2.tld>
Message-ID: <xxxxx-xxxx-xxx@server2.tld>
To: other.user@server2.tld
Date: Tue, 04 Jun 2019 14:37:14 +0200
Subject: =?UTF-8?Q?Event_Invitation_Reply_?=
 =?UTF-8?Q?=28Accepted
Content-type: multipart/mixed; boundary="Boundary_(ID_qyG4ZdjoAsiZ+Jo19dCbWQ)"


--Boundary_(ID_qyG4ZdjoAsiZ+Jo19dCbWQ)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_ryU4ZdJoASiZ+Jo21dCbwA)"


--Boundary_(ID_ryU4ZdJoASiZ+Jo21dCbwA)
Content-type: text/plain; charset=UTF-8
Content-transfer-encoding: 8BIT

user@server1.tld has accepted your event invitation.


--Boundary_(ID_ryU4ZdJoASiZ+Jo21dCbwA)
Content-type: text/calendar; method=REPLY; charset=UTF-8
Content-transfer-encoding: 8BIT

BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
METHOD:REPLY

[...]

ATTENDEE;PARTSTAT=ACCEPTED;ROLE=REQ-PARTICIPANT;SENT-BY="mailto:user@server2.tld":mailto:user@server1.tld

[...]
  1. If I receive an invite and press Reply, correct sender identity is automatically chosen.
  2. If I press Accept, default account's identity is used as desribed in initial post.

As #1 works, it must be technically possible to choose correct identity to send acceptance notification.

11 years and counting...

I have made many tests now. I believe that this problem is a design fault. if you use accept or decline button, lightning seems to be send via the calender identity.

calendar/modules/utils/calProviderUtils.jsm

These select the indentity, but you could only configurate one:

  /**
   * Gets the iTIP/iMIP transport if the passed calendar has configured email.
   *
   * @param {calICalendar} aCalendar      The calendar to get the transport for
   * @return {?calIItipTransport}         The email transport, or null if no identity configured
   */
  getImipTransport: function(aCalendar) {
    // assure an identity is configured for the calendar
    if (aCalendar && aCalendar.getProperty("imip.identity")) {
      return Cc["@mozilla.org/calendar/itip-transport;1?type=email"].getService(
        Ci.calIItipTransport
      );
    }
    return null;
  },

These function her has a second parameter outAccount.

  /**
   * Gets the configured identity and account of a particular calendar instance, or null.
   *
   * @param {calICalendar} aCalendar      Calendar instance
   * @param {?Object} outAccount          Optional out value for account
   * @return {nsIMsgIdentity}             The configured identity
   */
  getEmailIdentityOfCalendar: function(aCalendar, outAccount) {

on line: 641. Is an config parameter imip.account. Which seems never set. I could not find out for what the config paramter is. Maby its old dead code or so. But here we could select the right indentity if we use this parameter.

          case "imip.account": {
            let outAccount = {};
            if (calprovider.getEmailIdentityOfCalendar(this, outAccount)) {
              ret = outAccount.value;
            }

I think a solution for this problem would be to select more than one identity in a calendar and have it selected by the recipient mail.

I could not found any SourceCode form lightning on web where I could made a pull request.

This is a High Severity problem for me, at least disable the "accept" button

Just got burned by this one - accepted an invite (to do with local government) on my personal email - meeting organizer got an acceptance from my work email (which they had no idea was me) and decided the meeting had been hacked, causing some issues

Eternally suffering from this, and attributing to myself being disorganized, I discover I am in good company.

Situation
You have multiple email identities, (A: name.surname@oldproviderdomain, B: nick.name@gmail.com, C: professional.address@company.domain; and possibly other addresses D: another.professional@anothercompany.domain or E: name@sport.association like the last one).
You want to use google calendar (GC), because it's believed to be the simplest. You want to receive and accept/decline invitations, and manage related notifications and alerts via the usual TB (thunderbird) and your favourite android email application (Bluemail for me, BM) and android calendar application (AC), as well as Ubuntu Calendar application (UC), that you may receive on any of those email identity.

A possible solution is to create independent calendars for all those identities. To do it with google, does it require a new account for each original identity? Unfortunately that would even increase complexity. What you need in fact is to have all those calendars be shown in one view. Is there a calendar solution that allows me to manage them all from the email identities registered in TB? Google? So far I am sticking with it. NextCloud?

A. Question: Can google calendar allow me create multiple calendars in one account (B), that I can manage in the name of A, C, D, E, ... as well? Can TB interact effectively with google calendars. Is there really a problem and where is it? Is it in Google or in TB or in their interaction? I don't have it clear and would like to receive your advice and links to documentation that teaches me how to do it.

B. Thinking of using also your smartphone, and of the other person environments, the situation is more complex. I try to sketch basic use cases here:

  1. S (someone@anydomain.anywhere) invites me on any of the above email identities (say X), that I all manage in TB (Ubuntu) or BM (Android). I can:
    1.1 decline the invitation: TB (or BM) will send a reply message with X's refusal, from the same address of mine that received it (X)
    1.2 accept the invitation: TB (BM) will send an acceptance reply message and will save the event in the calendar linked to email identity X
    1.2.1 if more than one calendar is linked to the same email address, it will use a default one, or ask in which to insert it, and optionally remember the chosen association saving the association (calendar, sender) ("save this association as the default for next invitation from same sender?")
    1.3 modify/suggest changes: TB (BM) will send back a modification message which suggests changes either of the event ("X would like to propose to modify the event timing so and so"), and even of the invited person identity ("X wants to be subscribed to the event as Y. Please confirm it and save this preference). S can choose to send back this message either from X or from Y identity or from both of them, and S will be able to act on any of these to confirm my modification, deleting the other message, replacing the participant identity in the event. and saving the preference that X prefers to be invited as Y. Next times he selects me from a list, or tries to digit address X, he will see Y identity highlighted and X lowlighted, or will be suggested to replace it with Y.

This requires that a some associations are known/accessible to TB (and BM) and managed by it:

  • (my.email.identity; preferred.calendar; a 3rd column "preferred" marks the one to be used as default):
  • (inviter.email.identity, or domain; my.preferred.email.identity.with.him)
  • (other.person.email.identity; preferred.identity.I.should.use.for.him)
    The first suffices for 1.1 and 1.2, and is probably already there or buildable on the fly based on the subscribed calendars. If it is already there, how can I clearly configure it from TB? Or from Evolution? I need to see all calendars known to each TB email account, and want to be able to manage these associations.
    The last two are required for 1.3, they are the reciprocal of each other and should better be saved in one place only (on the "invited" side) and accessible to registered inviters.

Yes 1.3 is complex (and I likely was neither complete nor accurate). It requires that the email client on the other side has features that TB cannot control. Maybe some of these or similar ones have already been implemented in some context (Google? Microsoft? Notes?) the difficult point is that many different players need to be coordinated. Or is it enough that one player in the middle manages it all? (does Google do it? I suspect it does but could not find myself instructions how to do it). But maybe 1.3 is not that necessary.

Sorry for the message if it is too long. Please free to answer only to the question at point A. or follow up more on the "use cases" at B. In any case what I need most is some link to a clear way how to set up a system that "simply works enough" with multiple email identities. Please point me to any howto on the net or just give hints.

Bye
L

After clarifying my needs, I found something useful myself:

You definitely [can use google calendars without a gmail address] (https://help.oncehub.com/help/creating-a-google-calendar-account-that-uses-your-business-email-address). This relaxes the constraint that you have create a gmail account just to use google calendar (wrong belief).

Let's see what else I find and if I can post a solution

I have the same problem as described above. For accepting invitations and as well while sending them.
Already at my creation of an invitation for an event the "organizer" can not be changed. It is set fix to the login credentials of the calendar account.

I tried all i found (turning off offline-support in calDAV settings, creating alias SMTP-accounts for the calendar-account etc...) It is highly annoying for me not to be able to separate calendar and email accounts as I have several email addresses but everything in one calendar account (that i access from the phone etc).

Using and accepting invitations is really confusing for everyone involved as the email-address of my calendar-account appears in all other people's invitation. In my case (same as described in comment 43) the receivers can't even tell from the email-address that it is me that has accepted or sent the invitation. Hence i can not use any of the invitation features with Thunderbird although invitations are very popular and wildly used.

Please increase severity 🤗

Duplicates: (I guess) (...respectively fixed with this fix)
https://bugzilla.mozilla.org/show_bug.cgi?id=1562896
https://bugzilla.mozilla.org/show_bug.cgi?id=1097558
https://bugzilla.mozilla.org/show_bug.cgi?id=749921
Additionally found some stuff in German and French speaking forums about this problem.
see also:
https://bugzilla.mozilla.org/show_bug.cgi?id=1642678
and:
https://bugzilla.mozilla.org/show_bug.cgi?id=1587736

@lurix66 thx for sharing. the fix with google calendars doesn't help me as i do not use google calendars.

Let me summarize.
All TB users that have multiple email accounts have a hard time in managing invitations, as:

  • sent invitations show the email identity of the calendar account, instead of the email identity of the "organizer", because one cannot set an organizer different from the calendar owner. This seems to me a limitation of the calendar service, not of TB. If I want to organize a meeting as X, I should send the invitation from a calendar belonging to X, or at least X should be a secondary email linked to the same account. TB could be made aware of the calendar ownership relation, and probably already is. I don't know if additional email identities linked to the same calendar are already managed, I believe they are not
  • received invitations which do not impinge on any known calendar, cannot be accepted, unless registering the recipient email address to an existing calendar, or creating a new one. The latter is not desirable because one may not want to multiply calendars just for one invitation. The former is not desirable because it will permanently associate the receiver email account with a certain calendar, while instead the involved calendar will differ every time, as it more likely depends on the sender or on the event, rather than on the email account that received the invitation.
  • more generally, also received invitations that do impinge on a known calendar, may in some cases need to be moved to another calendar, within those known to TB. This "move" operation could be interesting to implement, and might work also if the participant is the organizer. Other recipients, will receive a notification that a person originally registered to the event E with email identity X, changes it to Y. The person commanding the move, will see that as the event E moving from a calendar belonging to account X to one belonging to account Y.

Hope this "online reasoning" is useful to understand the severity of this issue, and to identify of a solution.
L

yes please fix this and increase severity. I love Thunderbird, but this is making me consider to move to a different programme. Calendar invites are so often used, it is really hampering my professional life.

This is the most annoying Thunderbird issue for me as well.

This is a major defect bordering on a security leak for anyone using multiple accounts as it creates a bleadover between accounts. This is the same as hitting reply to an email and the reply going out with the wrong email.

For example, I use multiple accounts for:
A. personal email
B. side business
C. faculty email
D. non profit where I'm a board member
E+. other less important accounts

There are potential legal implications of responding to an invitation sent to accounts B, C, or D with one of the other two accounts, and a security implication of responding to in invitation to account C with account A - imagine failing a vengeful student after sending out personal account info instead of faculty specific account info only.

Distinct accounts need to be fully compartmentalized. I can't believe this bug has been open for 13 years.

This is very frustrating. I thought that managers are adding my personal email to the work meetings unless I realised that this is done actually by Thunderbird when I click "Accept" – it uses the first account (my personal) to send a reply :/

(In reply to puppy from comment #50)

This is a major defect bordering on a security leak for anyone using multiple accounts as it creates a bleadover between accounts. This is the same as hitting reply to an email and the reply going out with the wrong email.

For example, I use multiple accounts for:
A. personal email
B. side business
C. faculty email
D. non profit where I'm a board member
E+. other less important accounts

There are potential legal implications of responding to an invitation sent to accounts B, C, or D with one of the other two accounts, and a security implication of responding to in invitation to account C with account A - imagine failing a vengeful student after sending out personal account info instead of faculty specific account info only.

Distinct accounts need to be fully compartmentalized. I can't believe this bug has been open for 13 years.

yeah i totally agree with this, i have exactly the same situation. I love open-source and Thunderbird, but i've just moved everything over to Outlook, because this was just not workable / professional any longer for me, with all the online calendar invites that are going around in these COVID times

Also, mindblowing that after 13 years this bug is set to:
Priority: Not set Severity: normal
!!

+1
Still annoying after so many years.
Always have to switch account in the calendar although it could be automatic.

At least on a work computer you can:

  1. Right click on your work account
  2. Click Settings
  3. On the bottom left corner set it as a default account
  4. Restart Thunberbird

I didn't know about this workaround, that's useful. Still, rather ridiculous that to accept a calendar invite you would have to change the default account and restart your email programme every time...

(In reply to Rik from comment #56)

I didn't know about this workaround, that's useful. Still, rather ridiculous that to accept a calendar invite you would have to change the default account and restart your email programme every time...

Not every time, only once. With this guide you will change your default account permanently

(In reply to Rik from comment #56)

I didn't know about this workaround, that's useful. Still, rather ridiculous that to accept a calendar invite you would have to change the default account and restart your email programme every time...

So, this is not what I would call a "workaround".

(In reply to Oleg K from comment #57)

(In reply to Rik from comment #56)

I didn't know about this workaround, that's useful. Still, rather ridiculous that to accept a calendar invite you would have to change the default account and restart your email programme every time...

Not every time, only once. With this guide you will change your default account permanently

Not sure you understood the issue : when receiving several invitations for different accounts the same day, I won't change my default account and restart Thunderbird every minute !

We need something like :

  • autoselection of the good calendar account (the one of the email address) when answering to an invitation,
    or
  • an option to switch calendar accounts easily,
    or
  • an option to select the account thanks to a "Reply with account..." button.

(In reply to Oleg K from comment #57)

(In reply to Rik from comment #56)

I didn't know about this workaround, that's useful. Still, rather ridiculous that to accept a calendar invite you would have to change the default account and restart your email programme every time...

Not every time, only once. With this guide you will change your default account permanently

I think you’re missing the point. If you have 3 invites in three different accounts, to get Thunderbird to send the response to the invite from the right email when using the “Accept” button, you’d have to change the default and restart Thunderbird at least twice (assuming one of the invites matched the current default mail account).

I think a better workaround would be just to create a profile for each account. But then you have to deal with external mailto: links launching the wrong Thunderbird…

(In reply to Oleg K from comment #57)

(In reply to Rik from comment #56)

I didn't know about this workaround, that's useful. Still, rather ridiculous that to accept a calendar invite you would have to change the default account and restart your email programme every time...

Not every time, only once. With this guide you will change your default account permanently

Incorrect. This would need to be done every time. If you get calendar invites to more than one account and want the responses to go out to the correct account, then you need to this every single invite you respond to, which is quite a lot now that everything is remote. That is not a functional workaround.

Is this bug now near to be fixed if https://bugzilla.mozilla.org/show_bug.cgi?id=1702782 is fixed?

Fascinating. The similar bug from 16 days ago is closed as fixed. Has anyone tested the fix?

(In reply to 1u from comment #62)

Is this bug now near to be fixed if https://bugzilla.mozilla.org/show_bug.cgi?id=1702782 is fixed?

Possible. It depends how it will be fixed.

I don't think the issue has been fixed. The bug above relates to a small fraction of cases where an identity* is not associated with a calendar already. This is not relevant to the problems reported here. See:

(In reply to lurix66 from comment #47)

Let me summarize.
All TB users that have multiple email accounts have a hard time in managing invitations, as:

  • sent invitations show the email identity of the calendar account, instead of the email identity of the "organizer", because one cannot set an organizer different from the calendar owner. This seems to me a limitation of the calendar service, not of TB. If I want to organize a meeting as X, I should send the invitation from a calendar belonging to X, or at least X should be a secondary email linked to the same account. TB could be made aware of the calendar ownership relation, and probably already is. I don't know if additional email identities linked to the same calendar are already managed, I believe they are not
  • received invitations which do not impinge on any known calendar, cannot be accepted, unless registering the recipient email address to an existing calendar, or creating a new one. The latter is not desirable because one may not want to multiply calendars just for one invitation. The former is not desirable because it will permanently associate the receiver email account with a certain calendar, while instead the involved calendar will differ every time, as it more likely depends on the sender or on the event, rather than on the email account that received the invitation.
  • more generally, also received invitations that do impinge on a known calendar, may in some cases need to be moved to another calendar, within those known to TB. This "move" operation could be interesting to implement, and might work also if the participant is the organizer. Other recipients, will receive a notification that a person originally registered to the event E with email identity X, changes it to Y. The person commanding the move, will see that as the event E moving from a calendar belonging to account X to one belonging to account Y.

Hope this "online reasoning" is useful to understand the severity of this issue, and to identify of a solution.
L

This is a useful summary. Looking at solutions, I am sure the code can be tweaked to accommodate a selection of the sender's address when generating the e-mail.

However, the major design flaw is the requirement for a one-to-one relationship between calendars and e-mail addresses*. These are completely different, and more importantly independent, concepts. It's the same as the relationship between mail folders and e-mail addresses.

When an invitation is sent, Thunderbird should ask which address to send it from. When an invitation is received, Lightning should ask which calendar to put it into. When accepting/declining, Thunderbird should let users change the From address of the message, which should be by default the e-mail address on which the invitation was received.

You can tell I've been burnt... Frankly, leaving the current bug makes users (i.e., me) appear downright unprofessional. Lots of users are affected (only a tiny fraction post here, and many may not bother when they see this bug has been opened for 13 years). I would suggest to immediately remove the facility to accept/decline until a proper solution is found.

  • Some people refer to identities; others to e-mail addresses. Lightning asks to associate a calendar with an e-mail address, but does it then behind the scene use the identity associated with that e-mail address? What happens with aliases (e.g., a calendar is associate with an alias; or an invitation is received on an alias of an identity whose primary e-mail is associated with a calendar)?

Thank you Francis and lurix66 for summarizing the problem so well. I'm not sure why so few people care, but it really bothers me since many years.

yeah i agree this is a great summary

great summary; would be really glad if this was solved soon. It currently turns TB useless for me regarding calendar invites - just discovered my business contacts kept receiving invites/accepts with my private email address, which is really a no-go for me.

Regarding (In reply to lurix66 from comment #47)

Let me summarize.
All TB users that have multiple email accounts have a hard time in managing invitations, as:

  • sent invitations show the email identity of the calendar account, instead of the email identity of the "organizer", because one cannot set an organizer different from the calendar owner. This seems to me a limitation of the calendar service, not of TB. If I want to organize a meeting as X, I should send the invitation from a calendar belonging to X, or at least X should be a secondary email linked to the same account. TB could be made aware of the calendar ownership relation, and probably already is. I don't know if additional email identities linked to the same calendar are already managed, I believe they are not
  • received invitations which do not impinge on any known calendar, cannot be accepted, unless registering the recipient email address to an existing calendar, or creating a new one. The latter is not desirable because one may not want to multiply calendars just for one invitation. The former is not desirable because it will permanently associate the receiver email account with a certain calendar, while instead the involved calendar will differ every time, as it more likely depends on the sender or on the event, rather than on the email account that received the invitation.
  • more generally, also received invitations that do impinge on a known calendar, may in some cases need to be moved to another calendar, within those known to TB. This "move" operation could be interesting to implement, and might work also if the participant is the organizer. Other recipients, will receive a notification that a person originally registered to the event E with email identity X, changes it to Y. The person commanding the move, will see that as the event E moving from a calendar belonging to account X to one belonging to account Y.

Hope this "online reasoning" is useful to understand the severity of this issue, and to identify of a solution.
L

This summary is really useful, but we should avoid merging several things into a single bug.

  • Received invitations: This issue is solved for my with the solution for bug 1702782.
  • Sent invitations: This is not part of the original bug report and a completely different use case. Would suggest to move it out into a separate bug. However, just figured out that I can change the identity with which the invitation is sent if I just change the first entry of the meeting (= organizer) to the e-mail address of the desired identity. While this is not obvious and has potential for improvement, it seems to work.
  • Move between calenders: Also different topic than accepting calendar invites and should be filed as a feature request.

Overall, I would suggest to close this bug as it concerns "received invitations", which should be fixed by bug 1702782, and open two other bugs for the "identity selection of sent invitations" and "move invitations between calendars"

I don't see how bug 1702782 actually resolves the issue reported here and don't that this "summary" accurately reflects it.

If a user has more than 1 email account, then it is a security (& possibly legal) risk to get an invitation received by 1 email and a reply sent via a different account. For example, a calendar is associated with email A and the user receives an invite sent to email B, the reply should never be sent via email A for any reason other than explicit user choice, the reply should be sent via email B defaulting the account which received it, always.

Invite replies should only be sent via the exact same email account that received them.

Different email accounts should be kept separate and never, never, NEVER be automatically intermixed.

Different email accounts are different email accounts!

This is a serious bug and not resolved

(In reply to puppy from comment #70)

I don't see how bug 1702782 actually resolves the issue reported here and don't that this "summary" accurately reflects it.

If a user has more than 1 email account, then it is a security (& possibly legal) risk to get an invitation received by 1 email and a reply sent via a different account. For example, a calendar is associated with email A and the user receives an invite sent to email B, the reply should never be sent via email A for any reason other than explicit user choice, the reply should be sent via email B defaulting the account which received it, always.

Invite replies should only be sent via the exact same email account that received them.

Different email accounts should be kept separate and never, never, NEVER be automatically intermixed.

Different email accounts are different email accounts!

This is a serious bug and not resolved

Looks like you haven't tried the solution of 1702782 or have a different scenario. Currently, if you receive an invite on an e-mail address different from the one of your calendar, Thunderbird will ask which identity to use for the reply. If things are still wrong, please describe the steps performed that still lead to an incorrect behaviour. Have retested my scenario reported in bug 1524055 because of an earlier discussion in this thread (comment 33) and it works now.

This is much better now, I get a popup and a dropdown to select the proper email. However.. it seems like a half baked fix.

Why do we need this popup? Why not just always send from the receiver email? I don't see a single use case when I want to use a different email for calendar response..

If we really need this popup, maybe the receiver email could be first in the dropdown?

Not only you get that popup, before that you also get a warning "you are not on the guest list", even though you are. And then the popup pre-selects the wrong email that does not belong to the account. (Tested with Thunderbird 102.)

Invite replies should only be sent via the exact same email account that received them.

Exactly! Thank you. This is the good summary. (As well as the 14 years old title of this bug)
And I see no other use case (where you want to choose an other email) neither.

Of course I was very happy to try the new select email drop down list. Definitely an improvement.
(Maybe new bug, hence not belonging here) But even now, that I can choose the email that should send the confirmation. The sender didn't got any confirmation.

to respond to the recent development: great that there has been some progress, much appreciated!
with regards to the different email addresses and choice therein: I feel the email account belonging to a calendar and the email account responding to a calendar invite should be completely separated. So for example, if an invite is sent to rik@mail.com , the calendar acceptance email should ALWAYS come from rik@mail.com. But for rik, it should be possible to save that calendar invitation to the calendar account of rik@mail.com OR ANY OTHER ACCOUNT, e.g. rik2@othermail.com. It should also be possible to choose the 'default' calendar for each email account. So eg for:

  • for rik@mail.com, I choose the default calendar to be the calendar account of rik@mail.com,
  • for rik2@othermail.com, I also choose the default calendar to be the calendar belonging to rik@mail.com, and
  • for rik@otherothermail.com, I choose the default calendar account to be the calendar belonging to rik@otherothermail.com
    But again, the responses to email invites should always come from the email account to which they are sent (although it does not hurt to give a choice there too, would be handy though if the default choice is the email account to which it is sent)

Check out Evolution on Linux for a reasonably good example of how this can be implemented.

just to note again: the solution to this is

  1. to make the email account belonging to a calendar and the email account responding to a calendar invite completely separated, and
  2. in the email account settings to provide options for what you want the default calendar to be belonging to the email address
  3. potentially give options when replying to calendar invites which reply address you want to use and which calendar account, although for me that's not really necessary, good default settings in the account settings are handier and save time.

(In reply to 1u from comment #74)

Of course I was very happy to try the new select email drop down list. Definitely an improvement.
(Maybe new bug, hence not belonging here) But even now, that I can choose the email that should send the confirmation. The sender didn't got any confirmation.

I guess, you have to activate the option to "prefer sending e-mail via the client" in the calendar.

(In reply to Lorenz Froihofer from comment #77)

I guess, you have to activate the option to "prefer sending e-mail via the client" in the calendar.

Thx! That helped.

I am using Thunderbird 102.3.1 and Lighting but I have found issue with accept invitation. When I send invitation from google and 0365 I can't accept and deny button.

Also in event I can't see any html link and when I send events with html its not going which was working fine previous version. Also my old events links also not showing properly in events.

Severity: normal → S3

(In reply to Rik from comment #75)

with regards to the different email addresses and choice therein: I feel the email account belonging to a calendar and the email account responding to a calendar invite should be completely separated.

I agree, and it's pretty frustrating that this hasn't been addressed after 14 years of discussion.

Duplicate of this bug: 1822492

I agree with @Bram and the initiator of bug 1822492.

Why waste time on building a calendar when this basic functionality is missing? It's not like no one has identified the customer need.

This is why I try to hide and remove Thunderbird Calendar. It isn't ready for prime time except for very basic use cases.

How about someone actually fix this? 14 years of people complaining should have bounced this issue up the priority list ...

Anyone??

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