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 336337 - "Send and receive mail" dialog always shows the default smtp server
"Send and receive mail" dialog always shows the default smtp server
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
2.4.x (obsolete)
Other All
: Normal minor
: ---
Assigned To: Milan Crha
Evolution QA team
evolution[smtp]
: 353705 369681 414668 449068 493239 539691 543554 548796 592717 621019 626558 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-03-28 12:46 UTC by Viktor Kojouharov
Modified: 2010-08-11 04:19 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
proposed evo patch (4.85 KB, patch)
2009-02-05 12:43 UTC, Milan Crha 		committed Details | Review

Description Viktor Kojouharov 2006-03-28 12:46:25 UTC 
Please describe the problem:
When the "Send and recieve mail" dialog is brought up, it appears that the mail
is always sent through the smpt server of the default account, instead of the
one that's actually sending the mail. The is just a bug in the interface, as the
log reveals that the mail is sent through the corrent server.

Steps to reproduce:
1. Write mail on a non-default account
2. Send mail
3. Observe


Actual results:
The dialog shows the smpt server of the default account

Expected results:
It should show the smpt server of the account currently in use

Does this happen every time?
yes

Other information:
evolution version 2.4.2.1
Comment 1 Poornima 2006-06-20 15:01:07 UTC 
Reproducible in evolution 2.6.x
Comment 2 Jonh Wendell 2006-12-15 12:09:25 UTC 
*** Bug 369681 has been marked as a duplicate of this bug. ***
Comment 3 Boris Dušek 2007-02-14 09:08:14 UTC 
Bug still present in Evolution 2.8.1, version shipped be default with Ubuntu Edgy.
Comment 4 Matthew Barnes 2009-02-04 12:32:04 UTC 
*** Bug 548796 has been marked as a duplicate of this bug. ***
Comment 5 Milan Crha 2009-02-05 12:43:00 UTC 
Created attachment 128000 [details] [review]
proposed evo patch

for evolution;

It shares lock for all infos, but I believe it'll be unnoticeable, because those guarded parts are leaved really quickly.
Comment 6 Matthew Barnes 2009-02-11 13:52:18 UTC 
*** Bug 353705 has been marked as a duplicate of this bug. ***
Comment 7 Srinivasa Ragavan 2009-02-12 08:32:44 UTC 
Milan, I don't understand why you have to do with static locks.
Comment 8 Milan Crha 2009-02-12 10:37:37 UTC 
There was suggested to use a lock (/* FIXME: LOCK */) and as I understand the request, it's to ensure that when using value in operation_status_timeout, the other thread, the worker, will not change that value in set_send_status or in set_send_account.
Comment 9 Akhil Laddha 2009-05-27 08:01:29 UTC 
*** Bug 493239 has been marked as a duplicate of this bug. ***
Comment 10 Akhil Laddha 2009-07-29 13:03:39 UTC 
*** Bug 414668 has been marked as a duplicate of this bug. ***
Comment 11 Akhil Laddha 2009-07-29 13:19:47 UTC 
*** Bug 449068 has been marked as a duplicate of this bug. ***
Comment 12 Akhil Laddha 2009-08-26 10:54:57 UTC 
*** Bug 543554 has been marked as a duplicate of this bug. ***
Comment 13 Akhil Laddha 2009-09-04 06:17:33 UTC 
*** Bug 539691 has been marked as a duplicate of this bug. ***
Comment 14 Milan Crha 2009-10-15 14:18:51 UTC 
Created commit 37cd058 in evo master (2.29.1+)
Comment 15 Akhil Laddha 2010-02-18 03:14:13 UTC 
*** Bug 592717 has been marked as a duplicate of this bug. ***
Comment 16 Akhil Laddha 2010-06-09 03:43:10 UTC 
*** Bug 621019 has been marked as a duplicate of this bug. ***
Comment 17 Akhil Laddha 2010-08-11 04:19:22 UTC 
*** Bug 626558 has been marked as a duplicate of this bug. ***