Bug 342756 - Clicking on read/unread icon in Kmail's message list removes attachment icon/flag instead
Summary: Clicking on read/unread icon in Kmail's message list removes attachment icon/...
Status: REOPENED
Alias: None
Product: kmail2
Classification: Applications
Component: message list (show other bugs)
Version: 5.16.3
Platform: Kubuntu Linux
: HI major (vote)
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-12 06:31 UTC by Larry CK
Modified: 2021-12-26 23:18 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.14.6


Attachments
attachment-21477-0.html (1.34 KB, text/html)
2017-06-28 04:41 UTC, Larry CK
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Larry CK 2015-01-12 06:31:08 UTC
There are several Kmail bugs reporting issue with attachment icon (Bug 291332; Bug 292399; Bug 286692).

Bug 291332 discussion suggests, that issue with attachment icon not showing up in Kmail is to do with Akonadi. I'm sorry, if this bug is not properly filed as I do not know Akonadi components.

I hope that Akonadi developes can resolve the issue as Kmail (Kontact) is great application, but not being able to find required e-mail quickly is a deal brakef for business use.

Reproducible: Always

Steps to Reproduce:
1. Konfigure e-mail account on Kontakt (Kmail). (I have tried with Gmail and Exchange 2012 through DavMail)
2. Receive e-mail with attachment
3. View e-mail
4. Close Kontact (kmail)
5. Re-open Kontakt
6. Find the e-mail with attachment

Actual Results:  
attachmnt icon next to an e-mail withattachment is not shown. Filteriing (to show e-mail with atachments only) does not show e-mail with attachments, when it should.

Expected Results:  
Attachment icon is shown next to e-mails with attachments. Filtering e-mail list (to show e-mail with attachments) procžduces a klist of e-mails with attachmets in them.

Kmail Bug 291332 suggests the root cuse of the issue is in Akonadi
Comment 1 Martin Koller 2015-01-31 14:50:45 UTC
Git commit 0cb0e2f5efc7d76033f9b9ccc83aeebe9845f338 by Martin Koller.
Committed on 31/01/2015 at 14:44.
Pushed by mkoller into branch 'KDE/4.14'.

Fix missing mail flags; avoid code duplication

This patch uses the new method Akonadi::MessageFlags::copyMessageFlags()
to copy the mail message flags into Akonadi objects, avoiding
code duplication.
Some places did not do this previously leading to mail flags never
appearing (or getting lost) in Akonadi
Related: bug 286692, bug 313401, bug 327241
FIXED-IN: 4.14.6
REVIEW: 122224

M  +1    -1    CMakeLists.txt
M  +1    -13   resources/imap/messagehelper.cpp
M  +3    -0    resources/maildir/maildirresource.cpp
M  +2    -0    resources/maildir/retrieveitemsjob.cpp
M  +6    -0    resources/mbox/mboxresource.cpp
M  +3    -0    resources/mixedmaildir/mixedmaildirstore.cpp
M  +2    -9    resources/pop3/pop3resource.cpp

