Until recently it was possible to set certain properties (retrieve frequency) of a collection of IMAP folders by editing the properties of the parent folder, be it the account entry in the folder list, or a parent folder like "[Google Mail]". It seems that this is still possible for "regular" folders (like the "Devel" folder under which I have gmail store folders for KDE, MacPorts etc. mailinglists), but it no longer is for "[Google Mail]" or the account entry. Reproducible: Always Steps to Reproduce: 1. Right-click an entry in the mailbox folder 2. Select the properties action Actual Results: The action has been deactivated for the "account folder" as well as for "[Google Mail]", among other actions. Expected Results: It should be possible to set at least certain properties on those folders too, like the retrieval interval. After all the folders directly underneath (Inbox, "All Mail" etc) do have the option to use their parent folder's property for those settings. Because of that I'm marking this a major issue. I discovered this when I wanted to deactivate indexing for several folders at once, tired of having to wait for a folder sync each time I want to change that folder's properties. I'd deactivate email indexing altogether as used to be possible in the nepomuk days, but apparently we no longer have that choice...
RJVB, thank you for your report. I can still see this in KDEPIM 15.08. There is no context menu choice for "Folder Properties" of the toplevel folder of an IMAP account.
The option now reads "Use options from parent folder or account", so it should be quite clear how to apply settings to all top-level folders. From the wording, we can tell that this is an intended change instead of a major regression. Actually, this was never major, as there has always been a relatively obvious way to work around it (by configuring the account itself). The fact that the context menu of accounts in the folder list does not have an entry to configure that account might very well be considered as a UX bug. The regression reported here, however, is now clarified by wording. I close this as fixed. Feel free to disagree.