BTW, could anyone explain the reasoning behind attemptConfigRestoring?
It does quite a lot of stuff for new maildir, even before user provided a folder, which doesn't make any sense.
And if the maildir is not new, where could its config vanish?

With this change, all new maildir resources are now named "local-mail" and use ~/.local/share/local-mail/ by default, instead of something unique as before.

And this also affects new notes collections (i.e. akonotes resources) in knotes that now also always get named "local-mail" and use ~/.local/share/local-mail/ by default.

PS: AIUI, at least one thing that attemptConfigRestoring() does is trying to give every new resource a unique storage location, something like ~/.local/share/akonadi_maildir_resource_1/ (or ~/.local/share/notes/akonadi_akonotes_resource_1/), by default.

Also, I think this would now always change the resource name (to the name of the directory) when the user reconfigures the storage path, even if it was explicitly set to something (like "My mails") before.
I'm not sure that's really desired?

In D27905#630324, @wbauer wrote:

Also, I think this would now always change the resource name (to the name of the directory) when the user reconfigures the storage path, even if it was explicitly set to something (like "My mails") before.
I'm not sure that's really desired?

And as I just noticed, it also renames the default resources.
If you try on a fresh user account, they will be named according to the used directory now instead of a translated "Local Mail" or "Notes".

I'm not yet sure it works as expected together with D28523: Save configuration when creating resources for new user, it still needs testing.

When I create a new user, sometimes "Local Folders" get created right after first login, but the folder is akonadi_maildir_resource_0 (instead of local-mail);
sometimes "Local Folders" get created only after I run KMail for the first time, with the proper folder ("local-mail"), but also sometimes KMail crashes with weird Invalid parent message.
Weird as hell. Need to investigate it.

UPD: OK, it might have been an issue with not-so-fresh-start. I tried removing whole home folder of a new test user, rebooting and logging in, it seems to be working just fine, new resources are created with a proper name and proper folders.

And I am still able to change the folder of an existing resource so some another place, as well as create a new resource in non-default localtion. However, I would appreciate if someone tested it too, just to be sure...

Since D28523: Save configuration when creating resources for new user was landed, I think this one should be fairly safe to land.
Any objections? Should I go for 20.04 branch?

No objections from my side.

I just tested it a bit (sorry for the delay...), and I can't seem to reproduce the problems I noticed with the first version (i.e. the default resources are named as expected now, new resources get a unique folder by default again).
Changing the path for an existing resource seems to work as expected now too (I still have to manually "Restart" the resource to actually see the content of the new directory, but that's certainly unrelated to this change).

The summary is no longer correct though, at least the last paragraph.

PS:

In D27905#640353, @poboiko wrote:

but also sometimes KMail crashes with weird Invalid parent message.

That's probably https://bugs.kde.org/show_bug.cgi?id=380171.
Happens here too on a fresh account when starting kontact the first time (subsequent starts are fine).

I had a slight hope that maybe your other patch ( D28523 ) might fix that, but apparently not unfortunately...

In D27905#660917, @wbauer wrote:

(I still have to manually "Restart" the resource to actually see the content of the new directory, but that's certainly unrelated to this change).

Sorry, I just noticed that I tested this *without* the patch applied by mistake.
With the patch, the change actually is picked up immediately now and the resource automatically shows the new directory's content.

So definitely an improvement, I'd say.