Tickets :: Comment on [#10447] New trash folder gets created in the shared namespace

* Your Email Address
* Spam protection	Enter the letters below: . .. ,. .. ..__. \| \| \./ \| \|\ /[__] \|__\| \| \|/\\| \/ \| \|
Comment	>> 1) The problem does not exist for "sane" namespaces. And that is >> something we can easily detect. If there either exists no namespace >> without prefix and or it exists but is the default personal namespace >> then the current code is valid and can be used. > > I agree. If the IMAP server is configured with "sane" values, we > should leverage those values and allow a power user to create > mailboxes in the non-default namespace. > >> 2) For "insane" namespaces the current code is not valid and would >> need to be amended. The situation - empty prefix for non-personal >> namespace - can easily be detected and I see two possible options: >> >> a) disallow creating "Trash", "Drafts", "Sent", and "Spam" in the >> shared namespace and always assume that the user refers to the >> personal namespace. > > It's not just the special mailboxes, it's any mailbox that can be > created from a prompt that allows definition of the full mailbox > name. (Also, better description of issue: these mailboxes are ONLY > allowed in the default namespace) > > Note that this is NOT an issue when creating mailboxes directly when > using a UI that allows explicit creation of submailboxes (e.g. > dynamic view, standard view folders.php). It is only an issue when > presented an input box that asks for a full mailbox name (e.g. > "Create new mailbox" options in pref screens; Ingo mailbox creation; > create mailbox via folders.php when submailbox is not selected) > >> b) allow the admin to set a "full path has to be used" for an IMAP >> server specified as backend so that users would have to specify >> "INBOX/Trash" if they want the folder in personal namespace or just >> "Trash" if they refer to the shared namespace. > > An admin option is pointless, since it is the user's understanding of > what they can do that matters. Not sure how you would display an > admin's decision on a config option like this to the user in any sort > of reasonable, sane manner that would not confuse 99% of the people > using the program. > >> I think it is quite reasonable to just implement (a). The only folder >> where I could imagine that users might rather wish to create it in >> the shared namespace might be the "Spam" folder. All others tend to >> contain private data that is usually not meant to show up in the >> shared namespace. So disallowing creation of special folders in the >> shared namespace does not seem much of a drawback in the "insane >> namespaces" situation. After all the admin might also still have the >> option to fix the namespaces in case the limitation introduced with >> option (a) is considered to severe. > > This is a limitation of using an "insane" namespace. Period. > Probably should be documented somewhere (INSTALL? backends.php?)
Attachment
Watch this ticket

Saved Queries