Bug 340237 - kmail "send later" does not store copy of mail in "sent" folder
Summary: kmail "send later" does not store copy of mail in "sent" folder
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kmail2
Classification: Applications
Component: general (show other bugs)
Version: 4.14.1
Platform: Debian testing Linux
: NOR critical
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-22 19:54 UTC by Nigel Kukard
Modified: 2018-01-31 16:51 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nigel Kukard 2014-10-22 19:54:40 UTC
When using the "Send Later" feature sent mail is not being copied to the "Sent" folder.

The "Sent" folder works 100% using "Send Now".

I first thought it was kdewallet that may be closing and the credentials not being retrieved, but thats not the case.


Reproducible: Always

Steps to Reproduce:
1. Setup kmail with an imap email box, set the "sent" folder
2. Compose an email to any other email address and use "Send Later", select 1 hour later
3. Wait for 1 hour until it triggers, the email is received, but not in the "Sent" folder

Actual Results:  
The copy of the sent mail is lost

Expected Results:  
The copy of the sent mail should be in the configured sent folder

I have tried this very many times over the past couple of days with a 100% accuracy in reproducing this problem.
Comment 1 Laurent Montel 2014-10-23 05:55:18 UTC
It's normal.
And when it will send it will stored in "send folder" but not before.

Regards
Comment 2 Nigel Kukard 2014-10-23 06:00:07 UTC
Hi Laurent,

I think you misunderstanding. It is never placed in the sent folder.
Comment 3 Nigel Kukard 2015-06-07 18:35:07 UTC
Is this possibly related to 342059?
Comment 4 Denis Kurz 2017-06-23 20:04:24 UTC
This bug has never been confirmed for a KDE PIM version that is based on KDE Frameworks (5.x). Those versions differ significantly from the old 4.x series. Therefore, I plan to close it in around two or three months. In the meantime, it is set to WAITINGFORINFO to give reporters the oportunity to check if it is still valid. As soon as someone confirms it for a recent version (at least 5.1, ideally even more recent), I'll gladly reopen it.

Please understand that we lack the manpower to triage bugs reported for versions almost two years beyond their end of life.
Comment 5 Denis Kurz 2018-01-31 16:51:47 UTC
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.1 aka 15.12, preferably more recent), please open a new one unless it already exists. Thank you for all your input.