Can you please try if the attached patch fixes this for you?

We're still getting occasional reports of this issue affecting users 
here at Reed, even with the patch.

Do you guys still see this, and if yes, can you determine any common 
denominator that might cause this?

I can't reproduce this, with any storage driver.

Dominik's patch appears to work in our environment, and after being 
appropriately modified for 'rule.php', 'whitelist.php', etc., appears 
to be a more general solution, as well. The "right way" to solve to 
problem, going forward, would probably be to have 'lib/base.php' 
pre-fetch the various filter types...perhaps even exposing them via 
named methods like '$ingo_storage->vacation()' to save us all a few 
keystrokes typing those long INGO_STORAGE_ACTION_* constants? (hint, 
hint...)

I just found a way to fix this problem on the vacation.php page (a fix 
for the other pages should be similar). In fact, the problem seems to 
be that not all filter objects are loaded when the first save happens. 
In my case, I noticed that when the first save in vacation.php failed, 
the whitelist filter got loaded and then, when trying to save the 
second time (this one successful), the whitelist filter did not get 
loaded again.



So to fix the problem in vacation.php, I added all filter objects to 
the beginning of the page, which became



/* Get vacation object and rules. */

$vacation = &$ingo_storage->retrieve(INGO_STORAGE_ACTION_VACATION);

$filters = &$ingo_storage->retrieve(INGO_STORAGE_ACTION_FILTERS);



#added to fix http://bugs.horde.org/ticket/comment.php?id=4370

$whitelist = &$ingo_storage->retrieve(INGO_STORAGE_ACTION_WHITELIST);

$forward = &$ingo_storage->retrieve(INGO_STORAGE_ACTION_FORWARD);

$blacklist = &$ingo_storage->retrieve(INGO_STORAGE_ACTION_BLACKLIST);

$spam = &$ingo_storage->retrieve(INGO_STORAGE_ACTION_SPAM);

#end fix



$vac_id = $filters->findRuleId(INGO_STORAGE_ACTION_VACATION);

$vac_rule = $filters->getRule($vac_id);

Some debug info. I log in, select Mail, then Filters. I want to turn 
on default Spam Filter. It has a red cross under disabled column. I 
click on it, and from horde.log:

-----

Sep 18 20:32:10 HORDE [debug] [] SQL Query by 
DataTree_sql::_buildParentIds(): SELECT datatree_id, datatree_p

arents FROM horde_datatree WHERE datatree_name = ? AND group_uid = ? 
ORDER BY datatree_id [on line 275 of "/v

ar/www/pear/lib/Horde/DataTree/sql.php"]

Sep 18 20:32:10 HORDE [debug] [] SQL Query by DataTree_sql::_load(): 
SELECT c.datatree_id, c.datatree_name, c

.datatree_parents, c.datatree_order FROM horde_datatree c WHERE 
c.group_uid = 'horde.perms'  [on line 144 of

"/var/www/pear/lib/Horde/DataTree/sql.php"]

Sep 18 20:32:11 HORDE [debug] [ingo] SQL Query by 
Prefs_sql::retrieve(): SELECT pref_scope, pref_name, pref_v

alue FROM horde_prefs WHERE pref_uid = ? AND (pref_scope = ? OR 
pref_scope = 'horde') ORDER BY pref_scope [on

  line 159 of "/var/www/pear/lib/Horde/Prefs/sql.php"]

Sep 18 20:32:11 HORDE [debug] [ingo] SQL Query by 
Prefs_sql::retrieve(): SELECT pref_scope, pref_name, pref_v

alue FROM horde_prefs WHERE pref_uid = ? AND (pref_scope = ? OR 
pref_scope = 'horde') ORDER BY pref_scope [on

  line 159 of "/var/www/pear/lib/Horde/Prefs/sql.php"]

Sep 18 20:32:11 HORDE [debug] [ingo] SQL Query by 
Prefs_sql::retrieve(): SELECT pref_scope, pref_name, pref_v

alue FROM horde_prefs WHERE pref_uid = ? AND (pref_scope = ? OR 
pref_scope = 'horde') ORDER BY pref_scope [on

  line 159 of "/var/www/pear/lib/Horde/Prefs/sql.php"]

Sep 18 20:32:11 HORDE [debug] [ingo] SQL Query by 
Prefs_sql::retrieve(): SELECT pref_scope, pref_name, pref_v

alue FROM horde_prefs WHERE pref_uid = ? AND (pref_scope = ? OR 
pref_scope = 'horde') ORDER BY pref_scope [on

  line 159 of "/var/www/pear/lib/Horde/Prefs/sql.php"]

Sep 18 20:32:11 HORDE [debug] [ingo] SQL Query by 
Prefs_sql::retrieve(): SELECT pref_scope, pref_name, pref_v

alue FROM horde_prefs WHERE pref_uid = ? AND (pref_scope = ? OR 
pref_scope = 'horde') ORDER BY pref_scope [on

  line 159 of "/var/www/pear/lib/Horde/Prefs/sql.php"]

Sep 18 20:32:11 HORDE [debug] [ingo] SQL Query by 
DataTree_sql::_buildParentIds(): SELECT datatree_id, datatr

ee_parents FROM horde_datatree WHERE datatree_name = ? AND group_uid = 
? ORDER BY datatree_id [on line 275 of

  "/var/www/pear/lib/Horde/DataTree/sql.php"]

Sep 18 20:32:11 HORDE [debug] [ingo] SQL Query by 
DataTree_sql::_load(): SELECT c.datatree_id, c.datatree_nam

e, c.datatree_parents, c.datatree_order FROM horde_datatree c WHERE 
c.group_uid = 'horde.perms'  [on line 144

  of "/var/www/pear/lib/Horde/DataTree/sql.php"]

Sep 18 20:32:11 HORDE [debug] [ingo] SQL Query by 
DataTree_sql::_buildParentIds(): SELECT datatree_id, datatr

ee_parents FROM horde_datatree WHERE datatree_name = ? AND group_uid = 
? ORDER BY datatree_id [on line 275 of

  "/var/www/pear/lib/Horde/DataTree/sql.php"]

Sep 18 20:32:11 HORDE [debug] [ingo] SQL Query by 
DataTree_sql::_load(): SELECT c.datatree_id, c.datatree_nam

e, c.datatree_parents, c.datatree_order FROM horde_datatree c WHERE 
c.group_uid = 'horde.perms'  [on line 144

  of "/var/www/pear/lib/Horde/DataTree/sql.php"]

-----



The red cross turns into green checkmark. On top it says:

"Rule Enabled"

"Script successfully activated"



On backend, indeed there is an entry in ingo.script.

I log out, log back in, go to Mail -> Filters, and instead of seeing a 
green checkmark for Spam Filter, there is a red cross. Still, it is 
enabled on backend imap server.



CVS HEAD, SQL DB for preferances, Horde defaults.

In Ingo, for storage driver selected is "preferences system".

What I see is similar to ticket #3825. This only happens the first 
time, and it happens with creating a new rule, moving rules up/down, 
and enabling or disabling a rule. For example, after I log in and go 
to create a new rule, and hit save, it doesn't really save it to the 
database. It does show up on the filter rule screen. If I then "edit" 
the rule, and hit save again, it does get saved to the database. It is 
similar with other things, like moving rules up or down, the first 
time after a login it doesn't work, but after doing it once or twice, 
the database gets updated. Same with enabling or disabling a rule, 
using sieve as well, the sieve server gets updated every time, but the 
first time the sql doesn't seem to do an update. Using 'prefs' for 
storage driver, and cvs head.