This is the composer not gtkhtml (I know it can be confusing :) )

this isn't actually a bug. "disabled" simply means "don't auto-check
mail for this account"

The mentioned "don't auto-check mail for this account" actually is a
seperate option in the Receiving Options tab for the account.

I assume you mean "don't check mail when hitting Send/Receive butten".
But even that is wrong:

Disabling an account actually _removes_ the account from the Folders
tree (I use IMAP). Thus I cannot see any of the mails in that account.

And as I do _not_ have _any_ data for that account visible, I should
not be allowed to send mails using that DISABLED account.


Reopening, as I don't agree and the reason for closing is wrong.

no, it's really the same option. just 2 places to set the same setting
is all.

Since we're discussing a UI issue, I'm adding anna to the Cc: line for
her input.

Hi Karsten,

Thank you for this report. 

It seems like there are a few issues alluded to within this bug -- I
am going to try to list them separately, to see if this makes it
easier for us to address them. 

Issue 1: It isn't clear to you (and probably to other users to) what
"disabled" means in the context of the mail settings.

Issue 2: There are currently two (differently worded) places to set
the same setting. 

Issue 3: You don't want disabled accounts to show up in the composer's
"From" menu. 

Issue 4: If we prohibit disabled accounts from showing up in the
composer's "From" menu, then we will have reduced Evolution's
functionality in a way that other users don't like. 

So, Issue 1 is easy to fix by changing a label. I will work on
generating a list of possibilities, and discussing them with the
development team. 

For Issue 2, we need to hear some feedback from the mail developers
about why this setting exists twice. If they don't have a compelling
reason for it to exist twice, then we should remove the duplication. 

Regarding Issue 3, I understand why you feel the way you do.. and I
understand why you want what you want. Something which I would like to
bring to the table for consideration is the fact that one doesn't
necessarily need to use the same "From" and "Reply-To" addresses. That
is, just because you send mail from an account doesn't necessarily
mean that you must receive mail at that account as well. (To use a
concrete example, I sometimes send mail from my university email
address, while setting the reply-to field for those messages to be my
work email address.)  

Is your main concern that you might make a mistake, and accidentally
send mail from a defunct address? Or are you primarily bothered by not
being able to tell from the composer which accounts are disabled, and
which aren't? Or something else? 

(Because there are different ways of resolving the "not able to tell
which accounts are disabled" thing.. we could sort the accounts in the
"from" menu, or add a separator between enabled and disabled accounts,
or something like that..) It would be great to hear from you more
about what concrete troubles the presence of disabled accounts in the
composer causes you. 

For Issue 4, we (meaning mostly I, since this is my job) need to
investigate the different ways in which people use the composer, so
that we can figure out what the costs of removing disabled accounts
would be. 

Does this sound like a fair plan?  

Jeff -- I am temporarily reassigning this to evo-mail-maintainers so
that we can get some feedback from you about the questions I asked
above . Thanks in advance for your patience.. 

Issue 1: sounds fair

Issue 2: Yea, I'm no really sure why there are 2 places to set this...
I guess the enable/disable buttons in the account-list were put there
as a shortcut or something.

I think the label in the account editor is more clear than the one in
the account-list, but that is probably largely due to the fact that a
button can't have a long label on it (well, it can, but it'd look weird).

as far as Issue #3, the From dropdown tries to distinguish between
mail accounts as much as it can - ie, if there are 2 accounts with the
same email address, it will *also* add a string to the label to say
which account name it is. Example:

Jeffrey Stedfast <fejj@ximian.com> (Work Account)
Jeffrey Stedfast <fejj@ximian.com> (Test Account1)
Jeffrey Stedfast <fejj@ximian.com> (Test Account2)

