The ComposerPageState JS object assumed that if no signature was present
when first loaded, that none ever would be. This broke changing the
signature when the composer was opened for an account without one, and
the from account was changed to an account with a sig.
Instead of including the signature as part of the loaded body, always
include just a skeleton signature DIV and ensure the signature is loaded
dynamically after the body has been loaded. Update code and tests to
match this assumption, and add a unit test for updating the sig.
Fixes#309
Some software like the above will mangle From mailbox names by appending
"via Some Service" to the From mailbox name. This messes up generating
default avatars for the actual people sending these messages, so
attempt to de-mangle the names.
This involves moving primary originator determination from the engine
to the client, since it's now a policy thing. Add unit tests.
This allows either type to be used interchangably as a source of
header data. Add documentation comments for the headers, add missing
message_id property to RFC822.Message.
Don't try to dray null initials, actually return null per API contract
when no initials can be found, don't include non-alphanumerics in the
initials. Add test case.
This ports the code written by Felipe Borges for GNOME/Initiatives#6 to
vala, and uses that when no Folks individual was found or it does not
have an avatar.
Services like GitLab and mailing lists will use the same From address
but the actual user's name as the mailbox name. By using the mailbox
address as the cache key, these all get lumped together. This will make
different sender names use the same initials, so use the short display
name as the cache key instead.
AccountInformation.load_outgoing_credentials (and incoming) should be
true in case there's no credentials, but also loading ougoing must use
the incoming service and credentials when USE_INCOMING is set.
Fixes SMTP side of #301 at least.
Commands that were cancelled, e.g. because the network connection was
lost and so commands in progress were backed out, were throwing
timeout errors to callers of wait_until_complete since they had received
no response. This was causing e.g. account operations to fail, and the
alleged timeout be reported as problem in the UI.
This takes note of whether a command was cancelled and throws an
appropriate error in wait_until_complete if so. Callers can then clean
up and choose to be more circumspect in their error reporting.
Fixes#285
