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

* Your Email Address
* Spam protection	Enter the letters below: .__ .__ . .. . . [ __[__)\| \|\| \| \| [_./[__)\|__\|\|/\\|\__\|
Comment	> I admit I didn't see the problem you described before and I agree it > exists. A user saying "I want 'Trash' to be created" could mean > "INBOX/Trash" or just "Trash" in the shared namespace if the prefix > of the default personal namespace is "INBOX/" and "" for the default > shared namespace. > > BUT... > > 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. > > 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. > > 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. > > 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. > > I would only implement (b) in case there is some protest about this > being something that really needs to be configurable. But based on > the reasoning above I really don't expect that. > > Do you agree? If so - is this something I should start coding a patch > for? Because I really need to get that fixed :)
Attachment
Watch this ticket

Saved Queries