etc. Mostly I just added that bit so you were aware it existed (it
normally won't add that unless email addresses clash).

As Jeff mentioned (and I think that is what Anna is referring to)
'disabled' only is another word for 'do not auto check'. That's what
you say -- however, that is *not* the case.

As I am using IMAP accounts, I will explain it in more detail:

You can have an IMAP account, and as long as this account is
*enabled*, this IMAP accounts is visible in the folder tree. Disable
this IMAP account, and even the folders and thus my entire mails are
not visible in the folder tree.

In any case you still have the option to auto check mails, not related
to the account being visible (enabled!).

Thus:  enabled != auto check


Additionally: I can setup an account to *not* auto check mails. I get
my mails, when hitting the Send/Receive button. As long as I have this
account enabled, that is: Disabled accounts even don't get polled,
when hitting Send/Receive button.


My primary concern is, that this plainly feels wrong. If I do not see
my mails (in the folder tree) I may not be offered to send mails from
this account. That is what disabling is to me.

As disabling leaves the settings stored, it's a somewhat temporary
disabling. And as I decided I do not need account X, disabling this
account, I do not want to send mails by that account. That was my choice.


related: I have some accounts here, only to send mails from. Those
accounts uses different identities and sometimes different SMTP
servers. I do not need to disable them, to not retrieve mails, as I
have the option to set Incoming Server == NONE. I do not need to
disable them, to not check mails.

Those accounts all get forwarded to a main account. They are only for
sending purposes.

quick note: Most of you do likely know me better by my email address
used for personal mail and in the mailing lists:  guenther@rudersport.de

Issue 1: Well, I have a strong opinion about being disabled...

Issue 2: nope

Issue 3: Yep, as they are disabled.

Issue 4: May be, but I don't see how ATM.

Umm, issue 2?

Huh Jeff?  The options aren't even related, let alone being the same.

One is about automatic mail checking, the other is whether the account
is shown (for imap, etc), or mail is retrieved when you hit 'get mail'
(for pop).

The both seem pretty clear ... and separate.

Karsten, as for issue 4, some people use the disable account thing to
disable (pop) mail retrieval, on an otherwise active account.  e.g.
network issues or changes (work vs home on a laptop).  That's probably
the main case you'd want to still list the from addresses.  If you
really didn't want them, you'd probably just delete the account, perhaps?

yea, I was confused. I thought they were the same option. I was wrong.

Not Zed, unfortunately I need my disabled accounts -- in very rare
cases, but I do not want to re-enter the values if needed. They are
for testing and debugging purposes mainly [1].

I already explained, what disabling is to me. At least the *entire*
account gets disabled. Nothing states, only sending mail and viewing
mail is disabled. Can screw things up, see [2].


I actually do understand your point to issue 4 for other users,
though. Have not thought about that, cause this is not an issue for
me. Thx.

However, I could think of better (and faster) ways to disable sending
only for an account:
- going offline for single accounts
  (File / Work Offline seems to be prepared for that purpose)
- checking mails for single accounts
  (instead of always checking all accounts)


[1] Jeff can feel with me about the web.de IMAP server... ;-)

[2] This can really screw things up. Imagine an disabled IMAP account,
Sent folder is on that IMAP server. Now try to actually send a mail
for that disabled account and see your sent mail not being stored in
your specified Sent folder. :-(

Anna, any progress on this?

I still would love to see this being fixed. Jeff already posted a
patch to fix this on the patches mailing list. Maybe this can be done
for 1.4.5...


Think about the following scenario:

I am a user and one of my accounts is an IMAP server. As I want all my
mails to be accessible, I even store SENT mails on the IMAP server.
This account is currently *disabled*, so there is no connection to the
IMAP server. However, as Evolution does offer me this *disabled*
account, I write a mail choosing this account.

Where does the SENT mail go?

Yep, to the local folders -- me knows and so do you. But the user does
*not* know and probably will never find the SENT mail again, when he
has to.

At the very least: The mail is not stored as intended on the IMAP
server. If the user knows about this issue, he will remember this
particular mail being saved on a local account on a machine, he has
right now (as he needs the mail) no access to.

The user will blame Evolution for this behavior and call it a bug. And
he is right, IMHO.

Moving all 2.0 milestones to 1.5.x, please retarget if needed.

I think the "sent folder in IMAP" is a valid concern that needs to be
addressed somehow if that is the case, having sent mail end up
somewhere else is a bad thing.

Separate offline and mail checking for each account sounds like much
trouble for little gain though and makes things just overly complex.

The simplest way would be to actually do what Karsten proposes, remove
a disabled account from everywhere, just keep its settings stored for
future.

"Network issues" are not something you should face every day (or you
need to change ISPs) thus catering the UI for those sounds wrong. 

Also "home vs work" usage scenarios calls for something like the MacOS
"location" support which could be implemented Gnome-wide at some point
- the users mail settings could also be part of that framework, so
then you could select "Home" location from your network settings, and
your mail config would change accordingly. Overloading this
functionality to the enabled/disabled account is something it was not
designed for.

Tough problem. I think I'd have to choose the least of two evils and
say: Lets make "disabled" account just that - store the settings for
future, but apart from the "settings storage", a disabled account
doesnt exist, as fr as Evo is concerned. So hide it from everywhere.

  Hmm, I was pleased to see this already reported and discussed.  And
according to the last comment, it appears that the intention is make
disabled accounts invisible everywhere (except, I presume, in the
account editor ;-)).
  But I'm testing out 1.5.9.1 and still see my (many) disabled
accounts listed in the From: choices of the composer.
  So I guess I'm just asking what the status of this is.  Any news? 
Is it still targeted for 2.0?

If we make disabled accounts not show up in From:, how am I supposed
to send mail from one of my several accounts that just forwards mail
to where I actually get my mail? Disabled means "don't check for
mail", not just "don't auto-check". The terminology might be bad, or
hard to do, but the behavior is definately ideal in evolution.

  I wouldn't call it ideal.  But I'll concede that it possible that it
has more to do with poor terminology.
  Let me explain.  I have numerous aliases, some of which I use
