Version: 1.2.4 (using KDE 3.5.6, Arch Linux) Compiler: Target: i686-pc-linux-gnu OS: Linux (i686) release 2.6.19-ARCH if i try to forward an email from a mailman mailinglist, the template for forwarding (as introduced in 3.5.6) is completely ignored and simply the original message text is used in the composer window that opens. i've tried also to make a new template with this =-=-=-=-=-=- Message transmis -=-=-=-=-=-= [%ODATE %OTIME] : %OFULLSUBJECT <<: %OFROMADDR >>: %OTOADDR =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= %TEXT =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= as an alternative. same outcome. for normal emails (no mailinglists) forwarding works (means the composer opens with the template parts like specified). if a mailinglist message is tried to be forwarded, the composer opens with no template-specific parts or fields but simply the %TEXT as far i can see. reproducability: so far i can see this behaviour with all mails i got over mailinglists run by mailman
What kind of template do you using? Is this per folder, per identity or global template? Can`t reproduce this locally with any kind of mailing list messages available. Another question -- does Arch using final kde 3.5.6 or some revision from svn? There are was a bug with templates fixed several days before release, so..
i have multiple identities in kmail, but the templates are configured in Composer::templates so it should not depend on a profile a closer inspection i did showed actually that its not because of mailinglists ... only messages that contained bodyPart Plain text bodyPart HTML Page are affected. any message (also from mailinglists) that has only a plain text part, is working fine. if you want, i can redirect such a message to you, so that you try it. about arch final versions... it should be the tarballs that get released for packaging... but i will check with the maintainer of kde pkgs to make sure.
SVN commit 628742 by dmiceman: Create all inline forward messages as text/plain CCBUG: 140549 M +9 -3 kmmessage.cpp --- branches/KDE/3.5/kdepim/kmail/kmmessage.cpp #628741:628742 @@ -1217,14 +1217,20 @@ msg->initFromMessage( this ); //restore type - msg->setType( type ); - msg->setSubtype( subtype ); + // msg->setType( type ); + // msg->setSubtype( subtype ); + + // set plain text content type for forwarded message + // of you change this, please test how templates work on forward + msg->setType( DwMime::kTypeText ); + msg->setSubtype( DwMime::kSubtypePlain ); } else if( type() == DwMime::kTypeText && subtype() == DwMime::kSubtypeHtml ) { // This is non-multipart html mail. Let`s make it text/plain and allow // template parser do the hard job. msg->initFromMessage( this ); msg->setType( DwMime::kTypeText ); - msg->setSubtype( DwMime::kSubtypeHtml ); + // msg->setSubtype( DwMime::kSubtypeHtml ); + msg->setSubtype( DwMime::kSubtypePlain ); msg->mNeedsAssembly = true; msg->cleanupHeader(); } else {
SVN commit 629114 by vkrause: Merged revisions 626135-629113 via svnmerge from https://vkrause@svn.kde.org/home/kde/branches/KDE/3.5/kdepim ........ r626312 | toma | 2007-01-22 21:19:10 +0100 (Mon, 22 Jan 2007) | 3 lines Backport of trunk commit 626306 by vkrause: more tolerant parsing of broken headers ........ r626502 | coolo | 2007-01-23 15:33:15 +0100 (Tue, 23 Jan 2007) | 3 lines having a different accel for plural is nonsense, sorry (removes one string as it's correct some lines below) ........ r626701 | dfaure | 2007-01-24 12:27:51 +0100 (Wed, 24 Jan 2007) | 3 lines Better avoid error while opening "*.{h,cpp}" for reading: No such file or directory ........ r626915 | winterz | 2007-01-25 00:09:52 +0100 (Thu, 25 Jan 2007) | 7 lines Put back this patch that got lost somewhere along the way. Written by Jakob and approved/committed by Till several years ago. Fixes "Paste into selected To, CC, BCC fields keeps old contents" CCBUGS: 54020 ........ r627092 | wstephens | 2007-01-25 18:07:15 +0100 (Thu, 25 Jan 2007) | 7 lines This patch uses the resource's own KABC::Lock to lock the cache file, which inhibits the file_copy operation that causes the error. The resource detects its cache is locked after having loaded the cache, but before refreshing the cache. The result of adding this lock is that if two processes are simultaneously reloading the resource, the winner will first load the cached version (call it C-1) and then load C0 after fetching it. The loser will load C-1, encounter the lock and stop. On the next iteration, Winner gets C1 and Loser gets C0. So the result of the lockstep is that loser is at most out of date by one version of the resource. A better synchronisation would be if we had distributed locks so that Loser is notified when Winner releases its lock and then loads the fresh cache file. ........ r627230 | kainhofe | 2007-01-26 05:06:46 +0100 (Fri, 26 Jan 2007) | 4 lines Don't write out empty, invalid or superfluous fields. If we have an empty organizer, an invalid URI would be generated. Fields like Sequence, CLASS, etc. have a default value (defined in rfc 2445), so we don't have to write that default value out and grow the icalendar file even more.... BUG: 140624 ........ r627323 | scripty | 2007-01-26 08:02:46 +0100 (Fri, 26 Jan 2007) | 1 line SVN_SILENT made messages (.desktop file) ........ r627419 | kainhofe | 2007-01-26 15:35:23 +0100 (Fri, 26 Jan 2007) | 5 lines Work around Windows-isms. RFC 2445 clearly says that all linebreaks are always \r\n, even under Unix, where \n is used for text files. Just because windows apparently adds the \r automatically, when you add a \n, does not mean that other platforms will do the same. Here in Linux, the file contains exactly what you put into the char*, which is a \n only and thus invalid. CCMAIL: libical@softwarestudio.org BUG: 140650 ........ r627420 | kainhofe | 2007-01-26 15:35:38 +0100 (Fri, 26 Jan 2007) | 5 lines Work around Windows-isms. RFC 2445 clearly says that all linebreaks are always \r\n, even under Unix, where \n is used for text files. Just because windows apparently adds the \r automatically, when you add a \n, does not mean that other platforms will do the same. Here in Linux, the file contains exactly what you put into the char*, which is a \n only and thus invalid. CCMAIL: libical@softwarestudio.org BUG: 140650 ........ r627541 | kainhofe | 2007-01-27 00:55:11 +0100 (Sat, 27 Jan 2007) | 6 lines When loading any url/uri (attachments, audio alarm files, procedure alarm application), make sure we load it as utf8 and not latin1. By default, QString(const char*) treats the string as latin1, so we need to use QString::fromUtf8 instead. BUG: 140688 ........ r627548 | winterz | 2007-01-27 01:32:53 +0100 (Sat, 27 Jan 2007) | 3 lines somehow this part of the templates feature merge got lost ........ r627641 | winterz | 2007-01-27 16:04:37 +0100 (Sat, 27 Jan 2007) | 4 lines Fix for the grave bug "kmail crash when I make a CTRL + J in inbox" BUGS: 140660 ........ r627763 | winterz | 2007-01-28 01:47:52 +0100 (Sun, 28 Jan 2007) | 7 lines merge SVN commit 627761 by winterz: Fix bug "Add icons for context menu on address in readerwin" Thanks for the patch Mikolaj. Hey, we only took 3+ years to commit it! :) BUGS: 66740 ........ r627911 | wstephens | 2007-01-28 16:54:12 +0100 (Sun, 28 Jan 2007) | 1 line take skipped lines into account when reporting line number ........ r627913 | wstephens | 2007-01-28 16:56:03 +0100 (Sun, 28 Jan 2007) | 1 line Fix indentation ........ r627914 | wstephens | 2007-01-28 16:56:41 +0100 (Sun, 28 Jan 2007) | 1 line Add testcases for iCalendar generated by Evolution ........ r628136 | winterz | 2007-01-29 10:46:58 +0100 (Mon, 29 Jan 2007) | 5 lines Fix for "find journals doesn't display journal title". Thanks for the patch Lars. BUGS: 132947 ........ r628168 | dfaure | 2007-01-29 12:15:13 +0100 (Mon, 29 Jan 2007) | 3 lines Laurent started kmail for a brand new user, and oh surprise, there were two actions in the Folder menu with the label "foo"! Call updateFolderMenu after creating the actions. ........ r628300 | kossebau | 2007-01-29 18:57:21 +0100 (Mon, 29 Jan 2007) | 5 lines added: context info to help with the for some translators ambigious term "address" CCMAIL:kde-i18n-doc@kde.org ........ r628362 | kossebau | 2007-01-29 22:23:14 +0100 (Mon, 29 Jan 2007) | 1 line s/IM/Instant messaging/g in i18n comment ........ r628406 | djarvie | 2007-01-30 01:45:43 +0100 (Tue, 30 Jan 2007) | 1 line Fix start-of-day time being ignored for date-only alarms ........ r628408 | djarvie | 2007-01-30 01:49:03 +0100 (Tue, 30 Jan 2007) | 1 line Fix start-of-day time being ignored for date-only alarms ........ r628518 | scripty | 2007-01-30 08:06:53 +0100 (Tue, 30 Jan 2007) | 1 line SVN_SILENT made messages (.desktop file) ........ r628565 | adridg | 2007-01-30 12:50:08 +0100 (Tue, 30 Jan 2007) | 1 line Since the KMail homepage has moved into kontact.kde.org, it's a good idea to point there instead of the deprecated kmail.kde.org. Not a string change. ........ r628578 | wstephens | 2007-01-30 14:04:27 +0100 (Tue, 30 Jan 2007) | 4 lines Refresh the pointer stored to the addressbook whenever KABLock::self() is called, otherwise we risk that StdAddressbook::close() has deleted the reference addressbook and invalidated the pointer. BUG:137269 ........ r628742 | dmiceman | 2007-01-31 08:27:12 +0100 (Wed, 31 Jan 2007) | 4 lines Create all inline forward messages as text/plain CCBUG: 140549 ........ _M . (directory) M +1 -0 akregator/src/akregator_plugin.desktop M +1 -0 akregator/src/eventsrc M +1 -0 akregator/src/mk4storage/akregator_mk4storage_plugin.desktop M +2 -2 certmanager/conf/kleopatra_config_appear.desktop M +1 -1 certmanager/conf/kleopatra_config_dirserv.desktop M +0 -1 certmanager/kleopatra_import.desktop M +3 -1 kaddressbook/Makefile.am M +5 -5 kaddressbook/addresseditwidget.cpp M +0 -1 kaddressbook/csv-templates/kaddressbook.desktop M +2 -2 kaddressbook/editors/imeditorwidget.cpp M +1 -0 kaddressbook/editors/protocols/meanwhileprotocol.desktop M +2 -2 kaddressbook/features/distributionlist.desktop M +2 -2 kaddressbook/features/resourceselection.desktop M +1 -1 kaddressbook/interfaces/kaddressbook_extension.desktop M +1 -1 kaddressbook/interfaces/kaddressbook_xxport.desktop M +2 -0 kaddressbook/kablock.cpp M +1 -1 kaddressbook/kaddressbook_view.desktop M +1 -1 kaddressbook/kcmconfigs/kabconfig.desktop M +1 -1 kaddressbook/kcmconfigs/kabldapconfig.desktop M +1 -1 kaddressbook/xxport/bookmark_xxport.desktop M +2 -2 kaddressbook/xxport/csv_xxport.desktop M +2 -2 kaddressbook/xxport/eudora_xxport.desktop M +2 -2 kaddressbook/xxport/kde2_xxport.desktop M +2 -2 kaddressbook/xxport/ldif_xxport.desktop M +2 -2 kaddressbook/xxport/opera_xxport.desktop M +2 -2 kaddressbook/xxport/pab_xxport.desktop M +2 -2 kaddressbook/xxport/vcard_xxport.desktop M +2 -1 kalarm/Changelog M +3 -2 kalarm/kalarmapp.cpp M +1 -1 kfile-plugins/rfc822/kfile_rfc822.desktop M +0 -1 kmail/KMail.desktop M +1 -1 kmail/aboutdata.cpp M +0 -1 kmail/eventsrc M +1 -1 kmail/kmail_config_appearance.desktop M +3 -3 kmail/kmail_config_identity.desktop M +1 -1 kmail/kmail_config_security.desktop M +0 -1 kmail/kmail_view.desktop M +8 -6 kmail/kmfolder.cpp M +4 -5 kmail/kmmainwidget.cpp M +9 -3 kmail/kmmessage.cpp M +6 -6 kmail/kmreaderwin.cpp M +1 -1 kmail/profiles/profile-default-rc.desktop M +2 -2 kmobile/kmobile.desktop M +1 -1 knode/knode_config_appearance.desktop M +1 -1 knode/knode_config_identity.desktop M +1 -1 knode/knode_config_read_news.desktop M +1 -1 kontact/interfaces/kontactplugin.desktop M +1 -1 kontact/plugins/kaddressbook/kaddressbookplugin.desktop M +1 -1 kontact/plugins/kmail/kmailplugin.desktop M +1 -1 kontact/plugins/knode/knodeplugin.desktop M +1 -1 kontact/plugins/knotes/knotesplugin.desktop M +1 -1 kontact/plugins/korganizer/kcmkorgsummary.desktop M +1 -1 kontact/plugins/korganizer/korganizerplugin.desktop M +1 -1 kontact/plugins/kpilot/kpilotplugin.desktop M +1 -1 kontact/plugins/specialdates/kcmsdsummary.desktop M +1 -1 kontact/plugins/specialdates/specialdatesplugin.desktop M +2 -2 kontact/plugins/test/kptestplugin.desktop M +1 -1 kontact/plugins/weather/weatherplugin.desktop M +1 -1 kontact/src/Kontact.desktop M +0 -1 kontact/src/kontactconfig.desktop M +1 -1 korganizer/actionmanager.cpp M +1 -1 korganizer/interfaces/calendar/calendarplugin.desktop M +8 -5 korganizer/kolistview.cpp M +0 -1 korganizer/korganizer.desktop M +1 -1 korganizer/korganizer_configcolors.desktop M +3 -3 korganizer/korganizer_configplugins.desktop M +1 -1 korganizer/plugins/exchange/exchange.desktop M +1 -1 korn/Makefile.am M +1 -1 kpilot/conduits/vcalconduit/todo-conduit.desktop M +1 -1 kresources/birthdays/kabc.desktop M +19 -14 kresources/remote/resourceremote.cpp M +28 -15 libkcal/icalformatimpl.cpp M +1 -1 libkcal/incidence.cpp M +2 -2 libkcal/libical/src/libical/icalcomponent.c M +2 -2 libkcal/libical/src/libical/icalproperty.c A libkcal/tests/data/Compat/Evolution_2.8.2_timezone_test.ics branches/KDE/3.5/kdepim/libkcal/tests/data/Compat/Evolution_2.8.2_timezone_test.ics#628742 A libkcal/tests/data/Compat/Evolution_2.8.2_timezone_test.ics.ical.ref branches/KDE/3.5/kdepim/libkcal/tests/data/Compat/Evolution_2.8.2_timezone_test.ics.ical.ref#628742 M +256 -272 libkcal/tests/data/Compat/KOrganizer_3.1.ics.ical.ref M +42 -44 libkcal/tests/data/Compat/KOrganizer_3.1a.ics.ical.ref M +83 -89 libkcal/tests/data/Compat/KOrganizer_3.2.ics.ical.ref M +27 -29 libkcal/tests/data/Compat/MSExchange.ics.ical.ref M +74 -89 libkcal/tests/data/Compat/Mozilla_1.0.ics.ical.ref M +0 -1 libkcal/tests/data/RecurrenceRule/KAlarm_3.4/KAlarm_TestCase01.ics M +0 -1 libkcal/tests/data/RecurrenceRule/KAlarm_3.4/KAlarm_TestCase02.ics M +0 -1 libkcal/tests/data/RecurrenceRule/KAlarm_3.4/KAlarm_TestCase03.ics M +0 -1 libkcal/tests/data/RecurrenceRule/KAlarm_3.4/KAlarm_TestCase04.ics M +0 -1 libkcal/tests/data/RecurrenceRule/KAlarm_3.4/KAlarm_TestCase05.ics M +0 -1 libkcal/tests/data/RecurrenceRule/KAlarm_3.4/KAlarm_TestCase06.ics M +0 -1 libkcal/tests/data/RecurrenceRule/KAlarm_3.4/KAlarm_TestCase07.ics M +0 -1 libkcal/tests/data/RecurrenceRule/KAlarm_3.4/KAlarm_TestCase08.ics M +0 -1 libkcal/tests/data/RecurrenceRule/KAlarm_3.4/KAlarm_TestCase09.ics M +0 -1 libkcal/tests/data/RecurrenceRule/KAlarm_3.4/KAlarm_TestCase10.ics M +0 -10 libkcal/tests/data/RecurrenceRule/KAlarm_3.4/KAlarm_TestCases.ics.all M +20 -21 libkcal/tests/data/vCalendar/KOrganizer_vCalTestCase01.vcs.ical.ref M +20 -21 libkcal/tests/data/vCalendar/KOrganizer_vCalTestCase02.vcs.ical.ref M +20 -21 libkcal/tests/data/vCalendar/KOrganizer_vCalTestCase03.vcs.ical.ref M +21 -22 libkcal/tests/data/vCalendar/KOrganizer_vCalTestCase04.vcs.ical.ref M +21 -22 libkcal/tests/data/vCalendar/KOrganizer_vCalTestCase05.vcs.ical.ref M +19 -21 libkcal/tests/data/vCalendar/KOrganizer_vCalTestCase06.vcs.ical.ref M +20 -21 libkcal/tests/data/vCalendar/KOrganizer_vCalTestCase07.vcs.ical.ref M +20 -21 libkcal/tests/data/vCalendar/KOrganizer_vCalTestCase08.vcs.ical.ref M +20 -21 libkcal/tests/data/vCalendar/KOrganizer_vCalTestCase09.vcs.ical.ref M +20 -21 libkcal/tests/data/vCalendar/KOrganizer_vCalTestCase10.vcs.ical.ref M +21 -22 libkcal/tests/data/vCalendar/KOrganizer_vCalTestCase11.vcs.ical.ref M +20 -21 libkcal/tests/data/vCalendar/KOrganizer_vCalTestCase12.vcs.ical.ref M +21 -22 libkcal/tests/data/vCalendar/KOrganizer_vCalTestCase13.vcs.ical.ref M +4 -4 libkcal/tests/readandwrite.cpp M +13 -9 libkcal/tests/runtestcase.pl M +18 -19 libkdepim/addresseelineedit.cpp M +4 -1 libkmime/kmime_util.cpp
When applying the patch given above (commit 628742) to a clean 3.5.6 source the problem is indeed solved - thank you. But it seems that this patch introduces another problem: When forwarding mails "inline", attachments are no longer forwarded. Forwarding of attachments only works when forwarding a mail as an attachment. Without the patch, both methods of forwarding work also with attachments.
SVN commit 630887 by winterz: Ingo says to revert this. So we are still looking for a fix to this bug. CCMAIL: dmiceman@ubiz.ru, kloecker@kde.org CCBUG: 140549 M +3 -9 kmmessage.cpp --- branches/KDE/3.5/kdepim/kmail/kmmessage.cpp #630886:630887 @@ -1217,20 +1217,14 @@ msg->initFromMessage( this ); //restore type - // msg->setType( type ); - // msg->setSubtype( subtype ); - - // set plain text content type for forwarded message - // of you change this, please test how templates work on forward - msg->setType( DwMime::kTypeText ); - msg->setSubtype( DwMime::kSubtypePlain ); + msg->setType( type ); + msg->setSubtype( subtype ); } else if( type() == DwMime::kTypeText && subtype() == DwMime::kSubtypeHtml ) { // This is non-multipart html mail. Let`s make it text/plain and allow // template parser do the hard job. msg->initFromMessage( this ); msg->setType( DwMime::kTypeText ); - // msg->setSubtype( DwMime::kSubtypeHtml ); - msg->setSubtype( DwMime::kSubtypePlain ); + msg->setSubtype( DwMime::kSubtypeHtml ); msg->mNeedsAssembly = true; msg->cleanupHeader(); } else {
The behaviour I get is that forwarding inline ignores templates (global and per folder) for _all_ plain text messages. ...which is a big regression from 3.5.5.
Sorry, disreagard comment #7, I meant: The behaviour I get is that forwarding inline ignores templates (global and per folder) for the plain text part of all multi-part messages. In my case, these multi-part messages are all of type 'Content-Type: multipart/alternative;'
I confirm the comment #8, the inline forwarding ignores templates for multi-part messages.
*** Bug 140994 has been marked as a duplicate of this bug. ***
I can con firm this problem on: KDE 3.5.6 Kubuntu 6.10
*** This bug has been confirmed by popular vote. ***
same bug here on kubuntu 6.10 and kde 3.5.6. any inline mail forwarding action is affected, be it using general templates or custom templates.
can somebody with rights change the subject of this bug? remove please the mailing-list and replace by "inline mail" instead. i'm the original reporter but i cannot do it. thanx
>can somebody with rights change the subject of this bug? remove please the mailing-list and replace by "inline mail" instead. i'm the original reporter but i cannot do it. thanx Done.
This bug is also present in Kubuntu 7.04 (Feisty Fawn).
Can confirm Feisty as well now too.
i do confirm it as well.
Similar behaviour here; fresh install of Kubuntu 7.04 Default global template settings are there in Settings > Configure Kmail, but don't appear when replying or forwarding emails.
Also confirmed on SuSE 10.1 with KDE 3.5.6 "release 85.1". It is a very annoying regression.
This looks like the same problem as Bug 108038. I am experiencing this in Ubuntu 7.04.
still present in kde 3.5.7 on kubuntu feisty (7.04).
Needles to say that this is still an issue in 3.5.7 (opensuse). Ugly one.
I can confirm this on kubuntu 7.04 using kde 3.5.7 It seems to be for any message that has more than one part, as someone previously mentioned. One interesting thing: i tried it for a message with only an HTML part (no text part). Basically, in this case, at first kmail says at the top of the message: "Note: This is an HTML message. For security reasons, only the raw HTML code is shown. If you trust the sender of this message then you can activate formatted HTML display for this message by clicking here." If you don't click that link to display the formatted html, and you forward without clicking that link, the forwarded message uses the template correctly, but displays the html tags in the forwarded text. if you DO click the link and then forward inline, the forwarded message still uses the template correctly but just omits html formatting/tags. This proves that the message can have any kind of single part, even if that part is not plaintext, for the template to work
Sorry to comment again but I have just noticed some interesting behavior. I have a filter set up to forward all emails from a particular email address to someone in my address book. The incoming emails from this particular email address are multi part (plain text and HTML); however, kmail DOES use the template correctly when automatically forwarding them. Once the filter is applied and mails from this address are in my inbox, i tried right clicking on the email and forwarding in line, and the template DID NOT work.
*** Bug 146019 has been marked as a duplicate of this bug. ***
I can confirm this on gentoo unstable. kmail --version: Qt: 3.3.8 KDE: 3.5.7 KMail: 1.9.7 Now there are so good features with templates and i can not use them in a way i want. Isn't there a work around?
Any news on this? I hate things that sometimes work and sometimes don't ;)
Yeap. Same issue on FreeBSD 6.2-stable. So, definitely a KDE "bug" :) Running 3.5.6
This frustrating bug is the worst I've ever seen in kmail. Surely there is a workaround?
I can confirm this behavior. Happens on Debian Etch/Lenny/Sid/Experimental with KMail 3.5.7 with mails that have a HTML part or an image part attached at least. I didn't see this really annoying behavior before KDE 3.5.7.
i completely agree to comment 30 - the introduction of the new templates system totally has broken the quite essential usage of templates for multipart messages. nowadays, where around 40% of the people in general use multipart (or their webinterface does without them knowing) this bug is quite a pain for me trying to forward or reply such emails with the correct templates. /me wonders why in the beginning, this new feature was not tested before introduction in the main tree. the new template-system is great, but this downside is quite a no-go at the moment.
Is there a workaround for this?
The fix might be a one-liner in kmail from 3.5.7 source: --- kmail/kmcommands.cpp.orig 2007-06-28 00:00:03.934212337 +0200 +++ kmail/kmcommands.cpp 2007-06-28 00:07:06.571257413 +0200 @@ -1247,6 +1247,7 @@ KMail::Composer * win = KMail::makeComposer( fwdMsg, id ); win->setCharset( fwdMsg->codec()->mimeName(), true ); // win->setBody( QString::fromUtf8( msg->createForwardBody() ) ); + win->setBody( fwdMsg->bodyToUnicode() ); win->show(); } } But somebody should check that carefully ...
I've checked the suggested fix and it appears to work for both plain and multipart mails. The template code and parser appears to be working properly, which creates the properly formatted forward message and does a mMsg->setBodyFromUnicode( body ); at the end of TemplateParser::processWithTemplate(). I suspect that, in the case of a multipart message, this does not set the same message part that the composer will eventually use. Haven't investigated this further - the trail leads on into the depths of mimelib, past the "Here be dragons" signs :-) I believe, though, that mimelib is being replaced for KDE4 which may make the problem moot. The one-line fix will solve the problem for the one more intended KDE3.5 release. I suggest it should go in - any objections?
*** Bug 108038 has been marked as a duplicate of this bug. ***
Jonathan, I think you should add your comment to the thread on the kdepim mailing list as well ( see http://article.gmane.org/gmane.comp.kde.devel.pim/20003 ), because there, the developers are more likely to read it.
I thought bug activity automatically went to that list, but if not then I'll copy...
> I thought bug activity automatically went to that list, but if not then > I'll copy... No, the mails from bugzilla get sent to kdepim-bugs at kde.org. The normal kdepim ML would be way to flooded with bug messages if we sent them there.
Is there any chance this bug is going to be fixed with next KDE 3.5 release? It is a very annoying one. I first thought I had destroyed my template until I realised that it was all fine. Forwarding mails with this bug is really annoying.
There's a good chance it will be included in KDE 3.5.8 and 4.0.0. But it would be nice if people could test with the patch provided by vondom in comment 34. If other people verify that vondom's patch works the more likely the patch is to appear in the next KDE releases.
Confirmed, it works !
SVN commit 685749 by winterz: fix templates for forwarding do not work with inline mails Thanks to vondom for providing the patch, and thanks to everyone who tested. We very few KDEPIM developers are currently swamped with KDE4 and "real life" so the extra help really is appreciated. BUGS: 140549 M +1 -1 kmcommands.cpp --- branches/KDE/3.5/kdepim/kmail/kmcommands.cpp #685748:685749 @@ -1246,7 +1246,7 @@ { KMail::Composer * win = KMail::makeComposer( fwdMsg, id ); win->setCharset( fwdMsg->codec()->mimeName(), true ); - // win->setBody( QString::fromUtf8( msg->createForwardBody() ) ); + win->setBody( fwdMsg->bodyToUnicode() ); win->show(); } }
I just installed KDE 3.5.8 (Kubuntu packages). In the past I saw that templates were not working correctly when forwarding normal mails with an attachement. Forwarding mails without attachment worked as expected though. Now what this "fix" seems to bring is that the forwarding templates do not work AT ALL anymore. Not for mails with and not for mails without attachment. So please reopen it. -Marc
hi marc i'm using archlinux packages (kde 3.5.8) and from what i can see (first tests) forwarding templates work fine for me for multipart as well as plain text emails. - D
@Marc: are you using kubuntu feisty of gutsy? The Kubuntu website says: Base packages are also available for Kubuntu 7.04 (Feisty), with more coming soon. So, if you are using feisty, kmail is propably not updated yet. -- Wouter
Feisty packages are already available: http://kubuntu.org/announcements/kde-358.php But kmail was not updated in the repositories yet. So we have to wait to see if it works or not.
Hello, I'm using 3.5.8 for 2 days now (Debain SID). I'm not affected by this bug. Check local configuration! Greetings!
Feisty packages for kmail and the others missing just came in. I tested kmail and forwarding with templates just works with and without attachment. So the bug is really fixed (if you test it keep in mind you have restart, otherwise it will still load the old version).
SVN commit 731095 by marten: Forward port of bugfix commit 685749 from 3.5 branch: fix templates for forwarding do not work with inline mails Call setReplyFocus() when forwarding, so that %CURSOR in templates works. CCBUG:140549 M +4 -0 kmcommands.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=731095