Version: unspecified (using KDE 4.7.3) OS: Linux After configuring maildir resource, the mail directory gets trashed with subdirectories like "Koncepty", "Koš", "Odeslaná pošta", "Odchozí", "Příchozí", "Šablony". I don't want these. Stopping akonadi, removing the directories manually, and restarting akonadi leads to the same - these directories are recreated immediately on akonadi start. Reproducible: Always Steps to Reproduce: switch to Czech locale (I bet it works with any locale, I just use Czech thus the names listed in this reproducer are in Czech) add "Maildir" resource (it appears like "Lokální složky" in the list) configure it to use some existing maildir, e.g. ~/.kde/share/apps/kmail/mail ls -1 ~/.kde/share/apps/kmail/mail Actual Results: archiv drafts inbox Koncepty Koš mine misc Odeslaná pošta Odchozí outbox projects Příchozí sent-mail Šablony templates trash Expected Results: archiv drafts inbox mine misc outbox projects sent-mail templates trash $ rpm -qf /usr/lib64/kde4/akonadi_maildir_resource.so kdepim-runtime-4.7.3-1.fc16.x86_64
it's translated by default. So you can't have no translated special local folder.
(In reply to comment #1) > it's translated by default. So you can't have no translated special local > folder. you don't get the point I do not care which language it is in I do not want these directories to be created at all
you can't. It's by default.
(In reply to comment #3) > you can't. It's by default. defaults can be changed what is the reasoning to create cruft on users systems and to force users to look at that cruft, and not just to look at it but also let the cruft obstruct the work with useful data? why to create those directories on startup and not only when they are really needed (possibly warning/asking user about them missing and the creation)? my usecase is that I use IMAP, I have my inbox/outbox/sent folders on the IMAP server, I do not use the local ones by default yet still I want local maildir to serve as an archive, so I add it to kmail (akonadi) too - but I want to manage the contents of the archive myself, I really do not want any software to bother me by creating subdirectories that I do not want to use (or see at all) btw, what if I switch locale, I'd have another set of directories created? - so I'll possibly (if I'd use the default folders) get data scattered in different places just because of different locale, making them inaccessible with another locale setting?
The current design requires that you have at least an outbox marked as such (sent-mail might also be needed). Might be that it needs to be also a local folder, but I;m not 100% sure of this. Otherwise you can't send mail. If you already have one set up correctly and you import another maildir, it will not add the folders. Unfortunately marking something as outbox is not trivial, there is no user GUI for that. So I think here we have two problems: 1) it is hard to mark something as a special folder (inbox/outbox/sent-mail/trash/etc) from within the UI 2) if the app runs in a different locale, it will not recognize the english named folders and will create new ones instead.
(In reply to comment #5) > The current design requires that you have at least an outbox marked as such > (sent-mail might also be needed). Might be that it needs to be also a local > folder, but I;m not 100% sure of this. Otherwise you can't send mail. hm, btw, shouldn't that be a property of the "mailtransport agent"? - RFE for adding that configuration option, where to store the outgoing mail? > If you already have one set up correctly and you import another maildir, it > will not add the folders. well, despite the fact that "set up correctly" is as clear as mud, the problem is if the order matters - you can't tell the resource migrator which order to use, for example not to mention that in practice, it doesn't work as expected - as I have those folders on IMAP, yet still I get them created when adding local maildir ... (well, I should use past tense, I haven't tested this with 4.8.1 - I don't want to break my current setup in any way :-)) > Unfortunately marking something as outbox is not trivial, there is no user > GUI for that. see above, let's file RFE then - or is that a work in progress already? btw, thinking about that, maybe it'd be better to have it per identity, not a global setting ... > So I think here we have two problems: > 1) it is hard to mark something as a special folder > (inbox/outbox/sent-mail/trash/etc) from within the UI I've found I can do that via editing the properties in Akonadiconsole ... but there is no list what attributes I can use (oh, am I supposed to read the source code?) however, to be honest, I really do not understand the idea behind that in KMail identities configuration, I can assign folders to serve some special purpose for that identity - why not rely on this? why to have the folder role defined as an attribute of the folder itself when it can have different role for different identities (in theory ... :-))? and where the role property gets used? => well, the answer to this also answers a question for which component to file a RFE to be able to manage the folder properties this way? (like if I choose something as a sent-mail folder, for example, in kmail identity properties, then it should get marked SpecialCollectionAttribute=sent-mail automagically ... the problem is the other way round, if I unselect the folder in favour of another, should it get the attribute removed?) > 2) if the app runs in a different locale, it will not recognize the english > named folders and will create new ones instead. sounds like another RFE material ... then names of subdirectories within the maildir should be in English, while it should translate to folder names according to the locale being used - unless the user renames the folder manually ... in that case, if the folder is one of the standard ones then the user should be asked whether to rename also the underlying directory name or just change the alias
This bug has only been reported for versions older than KDEPIM 4.14 (at most akonadi-1.3). Can anyone tell if this bug still present? If noone confirms this bug for a recent version of akonadi (part of KDE Applications 15.08 or later), it gets closed in about three months.
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.