Bug 376156 - Deleting messages in IMAP account with server side folders enabled isn't possible
Summary: Deleting messages in IMAP account with server side folders enabled isn't poss...
Status: CONFIRMED
Alias: None
Product: kmail2
Classification: Applications
Component: commands and actions (show other bugs)
Version: 5.4.1
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-02-07 20:38 UTC by Alexander
Modified: 2022-08-30 11:08 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander 2017-02-07 20:38:19 UTC
New IMAP account, KDE Applications 16.12.1

I'm using server side folders (translated from the German text: »Server Abbonement«). Hitting DEL doesn't delete an email, in the right click mouse menu the delete / move to trash option is greyed out! 

If a message is regarded by kmail as SPAM and I click on the field »move to trash«, the message is moved to trash! So there is a bug, which prevents to move other emails to trash.

This is clearly a duplicate of bug https://bugs.kde.org/show_bug.cgi?id=316153 which has been erroneously cleared as a duplicate of a completely different bug.
Comment 1 Alexander 2017-03-02 10:40:16 UTC
I still can not delete Emails in an IMAP-Account. This is obviously a bug.
Comment 2 Murz 2017-03-07 07:04:13 UTC
I also very often got problems with deleting mail, especially after resume from suspend.
Comment 3 Andrej M. 2017-03-22 19:17:36 UTC
Reposting my comment in this bug ...

I wasn't affected by this bug in previous KMail versions (applications 4.14.1 and lower) but now in 16.04.3 (Kontact 5.2.3) it's here and it's extremely annoying.

- only one account out of three is problematic
- mail in Inbox cannot be moved or trashed, but copy works
- mail in other folders behaves normally, everything works
- restarting akonadi doesn't help
- restarting KMail doesn't help
- creating the account from scratch helps for a while, but then it stops working again

In summary, KMail2 is unusable for that account no matter what I do, the same account worked great in applications 4.14.1 and lower.

Best Regards,
Andrej
Comment 4 Allan Sandfeld 2017-05-31 09:38:20 UTC
I have the same problem.

What is more odd is that it happened to 3 out of 4 IMAP accounted I added all from the exact same provider (different aliases). So it is not consistent
Comment 5 Allan Sandfeld 2017-05-31 09:45:54 UTC
Seems to be the inbox folder specifically that sometimes get the wrong ACL. It can be fixed by going into the akonadiconsole, to the browser tab, right clicking on the affected inbox and change the ACL settings to allow all the basic operations that are allowed on all other folders.
Comment 6 Sebastian Held 2017-06-10 14:35:00 UTC
I have the same problem.
Comment 5 provides a workaround that works.
Comment 7 Isaac 2019-09-29 14:08:58 UTC
*** This bug has been confirmed by popular vote. ***
Comment 8 Luca 2021-08-30 08:51:51 UTC
this applies to 5.18.0 as well
Comment 9 BlinJ 2022-08-30 11:08:54 UTC
Hi, issue occured with KMail 5.20.3 (22.04.3) / KDE Plasma 5.24.6 / KDE Frameworks 5.96.0
About to give up KMail, then deleted/recreated many times IMAP mail and ingoing/outgoing server accounts, and issue magically disappeared. Move to trash button became enabled.
Misc info to help debug:
- did not fiddle with the ACL like it is mentioned in the thread
- trash is set up to move email to server-side trash, and not to local folder trash
- probably did'nt use KMail's account wizard properly at first, by the time to get used with KMail
- with my email provider (not to mention OVH), an extra "INBOX" sub-directory is present. KMail interprets tree is as such:
<KMail_account_name>
  <inbox>
    <INBOX>
      <Trash></Trash>
      <Sent></Sent>
      ...
    </INBOX>
  <inbox>
</KMail_account_name>