Apparently, yes. That is, it seems to separate the INGO preference 
from the IMP preference so that if I save the spam folder in INGO, it 
doesn't get overwritten (from the IMP preference) the next time I log 
in. However, the IMP idea of the spam folder doesn't change if I 
change the spam folder in INGO - which might be confusing for the 
users, who don't see INGO and IMP as two separate applications but 
rather see INGO as "the filter settings for IMP".



Thanks for the patch. :)



(Sorry for not responding earlier, I was on a /long/ vacation and only 
returned this week.)

Can you try if the commit in bug #7033 fixes saving the spam folder 
preference?

...OK, this is even more confusing: what happens with horde rc3 and 
rc4 /is/ identical, that is: the folder gets created OK; the script 
gets created ok (if spam filter is clicked to be active - if it isn't, 
then when I click it to be active, I get the correct script). But in 
the "Folder to receive spam" field there is still the text "Select 
target folder", not the name of the newly created folder. And if I try 
to select the newly created folder (that's really already selected), 
Ingo tries to recreate it (and fails). However, the "Script" page 
shows the correct script and spam folder. Then, if I log out and log 
in, the "Script" page shows a spam filter script which has as its spam 
target folder the folder that is set in IMP preferences, that is, the 
Spam folder setting... and the "Spam" page shows only the text "Select 
target folder". There appears to be something wrong with being able to 
set the spam folder both in IMP preferences and in spam.php... if I 
set the spam folder to be None in IMP preferences, then it turns to "" 
in the "current" script after re-login... The new spam folder creation 
javascript in IMP options appears to work better than the one in 
spam.php, but it doesn't activate spam filtering or anything... maybe 
it would be possible to take it away from IMP options and put similar 
logic into spam.php or something?

...moreover, the spam.php in -RC3 that did work with the patch and the 
spam.php in -RC4 that doesn't work appear to be identical... I'm 
confused.

I upgraded to -RC4, and now seem to be back in this situation (it no 
logner works correctly). I tried re-applying the patch that did work; 
it didn't fit. I also tried to un-apply the older patch in case that 
had somehow found its way to the -RC4 instead of the newer one, but 
that didn't work, either.

Thanks for your quick feedback!

This one appears to work. Thanks for replying so fast. :)

Okay, another try:

http://cvs.horde.org/diff.php?r1=1.15&r2=1.16&f=ingo%2Fspam.php



(I don't have this set up, sorry for the trial-and-error)

Now I can successfully create a new folder, but it doesn't end up as 
the spam folder (the script only creates the new folder). Moreover, if 
I try to select the newly created folder as the spam folder 
immediately after creating it this way, I get an error such as 
'WarningThe folder "maym" already exists' (and the spam folder isn't 
changed). Same if I try to select the folder again directly after 
getting the error. If I return to the rules list, go back to spam.php 
and then select my new folder as the spam folder, it works OK.

Can you try this patch, please?

http://cvs.horde.org/diff.php?r1=1.14&r2=1.15&f=ingo%2Fspam.php

Creating a new folder for spam does not work. If I select the option 
for creating a new folder in ingo/spam.php, I get the window asking 
for the name of the spam folder OK, the script gets activated - with 
an empty string as the argument to fileinto, and with no new folder 
created on the imap server. Tracing the error in ingo/spam.php, I 
found something weird in the if-elsif-construction in lines 81-122. 
Apparently, the new spam folder gets created and set as the spam 
folder only in case the test $form->validate($vars) in line 82 fails. 
But if the script is handling the form request created by the 
new_folder.js javascript, the test succeeds, and 
$spam->setSpamFolder($vars->get('folder')) (line 83) sets the spam 
folder to the value of 'folder' - i.e., an empty string.



Apparently, the validate() method should return false if all required 
variables aren't set. But it appears to be ok for the method that the 
variables are (implicitely) empty...