frequently, and some of which I rarely use.  There are more rarely
used ones than frequently used ones.  When I click on the From:
selector in a compose window, my list of possible From: addresses can
easily exceed the top to bottom length of a 1024x768 laptop screen. 
Quite annoying.  So I thought that if I disabled my rarely used
accounts (that have no 'Receiving' part in the account definition, but
only a 'Sending' part), that I could limit the list to only the
frequently used ones.  No dice.  They all show up.
  My whole reasons for disabling an account is because I rarely use it
to send mail, but still want it defined so that I can just re-enable
it when I *do* want to use it.
  I'll admit that my use case may not be all that common, but given
that my custom patch for this is about *two* lines of code, I can't
believe this is all that tough to implement.  But I do know that my
patch probably doesn't do what you want.
  I strongly believe that the terminology should match the function. 
It's confusing, otherwise.  When I say DISABLE, darnit I mean DISABLE!
 If you want another function that stops mail checking, then add
another checkbox for "Don't check mail" (or it probably makes more
sense for it to be "Check mail" and have it checked by default).
  I'll attach my patch to another entry.

Created attachment 44724 [details] [review]
Make disable account checkbox *really* disable the account

The above patch applies easily to both versions 1.4.6 and 2.0.2.

Punting to 2.3 as we are UI frozen for 2.2 and looking at some unified
account setup stuff for 2.3/2.4.

adding "patch" keyword

UI team needs to decide what to do about this.

Apologies for any spam... cc'ing usability-maint on all Evolution usability
bugs. Filter on EVO-USABILITY-SPAM to ignore.

punting to 2.5 - there have been changes regarding this in 2.5 whilst the described behaviour was still valid for 2.4.

The changes made in 2.5 cannot go into 2.4 - too many string changes :(

removing old target milestone.

At least for an year now, Only enabled accounts will show up in the composer. The bug and the patch are no longer valid.

Come again?  Evolution 2.9.91 *still* exhibits this behavior.  If you'd like, I can attach screen shots, but this behavior most certainly is still present in evolution.

Patch seems to be reverted. http://svn.gnome.org/viewcvs/evolution?view=rev&revision=30493

Created attachment 84469 [details] [review]
updated patch for showing enabled accounts only in From selector

Okay, so the patch is the reverted.  But no indication anywhere as to *why*.

I've attached an updated patch to the previous comment that works against 2.9.92.  Please either apply this patch, or explain why it isn't being applied.  This bug has been opened for almost four years now and it's dead simple to fix, as evidenced by the size of this patch.

I discussed with the UI team and I don't see any reason why this patch should not go in. I am committing the patch to HEAD alone. I will defer committing to stable branch until next release.

Committed to Trunk.

http://svn.gnome.org/viewcvs/evolution?view=rev&revision=33384

Hello,
I have checked evolution-2.10.2-2.fc7 and issue is still there. Another thing that needs to be fixed is when default enabled account is disabled, it is still default.

I can see that this works fine in 2.23.x, as well as it should with 2.12, the 2.10 was too early for the patch (it was head). About the default account can be disabled, hmm, I do not think it's the wrong thing at all. Maybe only the "From" should be preset with the first account (if any) in case the default one is not available.

Created attachment 114378 [details] [review]
proposed evo patch

for evolution;

This fixes the "default is disabled" issue, the rest is fixed already.

Milan, lets not do the choice. Leave it to the user in the pref dialog when he disables it. Its better to warn user than to use a wrong account to send a mail IMO.

I'm not sure. I think it doesn't worth the option in preferences. User will be warned before sending with no From set, so I guess you can reject the patch and close this as fixed, if you would prefer way without the patch. I'm fine with that. 

Guys, can one of you update the bug summary to reflect what the remaining issue is here?  I'm having a hard time following this thread.

*** Bug 572776 has been marked as a duplicate of this bug. ***

Created attachment 132422 [details] [review]
proposed evo patch ][

for evolution;

Warn user when no active default account found.
Give me a better message text, please...

I think we can do better than a warning dialog.

What about just not allowing the user to disable the account marked as default?  We can do this entirely without extra strings or popup dialogs:

  - Hide the "Disable" menu item in the folder tree for the default account.

  - In the Mail Accounts list, desensitize the Enabled checkbox next
    to the default account (with the box checked).

  - When the default account is highlighted in the Mail Accounts list,
    desensitize the Disable button.

If the user wants to disable the account marked as default, it forces him to first pick a different default.

(In reply to comment #45)
> What about just not allowing the user to disable the account marked as default?

I'm definitely against this. Veeeeery inconvenient. I do disable my default account from time to time, and I do not want to make it default again when I want to enable it after I'm done with testing of something. Please do not do this.

Marking as a duplicate of the other bug, as there had been implemented, based on the description given there, something very similar to patch from comment #39, but who cares.

*** This bug has been marked as a duplicate of 584902 ***