User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; ru; rv:22.214.171.124) Gecko/20100720 Iceweasel/3.5.11 (like Firefox/3.5.11) Build Identifier: 0.8 I use Lighting plugin for Thunderbird. When I send accept for new meet, my accept sent from DEFAULT outgoing server for icedove. It`s wrong. I need to send accept from account outgoing server (if it`s differ from default). Reproducible: Always Steps to Reproduce: 1. On remote client (MS Outlook/MS Exchange/...) create new meet and send notice to clients. 2. On client (who use icedove) get new meet notice. 3. Press on "Accept" button. Actual Results: Then accept send from DEFAULT outgoing server. It`s wrong. Expected Results: Then accept send from CURRENT outgoing server. More example. I have 3 accounts: <account> <outgoing server> email@example.com default firstname.lastname@example.org email@example.com firstname.lastname@example.org default And 2 outgoing server accounts: email@example.com (default) firstname.lastname@example.org If a get notice on email@example.com then accept send from default (firstname.lastname@example.org). But I need to send from email@example.com, because it set in account settings for firstname.lastname@example.org
Lightning will use the outgoing server of the email account that is selected in the calendar properties dialog for the calendar. If no account is selected for the calendar it will use the default one.
Ok. But can you change this behaviour? I have severel mail accounts and get a meet very often. And it`s always send from wrong outgoing server. My friends and colleagues don`t understand who accept the meet =( : they send meet on one address, but get accept from another. My friends can adapt, but when I at work it`s create a big problems.
"that is selected in the calendar properties dialog for the calendar." Can you tell us where ? Opening Preferences of Lightning from "Add-ons" opens the Thunderbird Preferences. The last tab "Lightning" contains "General, "Alarms", "Categories", "Views" and Timezone. None of them let us choose the outgoing server. I just confirmed a Skype interview for my work placement with the wrong outgoing address. He didn't notice but that's *very* annoying. People often have several email account, for friends, for work, for website where registration is compulsory ... and we don't want everyone to know all our email addresses. Can you please change the behavior to something like : reply with the same email account as the one where the invitation has been received ?
In the left pane you see the list of your calendars. Select one calendar and choose menu Edit > Calendar Properties or choose Properties from context menu or double click the calendar entry.
Ok, I set the proper outgoing server. But it's more a hack than a fix. By default, there is one calendar "Home". This means that every invitation you receive (whatever the email account you received it from) will be replied with the specified outgoing email server for "Home". Now you are aware of the bug, can you try fixing it ? I know people have life, work and familly but solving it could greatly improve user "experience" IMHO.
> Select one calendar and choose menu Edit > Calendar Properties This fix my problem because I have separated email accounts and calendars for different purposes. But I think incoming (via email) events need to be tied to email account too. Not just to calendar. And event accept need to be send from tied email account.
(In reply to comment #6) > > Select one calendar and choose menu Edit > Calendar Properties > > This fix my problem because I have separated email accounts and calendars for > different purposes. > > But I think incoming (via email) events need to be tied to email account too. > Not just to calendar. And event accept need to be send from tied email account. Algorithm: 1. Add "Email account" property for event 2. For incoming via email events set this property automayically as incoming account 3. Send accept from via email account from "Email account". If it`s empty then send from email account in calendar properties. Ughhh. It`s really can be done?
Couldn't you "just" use the outgoing server for the mail account that received the invitation? That would most probably be the expected behavior by most people. Also it's flexible. I'd pay 10€ via flattr, if done.
Unfortunately its not that trivial to fix. We currently don't have a way of saving metadata on an item level other than creating X-properties that are visible on the event. These X-properties would then also be sent back via email invitation, which doesn't make sense since the identity used to recieve the invitation is something user specific.
So you save an event independently from the mail account it is in? Is there no way to get the mail account at the time the user presses "accept" or "decline"?
Correct, we save events in a calendar, the items are not related to the mail account. The only correlation we have is the identity that saved with the calendar, which I believe we currently use for the outgoing server.
Maybe add drop-down list "Accept from..." near button "Accept"? Then user can always manually set oupgoing server when accept/decline event. I think this is good compromise.
Is this a duplicate of the following bug report? https://bugzilla.mozilla.org/show_bug.cgi?id=475886 In any event, I would like to see this bug fixed, because it is a major nuisance for people such as myself who need to have multiple work e-mail accounts.
I think the workaround (for me acceptable) is to have multiple calendars, one for each e-mail account. In calendar settings there's an associated e-mail account, so select different account for different calendars. After that, whenever an invitation arrives and you accept it, it will appear in the calendar associated to that e-mail address and the reply mail is sent from that account. I suspect this way it worked a long time ago.
Yes, this looks like a duplicate of 475886. I already have multiple calendars; work (x3); personal (x2); volunteer position etc. etc. So creating multiple calendars for multiple emails will increase the complexity and make syncronization of calendars nearly impossible. +1 for getting this fixed.
Multiple calendars didn't fixed it for me.. +1 for rshadow's solution: https://bugzilla.mozilla.org/show_bug.cgi?id=589081#c12