Bug 492233 - Kmail does not display IMAP accounts and Maildir folders in Folder views unless they contain a folder with unread messages
Summary: Kmail does not display IMAP accounts and Maildir folders in Folder views unle...
Status: REPORTED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: Maildir Resource (show other bugs)
Version: 6.2.0
Platform: Manjaro Linux
: NOR critical
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-08-26 19:45 UTC by whatifgodwasoneofus
Modified: 2024-10-14 11:49 UTC (History)
3 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 whatifgodwasoneofus 2024-08-26 19:45:10 UTC
STEPS TO REPRODUCE
1. Configure an IMAP account (using akonadi console also works)
2. Run Kmail 6.2.0

OBSERVED RESULT
You only see the IMAP account if it contains UNREAD messages, otherwise KMail hides them!
Accounts are also NOT visible in the "Move/Copy message to folder" window (when you press M or C on a message in the message list), nor in the "Select folder" window of the search tool.
It seems that all folders-related views in the whole application discard those accounts.
Nevertheless, accounts are visible in Settings/Configure KMail tabs: they are only "censored" in the folder views...

EXPECTED RESULT
Accounts should be visible.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Linux 6.10.6-10-MANJARO, 
KDE Plasma Version: 6.1.4
KDE Frameworks Version: 6.5.0
Qt Version: 6.7.2

ADDITIONAL INFORMATION
- This just started to happen after upgrading to KDE Gear 24.08.0
- From the Akonadi Console everything looks right, I can also trigger resync with the server.
- If I go in the Browser tab of the Akonadi console, I do see the "ghost" accounts, and if I open them I see their folders grayed out.
Comment 1 whatifgodwasoneofus 2024-08-28 19:04:47 UTC
Further info:

I think the issue is in Akonadi and not necessarily in kmail (or at least _also_ in akonadi).

The folders that "disappear" (the ones "grayed out" in the DB Browser) are missing the "inode/directory" and "message/rfc822" content types in the "internals" tab of the "Folder properties" window.
However, if I look inside the DB, there indeed are records in the join table "collectionmimetyperelation": I don't know why the DB Browser doesn't show them.

If I add (manually) those mime types in the "Folder properties" window, then the folders are not grayed out anymore and they do appear in KMail - but as soon as the Akonadi indexer "touches" them, they disappear again and become grayed out in the DB Browser and "loose" the mime types associations. And, again, the "collectionmimetyperelation" table still contains the related records!

I "fixed" the issue by removing the maildir folders from the disk, so that when Akonadi restarts it re-creates them as empty dirs. Then, I have rsync'ed them from a backup one-by-one, and so far it seems that everything stays there as it should.

It will take at least another hour for the indexer to complete, then I'll know if some folders keep disappearing or not.
Comment 2 whatifgodwasoneofus 2024-08-28 19:09:57 UTC
Further info:
About the IMAP accounts: they behave like the folders of the Maildir resources (they get grayed out in DB Browser)
Comment 3 whatifgodwasoneofus 2024-08-31 19:17:15 UTC
Further Info:

I am NOT able to fix this issue permanently.

Whenever I manage to have akonadi "rescan" the maildir (or the IMAP folders), they appear in Kmail and they are not greyed out anymore in the Akonadi console.
But when akonadi restarts (either because it crashes & restarts itself, or because I restart it with `akonadi restart`), those folders are greyed out again and kmail cannot see them anymore.

I can make a new message appear in the folders, either in maildirs (by creating a new msg or by just `touch`ing an existing one) or in IMAP accounts (by manipulating the folders from another mail client), and then force a folder rescan, but this is not a viable solution!
Another workaround I found is to fiddle directly with the DB:

```
update collectiontable
   set remoterevision = NULL
 where id in (list of affected collection ids)
;
```

and then request a rescan. This is faster, but hey... it's not viable.

It seems that akonadi is not able to persist the "correct" status in the DB, I have no idea how to investigate further.


I tried both with mariadb and with postgresql backends: the behaviour is consistent.
I have also tried with removing the search_db folder and also the whole .local/share/akonadi folder: the behaviour persists.

At this point I think it's a bug... It is reproducible at each & every clean start, with any backend!

Could someone help?!