CVS commit by tilladam:
When inline forwarding a mail consisting of only a top level body part,
extract that body part into an attachment of a newly created multipart/
mixed mail and create a new text part clearly identifying the mail as
a forward.
svn path=/trunk/kdepim/; revision=402419
when inline forwarding because otherwise they are falsely inherited
by the fowarded mail. I've tried to thoroughly regression test it, and
even inline forwarding opaque smime signed and encrypted mails with
attachments still works. If you are using inline forwarding, please give
it a try. If it works in all cases, we can backport it.
svn path=/trunk/kdepim/; revision=398184
this means that it is not so easy to mistype an email address and
thus causing strange errors, for example unbalanced > are not allowed
and many other cases are also caught by this validation.
BUG:95183
BUG:29571
BUG:93703
BUG:71680
BUG:74032
BUG:79169
svn path=/trunk/kdepim/; revision=391270
with attachments change the strategy for assembling the forward mail from
"make a new mail, copy the text body with some fluff, iterate over attach-
ments and attach them to the mail" to "copy the original mail, including
all attachments (possibly inline, for opaque smime), adjust the text part
in the composer, set subject, from, to as needed". That's not only simpler
but leaves the actual parsing of the message that is being forwarded to the
ObjectTreeParser in the messagecompser which can deal with things like
opaque signed mails and construct virtual bodypart for its contents. This
should finally fix aegypten isse 39/266 for good. (Yeah, right ;).
svn path=/trunk/kdepim/; revision=388759
Appearance -> Message Window which is used if there is no override codec
active (Encoding set to Auto) and the mail itself does not specify one
either. Since it is impossible to find a default for this which works
everywhere the settings defaults to locale, unless locale is eucjp in
which case the jis7 encoding is used. So if you are a SuSE 9.2 user, for
example this will default to utf8 but you can then set it to the encoding
the mails you get are usually in. iso-8859-15, for example, for germany.
Sven, thanks for reporting and insisting on this solution. It's probably
the right thing to do (TM).
BUG: 45279
BUG: 84702
BUG: 79639
svn path=/trunk/kdepim/; revision=376476
can only be moved when they have no children.
Along the way fix Bug 94125 and add the FolderRequester to the expire settings
in the folder dialog.
BUG: 94125
svn path=/trunk/kdepim/; revision=371419
(aegypten issue39) along with a fix for non-multipart messages and a fix on
top of that for inline forwarding messages with attachments.
svn path=/trunk/kdepim/; revision=370760
into an imap folder.
As per the "PATCH: KMFolderImap::slotGetMessagesData discrepancy"
discussion on the kmail-devel list.
I've tested it for weeks now without noticing any problems.
svn path=/trunk/kdepim/; revision=365366
when simply opening mail folders) : don't look for the serial numbers
of messages that haven't been inserted into a folder yet, it can't find one,
and it's slow every time. Note that assign() is only called on construction
(or soon after), never on totally-unrelated instances.
svn path=/trunk/kdepim/; revision=361937
and related things to KConfigXT. This must have been a lot of very non-
interesting grunt work, but it's a very much appreciated, so thanks a
bunch, dude. :)
Please everyone keep your eyes open for regressions, I've tried to review
it carefully, but it's big and something might have crept in.
svn path=/trunk/kdepim/; revision=361463
identity when replying in a folder with an identity set. Normally you
would not notice this, as the mails in the folder will normally have
been sent to that identity email anyhow, but if not, you'd notice, as Tom
did, and since he's been doing so much valuable bug work, it's my pleasure
to correct this.
This exposes a problem with the folder properties dialog, which sets a
folder identity always, on ok/apply, even if it's the default one, which
means when people change default identity all folders will be wrong, if
they have ever been edited. We shall have to fix that.
svn path=/trunk/kdepim/; revision=356396
when initiated via menu or hotkey (the redirect filter action
has already been fixed for 3.3).
See http://bugs.kde.org/show_bug.cgi?id=88473 and duplicates.
The dialog which collects the addresses needs further
improvements though.
svn path=/trunk/kdepim/; revision=350099
CVS commit by tilladam:
Fix issue 139 by using the mechanism we use for setting the replied and
forwarded status after a mail has been sent succesfully to move the mail
that originally triggered the sending of the accept/decline mail, whose
serial number is remembered in a link header to the trash folder configured
for that account. In other words, if you click to accept an invitation, and
then send the generated reply, the invitation mail will automagically go
away.
svn path=/trunk/kdepim/; revision=347299
strategy (iconic or inline) of the body part. Make the bodypartnode
implementation of the interface set it according to the readerwindow's
display strategy. Now bodypartformatter plugins can honor the display
strategy of the readerwindow they are invoked by.
svn path=/trunk/kdepim/; revision=346748
when loading attachments on demand. Please check if that fixes the attachment thingy.
CCMAIL: 85288@bugs.kde.org
svn path=/trunk/kdepim/; revision=334925
Now we sent redirected messages which are conform to RFC 2822.
Thanks to Ingo for pointing me into the right direction.
CCMAIL: 51283-done@bugs.kde.org
svn path=/trunk/kdepim/; revision=333330
If we do KMMessage::fromDwString(), we get to the calls that set the various
state flags from header fields. If those header fields are not there, then
setMDNSentState( 0 ) will be called. But 0 isn't a value in the resp. enum.
Catch this case and make it set the mdn sent state to unkown instead.
svn path=/trunk/kdepim/; revision=330149