GNOME Bugzilla – Bug 739059
Wrong mail account chosen when Forward as iCalendar
Last modified: 2017-09-19 11:55:46 UTC
With Debian Sid/unstable and Evolution 3.12.7 and Evolution-Data-Server 3.12.7.1 forwarding an event/meeting in the calendar as iCalendar file (*.ics) [1], the “From” account from the organizer is not automatically chosen, but the account from the current account in the Mail view. [1] https://help.gnome.org/users/evolution/stable/mail-calendar-sending-invitations.html
*** Bug 739207 has been marked as a duplicate of this bug. ***
One part of the problem seems to be that the meeting component editor allows picking disabled mail accounts, which cannot be used when the notification about meeting changes is sent. I just tried it, I picked a disabled account and a default account was used instead, but when I picked an enabled account, then it was used. Can that be the same for you?
(In reply to comment #2) > One part of the problem seems to be that the meeting component editor allows > picking disabled mail accounts, which cannot be used when the notification > about meeting changes is sent. I just tried it, I picked a disabled account and > a default account was used instead, but when I picked an enabled account, then > it was used. > > Can that be the same for you? No, it still took the default account.
The other reason can be that there is no Mail account configured with the organizer's e-mail. I might lead this in a wrong direction. Let's try to summarize some steps: a) go to a Calendar view b) have a meeting which has set an organizer whose email is from one of the enabled Mail accounts c) right-click such meeting and choose 'Forward as iCalendar' A message composer is opened which should have preselected the used organizer from the meeting, but if the corresponding mail account is not set as a default account, then it is not preselected either. The same applies when the c) is changed to (from bug #739207): c) edit a meeting, change the organizer to another non-default enabled Mail account and save the changes, then send the change to the attendees. While the new organizer's email address should be used, the background processing sends the message from the default account (not even from the previous organizer's email account). Is this it? I know these things look differently, but they use a common code in the background, or close enough, that I decided to merge the bugs. If I realize in the future that that was a wrong idea, then I will de-duplicate the bugs.
One part of the problem was that when the PUBLISH method had been requested then there was not made any attempt to figure out the correct account from attendees. The other part was that the attendees had been checked on a sanitized component, which doesn't contain any attendee. both fixed with the below change, which also fixes the alternative c) from the above comment. Only note that when the source component doesn't have set neither organizer nor attendees, aka it's a regular event, then the default mail account is chosen, eventually "the first" known and enabled, where the order is more or less unpredictable (GHashTable being involved). Created commit 61cca34f39 in evo master (3.27.1+) Created commit 920ec2c4d7 in evo gnome-3-26 (3.26.1+)