| Summary | HTML/Text Signature |
| Queue | IMP |
| Queue Version | Git master |
| Type | Enhancement |
| State | Resolved |
| Priority | 1. Low |
| Owners | Horde Developers (at) , slusarz (at) horde (dot) org |
| Requester | ThomDietrich (at) gmx (dot) de |
| Created | 09/06/2011 (5064 days ago) |
| Due | |
| Updated | 02/08/2017 (3082 days ago) |
| Assigned | |
| Resolved | 01/16/2012 (4932 days ago) |
| Milestone | 5,1 |
| Patch | No |
included into the official release?
Munich/Germany) confirms, that only you will be able to change Horde
as it is OpenSource Software. Is this true?
When could you add this feature to Horde so that I can ask our ISP to
install a new version of Horde?
Best regards from Dresden/Germany.
included into the official release?
s/I had added this feature in OWM/I had this feature in OWM/
not sure if it wad me
New Attachment: sig-before.zip
discussion, but I got here googling for "IMP signature before quoted
text", so if someone gets here too, I just migrated from OpenWebmail
to Horde, and my users wanted the signature in the proper place (I had
added this feature in OWM, which we have used for 10+ years).
So here's a simple hack to place the email signature BEFORE the quoted
text, IN THE COMPOSE EDITOR (not hidden), as a SELECTABLE OPTION on
the prefs page (I'm using IMP 6.2.2, installed on Debian Jessie).
One file is a patch to be applied on /usr/share/horde/imp/lib, modifies:
lib/Basic/Compose.php
lib/Compose.php
lib/Dynamic/Compose/Common.php
lib/Dynamic/Compose.php
The other is placed in /etc/horde/imp/prefs.d, to add the option in
the prefs page (note that if you have other custom prefs "identities",
it has to be edited to include them, as it overrides the
['identities']['members']
It's been in production use here for about a week. Comments, fixes welcome.
Why isn't there simply, like in Outlook, an OPTION to either see or
not your signature when replying, have it either at the bottom of the
reply or at the bottom of the e-mail, and attaching it either to every
e-mail or only to new ones and not replies.
It's so basic there shouldn't even be any discussion about this :(
Milestone ⇒ 5,1
we don't like that solution because hacked accounts are often used to
send SPAM by hiding SPAM in horde account's signature.
Our affected users have no chance to recognize their problem and
worser they send mails with SPAM themselves!
I'm sure you will agree to my opinion that daily verification of
signature settings or sended Mails are no realistic option.
On the other hand our reputation depends on fast detection of abuse,
which is more complicated with your solution.
Please, display the signature in an extra field! So users can see if
something is wrong.
Thank you and best regards
Stefanie Wenig
adamantly refusing to see or understand the issues users are having.
Not displaying the signature at compose time is really, really poor
UX, it makes it impossible to tell what will actually be sent, and is
down right confusing for users who see their signature in every other
MUA.
A couple of solutions to the conversion problem have been raised,
either just doing the best you can to convert between formats (as
happens now to the body of the mail when switching between HTML and
text mode), or putting it in a separate box. Either would be a good
compromise, the first the better, the latter acceptable, providing
there is a setting to indicate exactly where the signature is inserted
in replies and forwards.
If you really want to keep signatures as something that is invisibly
added, maybe using a template for new messages, and one for replies
and forwards would satisfy those of us who prefer to see our mails as
they will be delivered? The functionality for using a template for new
messages already exists, so just being able to select an default one
to use on all messages would deal with the issue in that scenario, I'd
imagine having a separate template for replies and forwards, with a
placeholder for the existing message would also be possible.
Triggering a hook to process the template before showing it in the
compose window would be the icing on the cake, and allow for any
dynamic content people might want to add.
I hope, you wont' ignore my post, because I (at least partually) agree
with your argumentation why not showing the signature in the editor
window. So I don't wanna make you change that.
BUT: The problem I see is, that when someone answers an incoming
email, the signature should appear below his or her answer and not
below the original first message at the bottom of the whole email
message. For me and my clients, this makes absolutely no sense and is
absolutely counter intuitive.
(re-)implemented in IMP. The UI debacle of showing a signature in the
compose text is so bad, it actually makes me slightly physically sick
to think this was ever a part of IMP.
So to future (and past) posters - note that any further comments to
this ticket will likely be ignored.
The outcome of this ticket is somewhat different from what one would
have expected in terms of improvement. Like Janne stated, one should
always be able to see (and possibly edit) his/her signature. After
learning about the technical difficulties, one clean solution to the
whole problem could be to implement a second textfield for the
signature in the compose window.
Benefits:
- the user is able to see the signature which will be appended
- the horde/imp system is able to change/replace the signature in a
clean way
- the user could alter the signature if needed
- the user would be able to choose between multiple predefined
signatures. This is one important NEW feature which gives the
possibility to switch between formal/informal/personal signature as
well as html and plaintext signature what was my initial concern with
this ticket.
I am very thankful for your work on horde and imp! However I want to
encourage Michael Slusarz to rethink his opinion and compare it with
the feedback given in this thread...
and they suddenly couldn't see their signatures anymore. Their (and
my) opinion on this: a user should see everything they're going to
send before hitting 'Send'; what if you couldn't see a print preview
of a business letter before printing /and/ sending the printed letter
to someone? What if you, in error, used a letter template you use with
your friends? You really, really should be able to see the message, in
its entirety, as a final sanity check, before sending it.
commit 8d238daae1c893a67082cf22735d8244e12f282e
Author: Michael M Slusarz <slusarz@horde.org>
Date: Fri Nov 18 18:45:56 2011 -0700
[mms] Remove signature from compose UI; signature is no added
automatically when sending (
Request #10487).imp/compose-dimp.php | 11 ----
imp/compose-mimp.php | 6 +--
imp/compose.php | 22 +--------
imp/config/prefs.php | 12 +----
imp/docs/CHANGES | 2 +
imp/docs/UPGRADING | 13 +++++
imp/js/compose-base.js | 64 +-------------------------
imp/js/compose-dimp.js | 24 ++++-----
imp/js/compose.js | 22 ++++-----
imp/js/message-dimp.js | 4 +-
imp/lib/Ajax/Application.php | 1 +
imp/lib/Compose.php | 26 ++++++++++-
imp/lib/Compose/Stationery.php | 23 +---------
imp/lib/LoginTasks/SystemTask/Upgrade.php | 18 +++++++-
imp/lib/Prefs/Identity.php | 24 +++-------
imp/lib/Ui/Compose.php | 73
++---------------------------
imp/package.xml | 2 +
imp/templates/prefs/stationery.html | 2 +-
18 files changed, 101 insertions(+), 248 deletions(-)
http://git.horde.org/horde-git/-/commit/8d238daae1c893a67082cf22735d8244e12f282e
dealing with signatures in the message body, this is undoubtedly the
correct solution. This is going into 5.1 - there will be no more
discussion about that.
surprised to have my signature appended after sending a message. I
completely forgot about it.
In the past I also tweaked my signature sometimes like Chuck did: Add
or remove my current position depending on how "official" I want the
email to look.
Showing a message "signature is going to be added" or providing an
on/off toggle would be an improvement.
Thomas
Version ⇒ Git master
State ⇒ Resolved
with signatures in the message body, this is undoubtedly the correct
solution. This is going into 5.1 - there will be no more discussion
about that.
Still to figure out: if we want to allow signature display somehow,
and what the UI for that will be.
in my opinion you are on the wrong track. For the sake of all users
(e.g. Michael Rubinsky) please just leave it as it is if you are not
willing (or easily able, i get this) to "actually improve" like
suggested.
Best regards, Thomas
Ticket #10798. This is *exactly* one of the issues Imentioned below. And it is an example of something that cannot be
fixed reliably. Pretty much cements that signatures need to be moved
out of the compose window. (Or, at the least, it means you have to
choose between multiple sigs and having the signature in the compose
window. This is really not a close case - multiple sigs is way more
important and useful to the largest number of users.)
I don't really care what other MUA's do. Especially desktop clients -
they can do more funky things in terms of protecting blocks of text in
their compose window box. We don't have that option - javascript
event handling of textboxes is not foolproof (and I neither want to
write nor maintain this kind of code). And we don't have direct
control over the HTML input because that is handled internally by
fckeditor. This is simply a limitation of the browser features
available to us. The easiest, cleanest, and fool-proof solution is to
remove all signatures from the compose window.
STILL not buying the "user may forget" what they put into their
signature argument. I have yet to hear a credible argument about
*why* you would want to change a signature. Signatures are meant to
contain contact information. If you are regularly adding/altering
your signature, THIS IS NOT A SIGNATURE - you instead want some sort
of template functionality.
I don't necessarily think the principle of least surprise applies
here. We already perform modifications on outgoing text (e.g.
converting to multipart/related; trailer hook), so the message that is
being sent is not the same as the message the user sees in the compose
window anyway. As previously mentioned, a user can not possibly be
"surprised" by text that they created.
And in many practical uses, people don't want to see these signatures.
Some signatures may be very long (especially in professional firms
that want to put all sort of disclaimer information in there). We
don't have a giant compose entry window - adding signature information
is a waste of space that is better used for the important part of the
e-mail - the actual content.
In real word usage, a signature would be comparable to letterhead. I
can't think of anybody that would cross out information in the
letterhead to update it. If the letterhead information is incorrect,
you would use a different piece of paper.
again request, beg if necessary, that this change be reverted.
This is a *very* disruptive change IMO, especially for anyone who is
accustomed to modifying/moving the signature before sending an email.
I *really* prefer to see EXACTLY the message that I am
sending...without having to wonder what/where the mail client is going
to add something on my behalf. Also, as I mentioned before, I use
this as final sanity check that I am using the correct identity. In
these last two days, I've selected the wrong identity at least a
handful of times.
that Michael is trying to solve, and rather complicates things than
making them simpler.
My last proposed solution solves everything and brings some new
posibilities like using multiple different signatures.
In fact, it is the exact solution implemented in Outlook and other
desktop clients!
another field. Or makes it not editable. I still don't think there's
any real issue and am in favor of rejecting this enhancement request
with no changes.
signature that will be attached. I would be very disappointed if I
could no longer edit/move/remove the signature without switching
identities, but could live with it as long as I can still see which
signature is active.
For me the signature serves as a sanity check to clarify the
currently selected identity.
simple button in the new-mail-window to "insert signature" at the
end of the existing message. This way the user has the possibility
to add, change and remove his signature in the editor and my problem
with html/plaintext signature would be solved because the button
would insert the according signature.
that Michael is trying to solve, and rather complicates things than
making them simpler.
signatures, and kept it in the main window, than the proposed
solution. I often take advantage of removing my signature from
emails - like less formal work emails - and I don't want to have to
think about switching identities to do so.
edit signatures at compose time, I would pick multiple signatures
hands down.
And even though I originally voted for keeping the ability to edit
signatures, I think Michael has a few very good points that could
convince me.
Is *displaying* the current identity's signature a viable compromise?
We would still need some identity switching code, but that would be
much simpler because it wouldn't involve changing the current compose
body and Text-HTML-conversion. And it would give the user a visible
notation of what is going to be sent out. A checkbox next to the
signature area would still allow him to *not* include the signature
for individual messages.
transparent for the user.
One simple solution to all problems with the signature would be a
simple button in the new-mail-window to "insert signature" at the end
of the existing message. This way the user has the possibility to add,
change and remove his signature in the editor and my problem with
html/plaintext signature would be solved because the button would
insert the according signature.
This solution would not change the current way of using signatures but
adds new uses.
Btw. this would allow the new option to "do not insert signature by default".
Regards, Thomas
the proposed changes are worse than the current state of things. So
I'd really vote for just closing this ticket with no changes.
technical perspective. It doesn't remove the need for unreliable
text->HTML switching, and doesn't work well saving/resuming from
Drafts.
into an email that the sender never sees.
signature - he is under the expectation and knowledge that this text
is being placed on his outgoing messages.
remember what the signature they set up 3 months ago says.
signatures, and kept it in the main window, than the proposed
solution. I often take advantage of removing my signature from
emails - like less formal work emails - and I don't want to have to
think about switching identities to do so.
with adding a preference, but making it off by default. Our compose
screen is already fairly crowded and busy; this doesn't seem to be a
useful enough feature to
Removing multiple signatures doesn't help things out from a technical
perspective. It doesn't remove the need for unreliable text->HTML
switching, and doesn't work well saving/resuming from Drafts.
into an email that the sender never sees.
- he is under the expectation and knowledge that this text is being
placed on his outgoing messages.
signatures, and kept it in the main window, than the proposed
solution. I often take advantage of removing my signature from emails
- like less formal work emails - and I don't want to have to think
about switching identities to do so.
I also think it violates the principle of least surprise to put text
into an email that the sender never sees.
Milestone ⇒ 5.1
thinking about this quite a bit, and looking at some other
implementations, I made the decision to completely remove all
signature options at compose time.
Playing around with this for awhile, it makes composing much cleaner,
less confusing, and provides exactly what a signature feature is
designed to provide: a way to automatically add contact/disclaimer
information to outgoing messages based on the current identity used.
Removing the signature swapping code is a fantastic development. That
code was some of the worst to try to upkeep, especially dealing with
Text->HTML mode swapping, and did not work reliably 100% of the time.
Specifically responding to Jan's thoughts earlier in this ticket,
thinking about it long and hard the features that he seeks will not be
retained. I can not think of a valid reason why someone would need to
edit their signature at compose time. If you are editing your
signature, then you are using the signature feature for something it
was NOT designed to do - this sounds more like a use case for
templates. We already have a UI to edit signatures in the prefs screen.
Additionally, I did not provide a way to turn signatures on/off for a
given message. I do not see the utility in providing this feature,
and if it is really needed it is easily provided by generating another
identity that has empty signatures.
signature to automatically be appended at send time? In other words,
the signature never appears in the compose window. This would be
useful for users (like me) who never edit their sig.
Or maybe it is better to not add a pref at this time, when it will
just go away in 5.1 when a separate sig field is added? Although
there is no guarantee that this will be completed by 5.1, so that
should factor into the decision.
"If end of mail equals html signature use text-signature in plain
part, else convert html to plain"
markup. So a simple signature equality check is not doable without
extensive reworking of the code, which isn't going to be done.
"If end of mail equals html signature use text-signature in plain
part, else convert html to plain"
This would at least solve the normal case and the case where you
deleted the sig which i also like to do.
An extra field would also be a nice idea, you wouldn't have to edit
"around the sig"
signature before sending, e.g. to edit it or remove it completely.
An alternative solution would be to have the signature in a separate
field, so you can change it during composition, but it's still being
added after submission. That field would require a bit more logic than
the main compose area because its default mode would depend on both
the compose mode, and whether a signature of that mode exists for the
current identity. The mode need to be changed dynamically if the
compose mode or the identity changes. Finally, switching its mode
between HTML and plain text would not convert the signature but switch
between existing HTML and plain text signatures, *unless* there is no
signature in the other mode. Sounds pretty complex but might be a neat
feature for IMP 5.1 or 6.0.
Assigned to Michael Slusarz
Assigned to
State ⇒ Feedback
whether a user manually changes the signature after it is loaded in
the compose screen. We could potentially lose information if we
revert to the text version when creating the alternative, text part.
I'm wondering if the more proper solution is to NEVER display the
signature to the user, and only add it as the message is being sent.
What do the other devs think?
Priority ⇒ 1. Low
State ⇒ New
Patch ⇒ No
Milestone ⇒
Summary ⇒ HTML/Text Signature
Type ⇒ Enhancement
Queue ⇒ IMP
In a HTML-mail the "text/plain"-part has a reduced version of the
html-signature instead of the defined text-signature.
I think this should be changed.