Diff for CustomizingPreferences between 10 and 11

[[toc]]
+
+ User Contributed Preferences in Horde5

Perhaps the greatest feature of Horde and all of it's modules is the flexibility to adapt to a myriad of different uses and I would expect that eventually, a more integrated system of managing 'defaults' will become part of the code but at this moment in time, the only way to effect settings system wide is to edit the various prefs.php file inside each module.

In general: Add any local changes to a prefs.local.php or a prefs.d/<name>,php file. Never change prefs.php because this file is overwritten on upgrade and contains vital system information about the preferences that must match the other parts of the system. For instance,

{{kronolith/config/prefs.php}} contains:

// Address book(s) to use when expanding addresses ``
// Refer to turba/config/sources.php for possible source values
//
// You can provide default values this way:
//   'value' => json_encode(array('source_one', 'source_two'))
$_prefs['search_sources'] = array(
    'value' => ''
);
</code>

To change the default value add the following PHP code to either {{kronolith/config/prefs.local.php}} or {{kronolith/config/prefs.d/**name**.php}} {{name}} can be any name you like, I prefer the local hostname:
<code type="php">
<?PHP
$_prefs['search_sources']['value'] = '["favourites"]';

++ Hooks

You can provide default values by hooks, which are little PHP functions.

Since Horde4See CustomizingPreferencesH3 for more ideas for preference hooks. Those use the old, no longer supported format from Horde 3, but still may provide some starting points for further customizations. If you port one of those Hooks to a recent Horde version, please add them here.

Since Horde 4 hooks are organized in classes, e.g. {{config/hooks.php}} uses {{class Horde_Hooks}}, whereas  {{kronolith/config/hooks.php}} uses {{class Kronolith_Hooks}}. See {{config/hooks.php}} for a description of hooks.

For instance to automatically prepare Kronolith's {{search_sources}} with all address books the user has access to:

Enable the hook in the local prefs.php {{kronolith/config/prefs.local.php}}:
<?PHP
$_prefs['search_sources']['hook'] = true;
</code>

And add to  {{kronolith/config/hooks.php}}:
<code type="php">
<?PHP
class Kronolith_Hooks
{
    public function prefs_init($pref, $value, $username, $scope_ob)
    {
            ifif (is_null($username)) {	// not logged in
                return
            return $value;
            }
        }

        switch ($pref) {
         casecase 'search_sources':	// enable all sources by default
        	if($value
            if ($value == '') {
			$sources
                $sources = $GLOBALS['registry']->call('contacts/sources');
			$value
                $value = json_encode(array_keys($sources));
			$scope_ob->set($pref,
                $scope_ob->set($pref, $value);
			$scope_ob->setDirty($pref,
                $scope_ob->setDirty($pref, true);
        	}
		return
            }
            return $value;
 	}
        }
    }
}
</code>

Because the prefs_init hook is called each time an user logins, line 12 shall prevent that the value is set to default each time, probably overwriting the user's choice. The empty string is the default value of the {{search_sources}}.

Line 13 collects all address books from Turba, the user has access to. Line 14 prepares the string for the preference. These lines are very preference-specific.

Line 15 and 16 permanently write the settings into the preference storage of the user. The next time the user logins, {{$value}} is no longer empty, hence, the {{if()}} block is skipped and any newly available address books are **not** automatically enabled. If you want to keep the preference changing until the user changes the setting manually, remove these two lines.

++ Cache user information between prefs_init() calls

Because preference values are requested one after another, the function prefs_init() is called for each preference you have set {{hook = true}}. If you query large latency databases, it can make sense to query all user data at once and cache the result for the next call of prefs_init. You can use a Horde case for example like so:
<code type="php">
function my_userinfo($uid) {
	global $injector;
	$cache = $injector->getInstance('Horde_Cache');
	$key = 'my_userinfo.u.'.$uid;
	if($cache->exists($key)) {	// saved??
		return unserialize($cache->get($key));
	}

	$userinfo = false;

	// prepare the userinfo array here

	if(isset($userinfo)) {
		$cache->set($key, $userinfo, 20 * 60);
		return unserialize($userinfo);
	}
	return false;
}
</code>

Save this function in a PHP file and use it in all prefs_init() functions you need the user information, e.g. before the {{switch($prefs)}} statement:
<code type="php">
    require_once(HORDE_BASE . '/lib/my_lib.php');
    $info = my_userinfo($username);
    if(!isset($info) || $info === false || $info == '') {
    	return $value; // error getting user information
    }
</code>


++ Suppressing "whitelist" and "blacklist" menu items

As an administrator you may want to manage all SPAM controls at the server and if so, you'll want to remove these menu items so as not to confuse/frustrate your users.

File to edit: ../ingo/config/prefs.local.php


<code type="php">

$_prefs['whitelist']['locked'] = true; 
$_prefs['spam']['locked'] = true; 

</code>


File to edit: ../config/registry.local.php

<code type="php">
$this->applications['ingo']['provides'] = array_diff(
     $this->applications['ingo']['provides'],
     array(
         'mail/blacklistFrom',
         'mail/showBlacklist',
         'mail/whitelistFrom',
         'mail/showWhitelist'
     )
);
</code>