| Summary | Creating a /new/ spam folder results in a setting without the correct namespace prefix |
| Queue | Ingo |
| Queue Version | 1.2 |
| Type | Bug |
| State | Duplicate |
| Priority | 2. Medium |
| Owners | |
| Requester | janne.peltonen (at) helsinki (dot) fi |
| Created | 05/29/2008 (6243 days ago) |
| Due | |
| Updated | 06/26/2008 (6215 days ago) |
| Assigned | |
| Resolved | 06/26/2008 (6215 days ago) |
| Github Issue Link | |
| Github Pull Request | |
| Milestone | |
| Patch | No |
Priority ⇒ 2. Medium
New Attachment: ingo_new_spam_folder_creation_append_namespace.patch
Patch ⇒ No
Milestone ⇒
Queue ⇒ Ingo
Summary ⇒ Creating a /new/ spam folder results in a setting without the correct namespace prefix
Type ⇒ Bug
State ⇒ Unconfirmed
folder for spam, then the spam->folder setting (and the created
script) ends up without the namespace prefix. What happened was that
the new folder was created using Ingo::createFolder()'s result, which
doesn't contain the namespace part in any case. This also explains
why, when I created a new folder and the script got activated OK and
the newly created folder ended up in the drop down menu of spam.php,
it wasn't selected in the menu: spam.php realoads the folder from the
server and gets, for instance, INBOX.newspamfolder, but the default
value of the menu ends up as newspamfolder...
I fixed the problem locally by adding a line that calls
IMP::appendNamespace($result) into spam.php... I don't know whether
this is an optimal solution, maybe it'd be better to give the
mail/createFolder function a new parameter that tells whether to
return the result with or without the namespace prefix?