http://commits.kde.org/kdepim-runtime/0cb0e2f5efc7d76033f9b9ccc83aeebe9845f338
Comment 2 Larry CK 2015-03-05 08:30:26 UTC
(In reply to Martin Koller from comment #1)
> Git commit 0cb0e2f5efc7d76033f9b9ccc83aeebe9845f338 by Martin Koller.
> Committed on 31/01/2015 at 14:44.
> Pushed by mkoller into branch 'KDE/4.14'.
> 
> Fix missing mail flags; avoid code duplication
> 
> This patch uses the new method Akonadi::MessageFlags::copyMessageFlags()
> to copy the mail message flags into Akonadi objects, avoiding
> code duplication.
> Some places did not do this previously leading to mail flags never
> appearing (or getting lost) in Akonadi
> Related: bug 286692, bug 313401, bug 327241
> FIXED-IN: 4.14.6
> REVIEW: 122224
> 
> M  +1    -1    CMakeLists.txt
> M  +1    -13   resources/imap/messagehelper.cpp
> M  +3    -0    resources/maildir/maildirresource.cpp
> M  +2    -0    resources/maildir/retrieveitemsjob.cpp
> M  +6    -0    resources/mbox/mboxresource.cpp
> M  +3    -0    resources/mixedmaildir/mixedmaildirstore.cpp
> M  +2    -9    resources/pop3/pop3resource.cpp
> 
> http://commits.kde.org/kdepim-runtime/
> 0cb0e2f5efc7d76033f9b9ccc83aeebe9845f338

That is a good new. Thank you for the fix! But there is a downside to it as well. It sais it is fixed in version 4.14.6, KDE website latest announcement is that version 4.14.3 is released, OpneSUSE has pushed 4.14.4 to its users. With KDE working hard on V5 (and I for one can't wait until is good enough for daily use)  4.14.6 release seems to be some time away.

From what I understand, there was one line of code added to 6 files. Maybe there is a way to match those files in  4.14.4? i'd appreciate if someone could give instruction on how to patch it in.
Comment 3 Wolfgang Bauer 2015-03-05 19:33:39 UTC
(In reply to Larry CK from comment #2)
> That is a good new. Thank you for the fix! But there is a downside to it as
> well. It sais it is fixed in version 4.14.6, KDE website latest announcement
> is that version 4.14.3 is released, OpneSUSE has pushed 4.14.4 to its users.
> With KDE working hard on V5 (and I for one can't wait until is good enough
> for daily use)  4.14.6 release seems to be some time away.

No. 4.14.6 has been released last Tuesday, together with KDE 14.12.3.
See https://www.kde.org/announcements/announce-applications-14.12.3.php, you'll find this fix in the "full changelog" for kdepim-runtime.

> From what I understand, there was one line of code added to 6 files. Maybe
> there is a way to match those files in  4.14.4? i'd appreciate if someone
> could give instruction on how to patch it in.

Probably. Click on the link in comment#1 to download or view the patch. Then apply the changes to the downloaded source manually or use the patch command to apply them.

Do you know how to compile kdepim from source?
If not, you'd probably better just wait until openSUSE releases the next KDE update, which will contain KDEPIM 4.14.6.
This might take a few weeks though, but the packages should be available in the update-test repo as soon as the update is submitted (probably in the next days) if you don't want to wait that long:
http://download.opensuse.org/update/13.2-test/
Comment 5 Larry CK 2015-03-23 12:31:33 UTC
Hey. So OpenSuse has pushed 4.14.6 updates out this weekend, but I don't see the fix. I'f I select e-mail with an attachment, and then click on the envelope icon to make the message "unread" - the paper clip (attachment) icon dissipaters forever.
Do I need to change some setting or do something in extra to get the patch to work?
Comment 6 Wolfgang Bauer 2015-03-23 13:19:53 UTC
(In reply to Larry CK from comment #5)
> Hey. So OpenSuse has pushed 4.14.6 updates out this weekend, but I don't see
> the fix. I'f I select e-mail with an attachment, and then click on the
> envelope icon to make the message "unread" - the paper clip (attachment)
> icon dissipaters forever.
Hm. You're right.
I can reproduce this when clicking on that envelope icon (I didn't even know one can mark the mail read/unread by doing this).
I tried with a mixed_maildir_resource btw.

It seems to work fine when I mark it as read/unread via the context menu though.

Anyway, reopening.
Comment 7 Wolfgang Bauer 2015-03-23 13:23:36 UTC
PS, to clarify:
Clicking on the "envelope" icon in the mail list _only_ removes the "attachment" icon without actually changing the read/unread state. Clicking again changes the read/unread state.

This actually seems totally unrelated to Akonadi's handling of mail flags.
It would seem to me that KMail changes the wrong flag in this case.
Comment 8 Larry CK 2015-03-23 13:56:49 UTC
(In reply to Wolfgang Bauer from comment #7)
> PS, to clarify:
> Clicking on the "envelope" icon in the mail list _only_ removes the
> "attachment" icon without actually changing the read/unread state. Clicking
> again changes the read/unread state.
> 
> This actually seems totally unrelated to Akonadi's handling of mail flags.
> It would seem to me that KMail changes the wrong flag in this case.

Yes, you are correct. Issue affects "smart with clickable status" theme. First click removed attachment flag, subsequent clicks change read/unread status. Do you know if kmail can be forced to recheck the flags and restore attachment flags?
Comment 9 Wolfgang Bauer 2015-03-23 14:05:55 UTC
(In reply to Larry CK from comment #8)
> First click removed attachment flag, subsequent clicks change read/unread
> status. Do you know if kmail can be forced to recheck the flags and restore
> attachment flags?

No idea.
I think KMail/Akonadi will re-evaluate the flag when the mail is no longer in the cache.
So it should resolve itself eventually I guess.

You could explicitely set the flag to the mails where it is missing with akonadiconsole (go to "Browse", select the message, switch to the "Internals" tab, and add a "$ATTACHMENT" flag).
But deleting the cache for the affected folders should "fix" it as well I suppose (right-click on the folder and choose "Clear Akonadi Cache").
Comment 10 Denis Kurz 2017-06-23 20:01:02 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 11 Wolfgang Bauer 2017-06-27 17:41:02 UTC
Yes, this is still reproducible in the latest version 5.5.2.

Although, meanwhile you apparently have to click on the read/unread icon twice to have the attachment icon disappear. It doesn't seem to happen the first time.
Comment 12 Wolfgang Bauer 2017-06-27 18:22:08 UTC
(In reply to Wolfgang Bauer from comment #11)
> Although, meanwhile you apparently have to click on the read/unread icon
> twice to have the attachment icon disappear. It doesn't seem to happen the
> first time.

Small correction: apparently it happens if the mail is unread and you click on the read/unread icon to mark it as read.
It does not happen if the mail is read and you toggle it to unread.
Comment 13 Larry CK 2017-06-28 04:41:22 UTC
Created attachment 106349 [details]
attachment-21477-0.html

I canconfirm it too. Version 5.3. But attachment icon seems to dissapear
after marming email as read only when messageist theme "smart with
clickable status" ienabled. It does not happen with "smart" theme.

On 27 Jun 2017 9:22 pm, "Wolfgang Bauer" <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=342756
>
> --- Comment #12 from Wolfgang Bauer <wbauer@tmo.at> ---
> (In reply to Wolfgang Bauer from comment #11)
> > Although, meanwhile you apparently have to click on the read/unread icon
> > twice to have the attachment icon disappear. It doesn't seem to happen
> the
> > first time.
>
> Small correction: apparently it happens if the mail is unread and you
> click on
> the read/unread icon to mark it as read.
> It does not happen if the mail is read and you toggle it to unread.
>
> --
> You are receiving this mail because:
> You reported the bug.
Comment 14 mateMat 2021-05-20 13:29:47 UTC
Still struggling with this bug.
It seems to be a UI problem in the way that the clicking action triggers the wrong outcome.
Can we up this bug to find a fix? I use these icons all the time, because they are very convenient.
Best
Comment 15 Erik Quaeghebeur 2021-12-26 23:18:04 UTC
This indeed still an issue with current versions (I'm using 21.08.3/5.08.3, but this is not in the selectable list) and actually it similarly affects the important status.

* (Twice?) clicking the unread/read icon removes a present attachment icon; this corresponds to removing the $ATTACHMENT flag
* Marking an unread important message as read by clicking the icon removes the important status; this corresponds to removing the \FLAGGED flag

I'm increasing the importance, because given that the importance status is, unlike the attachment state, purely user-assigned, this causes data loss.