Default account bug?

Setting the default account does not seem to work as documented.  I have two accounts that I send from.  Let’s call them A and B.  I have the “default account” set to A.

When I’m displaying any folder that is NOT under the B account, then a new message uses the (default) A account as the sender – as it should.  But when I’m displaying any folder that is under the B account, then a new message uses the B account as the sender – ignoring the default account setting.  It appears that the logic to default accounts is:

  1. If any folder under account x is being displayed, then x becomes the assumed (“local” default?) sender.

  2. Otherwise, whatever account has been set as the default account becomes the sender.

I understand the logic of this, and I understand that there’s a reasonable argument for doing this.  However:  (a) this is not what “default” generally means, (b) this behavior is NOT documented, and © this is NOT how Outlook behaves with respect to setting a default account.

Regarding ©, this seems odd since elsewhere eM Client appears to seek to implement Outlook behavior so far as this is reasonable, and the Outlook behavior is:   “Default” really means DEFAULT – so that when sending a NEW message, determination of the default sender is NOT context-sensitive with regard to which account is currently the “selected” one being displayed.

It appears that eM Client employs a context-sensitive determination of “default account” that is inconsistent with its documentation, with the standard sense of “default account”, and with the behavior of Outlook.  Seems like a bug one way or another.  And easy to fix – since there must be code in there that actually detects the context and ignores the default account setting?

Am I missing something here?

No, you are not missing anything - it is intended behaviour not a bug. The default mail account has other functions, but when you are in a specific account’s folders, that is the account that will be used to send messages.

Ah, then it’s worse than I thought.  

From the WebHelp:

“Default account will be used when a specific account cannot be detected for use. This means the Default account will be applied to new messages, contatcs [sic], events, etc. when the focus is set in Smart folders or Local folders.”

Unfortunately, this is buried in the WebHelp and isn’t seen in the UI where the default account is set.  Adding it there might at least go some way towards avoiding confusion and warn the user of the intended behavior at the point where the feature is set.

But this whole approach reduces  the utility and sense of the “default account” since it renders it meaningful only in the case of Smart/Local folders.  In the case of other folders, the account used is ALWAYS context-dependent.  There simply is no default account except for Smart/Local folders!  So it’s really an odd concept of “default” – a “relative” one rather than an absolute/universal one as in Outlook.   Saying that something is “the default … EXCEPT WHEN …”  is a very unusual notion of default.  Simply calling it something like “the Smart/Local default account” – and adding this in the UI where the value is set – might clarify things.  But it still strikes me as goofy, though I won’t go into any more details of that here.  

I wouldn’t make such a big deal of this except that it’s an unusual and surprising deviation from the common sense of a “default account” and it’s caught me unawares several times where I’ve unthinkingly sent messages from one account that I thought would be sent from another  (because I’d set the default a la – I thought – Outlook).  In addition, I don’t really see the utility of this restricted notion of “default” and think it would be less confusing and easier simply to eliminate this peculiar “default” concept rather than to implement it in this way and invite confusion.  But that’s a different matter.  At least now that I know that it’s a “feature” rather than a bug, I can better avoid stepping into that hole.

Glad you found the explanation you were looking for. :wink: