[Tickets #7033] Ingo does not store spam preferences

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/7033
------------------------------------------------------------------------------
  Ticket             | 7033
  Created By         | develop at kristov.de
  Summary            | Ingo does not store spam preferences
  Queue              | Ingo
  Version            | 1.2
  Type               | Bug
  State              | Unconfirmed
  Priority           | 2. Medium
  Milestone          |
  Patch              | 1
  Owners             |
+New Attachment     | horde-ingo-1.2.ebuild
------------------------------------------------------------------------------


develop at kristov.de (2008-07-06 15:39) wrote:

When running Imp and Ingo, Ingo does not store the spam preferences  
correctly. The problem is in the following code (lib/Storage/prefs.php):

case INGO_STORAGE_ACTION_SPAM:
              $ob = new Ingo_Storage_spam();
              $data = @unserialize($prefs->getValue('spam'));

Here, $prefs has previously been loaded to point to Ingo's  
preferences. However, within the constructor of Ingo_Storage_spam, the  
preference object is invalidated by changing the preference object's  
scope, as Imp's preferences are loaded:

         if (in_array('imp', $GLOBALS['registry']->listApps())) {
             $prefs = &Prefs::singleton($GLOBALS['conf']['prefs']['driver'],
                                        'imp', Ingo::getUser(), '',  
null, false);
             $prefs->retrieve();
             [...]

To solve this, I changed Ingo's code to read

          case INGO_STORAGE_ACTION_SPAM:
              $ob = new Ingo_Storage_spam();
              $prefs->retrieve($GLOBALS['registry']->getApp());
              $data = @unserialize($prefs->getValue('spam'));

So the preferences are reloaded after the construction call.  
Alternatively, only resetting the scope should also be sufficient.  
This solves the problem, but I admit it may not be the most preferable  
solution. I think that Prefs::singleton() should allow to cache  
preference objects with different scopes separately, which is  
currently disallowed (horde/lib/Horde/Prefs.php):

         if (!isset($instances[$signature])) {
             $instances[$signature] = &Prefs::factory($driver, $scope,  
$user, $password, $params, $caching);
         }

         /* Preferences may be cached with a different scope. */
         $instances[$signature]->setScope($scope);

If you want, I'll submit that as a separate Horde framework bug.