Tickets :: Comment on [#904] Ingo Screwed Up

* Your Email Address
* Spam protection	Enter the letters below: \ /.__..__ .__ ._. >< \| \|[__)[__) \| / \\|__\\| \| \_\|_
Comment	> 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.
Attachment
Watch this ticket

Saved Queries