user resolved

Michael,

That was it! The pref.php value of these things was set to blank. May 
it would be a good idea to add a warning comment in the prefs.php for 
ingo saying "If any prefs are not set to proper arrays, Ingo will 
break - BE CAREFUL." Most horde prefs.php values are just defaults, 
and if they are not set correct, the user can still overwrite them 
with valid ones (not the case with Ingo).



Thanks again,

Lee

From Lee:

I don't not have Sam enabled (it is commented out in registry.php, the 
ingo block is

enabled for whitelist/blacklist).



When the whitelist is updated, eventually you get to line 336 of sieve.php:

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

this followed by:

foreach ($filters->getFilterlist() as $filter) {

...

Am i correct in assuming that if this loop is never run after a 
whitelist or blacklist

rule is updated, the rule will be added to sieve? This is exactly 
what's happening. I put

a print statement into the foreach loop, and its never called. A 
var_dump of $filters

before the loop gives:



object(ingo_storage_filters)(2) { ["_filters"]=>  bool(false) 
["_obtype"]=>  int(0) }



Basically when the user updated their whitelist or blacklist in ingo, 
the prefs are

updated with with the rule, but sieve is never updated. This is 
reflected in the fact

that clicking the whitelist icon after updating shows the white rule, 
but the rule is not

listed in the "Rules" tab, or in the script view (its also not present 
in the script on

the server, when checked directly on the sieve server).



Im concerned that this might be a serious bug in ingo and cyrus/sieve. 
When i originally

installed RC1 everything was working. At some point when using RC2, 
this problem emerged.

I tried RC1 again, and it too now has this problem. What makes me 
concerned is that i

recently upgrade cyrus to the latest version and Im wondering if this 
could be causing

the problem. The only other thing that could be causing the problem is 
a config option i

changed. But as i noted above, Ingo is enabled and Sam is disabled in 
the registry.

BTW - your diagnosis of the problem on 11/30 is incorrect. A call to 
$ingo_storage->retrieve(INGO_STORAGE_ACTION_FILTERS) won't return the 
details of the blacklist/whitelist (since, as you have correctly 
noted, those details exist in separate preferences) but it will return 
the blacklist and whitelist placeholder entries - these are needed to 
indicate where the black/whitelist entry exists in the filter list, 
whether it is disabled or not, etc.



So if the blacklist/whitelist placeholder entry is not showing up in 
the return from the retrieve() call it is either because the backend 
doesn't support it (but sieve does so that's not the problem) or it is 
because some other app is handling the blacklist/whitelist API calls.   
See ingo/lib/Script.php:167-176

In horde/config/registry.php, have you configured sam to handle the 
mail/blacklistFrom and mail/whitelistFrom API calls?  If so, then you 
wont see any blacklist or whitelist links in ingo.

Sorry remainder of my post got cut off:



the problem appears to be in both RC-1 and RC-2.

I spent a few hours further debugging this. Here is what i have.



When i add rules, everything is fine. The rules get added to mysql, 
the sieve script gets updated on our imap server, and the rules appear 
in the script list.



HOWEVER, when i add whitelist and blacklist rules, neither get added 
to sieve and neither are displayed in the filters list. HOWEVER they 
are added to prefs in mysql.



Ive traced the problem down to:



sieve.php line 366: Prior to this line, the function generate() has 
appropriately set $whitelistBlocks, $blacklistBlocks etc... with teh 
information the user generated. However at line 366, a foreach loop is 
initiated from the result of:



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

foreach ($filters->getFilterlist() as $filter) {

...



In this loop whitelistBlocks, blocklistBlocks etc... are converted to 
code and added to sieve. Since the loop is never run, the 
whitelists,blacklists etc... arent added to sieve. The problem is that 
retrieve(INGO_STORAGE_ACTION_FILTERS) doesnt return any whitelist or 
blacklist items or vacation items (it only returns the filters).



If you want you can test out what im saying shoot me a private email 
and i will provide you with a login to our system.



FYI it appears this problem is also happening in RC-1, however I am 
positive when i originally installed RC-1

I do. And it works fine here too.

Ill do some debugging and see if i can track down the affending code. 
Are you testing with a sieve backend?

I can't reproduce this at all.  Everything is fine here.  The only 
thing that changed between RCs was the menu generation, so I have no 
idea why you would be seeing this.

In RC1 i setup a default script in the ingo conf.php. When I upgraded 
to RC2, the "Filters Rule" tab was blank despite the fact i both had 
an active script (i created in RC1) for the logged in user, and had 
the same script set as a default value. Perhaps the format of sieve 
scripts changed? Even if thats the case, Ingo RC-2 no longer lists 
Whitelist and Blacklist in the "Filter Rules" section, thereby 
preventing users from arranging them with the general filter rules. I 
also noticed that the whitelist and black list do not show up in teh 
"Script" tab either. However both do seem to display the values one 
sets when actually in the whitelist/blacklist tabs themselves.