After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 342935 - Cannot send meeting requests or responses with multiple accounts with same e-mail id
Cannot send meeting requests or responses with multiple accounts with same e-...
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Calendar
1.5.x (obsolete)
Other All
: Normal normal
: ---
Assigned To: evolution-calendar-maintainers
Ximian Connector QA
Depends on:
Blocks:
 
 
Reported: 2006-05-25 16:04 UTC by Jon Schewe
Modified: 2009-12-23 14:25 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12


Attachments
evo patch (1.72 KB, patch)
2009-12-23 14:23 UTC, Milan Crha
committed Details | Review

Description Jon Schewe 2006-05-25 16:04:40 UTC
Please describe the problem:
Whenever I try and send a meeting request or respond to one I get the error
"This message cannot be sent because the account you chose to send with is not
enabled.  Please enable the account or send using another different account." 
This worked fine for me under Evolution 2.4.0, but doesn't work now that I've
upgraded to 2.6.0.  I've tried deleting and recreating my exchange account and
that doesn't appear to work.  I don't see any send options in the exchange
options.  I would expect mail to be sent with my default account which is imaps.

Steps to reproduce:
1. Create a new meeting request
2. Add users to it
3. Try and send


Actual results:
I get the error message specified above in the description.

Expected results:
The meeting request/response would be sent.

Does this happen every time?
Yes

Other information:
Comment 1 Jon Schewe 2006-05-25 16:05:45 UTC
This bug is also reported over at ximian due to the bug reporting tool in SuSE, although the link appears to try and redirect it to this bugzilla repository and then complains about the bug not being found.
http://bugzilla.ximian.com/show_bug.cgi?id=78480
Comment 2 Sushma Rai 2006-05-29 06:57:48 UTC
When you send a meeting request. please check the account you have
selected in "To:" field of the meeting editor.
Looks like it is set to some other account of yours and not the
exchange account.

Also, do you have 2 accounts (one Exchange and one some other protocol)
with the same e-mail id and If this is the case, and other accont is 
disabled, you might get the error while accepting/sending the meeting request.
Comment 3 Jon Schewe 2006-05-30 14:20:22 UTC
I have multiple IMAPS accounts and one Exchange account.  One odd thing is that the evolution calendar seems to be hanging onto my old Exchange account as well.  I had deleted my Exchange account and recreated it to fix some other errors and in the Calendar I can still see the old Exchange Calendar even though I removed the account from my preferences.
Comment 4 Jon Schewe 2006-05-30 17:55:39 UTC
I went through and managed to completely remove my exchange account (cleaned out .gconf and .evolution) and then recreated my Exchange account.  I now only see the one Exchange calendar as I should.  However I am still unable to send meeting notices.  I tried using all 3 of my work mail accounts.

My setup looks like this:
Personal imap
project imap
work archive spool
work [Default] imap
Exchange exchange

The first two have unique email addresses.  The last 3 all have the same email address.

Does this help?
Comment 5 Sushma Rai 2006-05-31 05:59:16 UTC
yes.

I think you are using "Exchange exchange" to accept/send meeting requests.

While sending, check if "Exchange exchange" account is selected in To: filed.

While receving you are seeing the problem may be because
either of or both "work archive spool" and "work [Default] imap"
are disabled. This is not an Exchange specific problem, this is the
problem with Evolution calendar. 

Chen, In this case marking "Exchange exchange" account as default will help?
Comment 6 Chenthill P 2006-05-31 07:31:45 UTC
No it wont help. The emails meeting requests are currently sent through the composer, which just checks the name or email id to identify the account. So if we have multiple accounts with same email id, the first one in the EAccountList would be chosen and if its not enabled, the error would be displayed. I guess the order of the accounts in the  EAccountList depends on the account creation time. If composer could pick the accounts based on the account id, the problem could be solved. I am discussing with the mail maintainers for a feasible solution since the composer interface is common for mail and calendar.
Comment 7 Chenthill P 2006-05-31 07:35:24 UTC
Deleting the disabled accounts with the same email id would help as of now.
Comment 8 Jon Schewe 2006-05-31 10:36:00 UTC
Yes, but then I can't read all of my mail and if I change the email id on the accounts, then messages sent from that account have the wrong from and reply-to addresses.

Please note that this did work just fine under Evolution 2.4.0.
Comment 9 Jon Schewe 2006-05-31 13:33:42 UTC
Given your comments about the first account with the same email address being picked for sending I tried looked through my settings and the first on is "work archive", which is normally disabled.  I enabled this account and now I can send meeting notices.  So this is a workaround.  

It would be good if the composer could use the account settings for the account that is picked by the user and not just the first one with the right email address.
Comment 10 Sushma Rai 2006-06-01 05:01:33 UTC
Changing the summary and moving to calendar component of evolution.
Comment 11 Suman Manjunath 2007-08-24 11:05:37 UTC
Same bug #270605 [newer version], closing as duplicate

Please feel free to report any further bugs you find.

*** This bug has been marked as a duplicate of 270605 ***
Comment 12 Chenthill P 2007-09-09 10:54:50 UTC
Hmm in IMHO its not a duplicate of bug 270605. Read through comment #6. The problem is with the composer choosing a disabled account.
Comment 13 Milan Crha 2009-12-23 14:23:32 UTC
Created attachment 150298 [details] [review]
evo patch

for evolution;

This will just ensure to choose only enabled accounts, and if not found, then keeps the preselected account in a composer window, which is the default account.

I know that extending e_account_list_find with an extra argument for "only enabled accounts" is more general, but as I think it doesn't worth it to break API here at the moment, then I decided to do it the other way.
Comment 14 Milan Crha 2009-12-23 14:25:00 UTC
Created commit 6df5254 in evo master (2.29.5+)