[imp] forcing certain settings to look in database

[Jan Schneider]

Quoting rick at havokmon.com:

> Quoting eculp at encontacto.net:
>
> > Quoting Vince LaMonica <vjl at uci.edu>:
> >
> >
> > | [egad; replying to myself twice in one day..baaaad karma]
> > |
> > | The FAQ above doesn't explain how to use multiple settings with
> virtual
> > | domains [other than changing return addresses]. I want to be able to
> lock
> > | down certain features with certain domains [including not enabling
> the
> > | calendar and/or passwd changing for certain domains]. The only way
> I've
> > | been able to do that so far is multiple installations.
> > |
> >
> > Vince, I think that may be an overkill ;-).  There are a couple of bad
> > solutions that I've used.  I think it depends on how many settings and
> > for how many domains and how often they will change.  I really don't
> > change that many.  I have created a configuration file that I include
> > with variables assigned.  It is far from an optimal solution and could
> > be more maintenance intensive than it should, but it works.
> >
> > Sniplets from my files:
> >
> > /* This is an additional file in horde/config/ to set the variables */
> >
> > $vdomain = strtolower(eregi_replace('^mail\.|^www\.|^www\.mail\.', '',
> \
> > $_SERVER['HTTP_HOST']));
> >
> > switch ( $vdomain ) {
> >         case "insourcery.net" :
> >                 $default_theme='royal';
> >                 $default_lock=true;
> >                 break;
> >
> > Then in prefs.php for theme I have:
> >
> > // color theme
> > $_prefs['theme'] = array(
> >     'value' => $default_theme,
> >     'locked' => $default_lock,
> >     'shared' => true,
> >
> > I actually have about 15 definitions per domain.  I'm not sure that I
> would
> > want any more.  I'm sure there is a much better way of doing this.  I
> guess
> > that since this works, I've been too lazy to find a better mousetrap.
> >
> >
> I'm working on the same thing, to a greater extent.  I need to apply
> 'permissions' based on a users service level.  I use vpopmail with a
> MySQL
> backend.  By default, all users have a '0' service level.
>
> So what I'm attempting to do, is set a preference 'service_level' when
> the user
> Auth's, pulled from the vpopmail MySQL table.
>
> At that point, I can put a basic 'if (service_level >=)' around items in
> the
> horde/config/registry.php (to enable/disable turba/gollem/etc) for users.
> Since it's a Horde pref (or so the plan is), I can refer to it from other
> pref.php files (such as horde/imp/config/prefs.php) to allow for rights
> within
> each application (such as Fetchmail within IMP).
>
> Once I get it working, I'll post a diff what I did.  (I'm working with
> the
> current CVS). At this point, I've manually created/set the horde pref
> within
> the horde/config/prefs.php file to test it out. That works for the 'fine
> grain'
> control within each app (Fetchmail within IMP).  Now I need to figure out
> how
> to set it BEFORE the horde/config/registry.php file is called so I can
> use it
> to completely enable/disable those apps.

You should watch the dev@ list where we are currently discussing how to use
the Perms API for application access levels.
Someone already stepped up to implement this.

Jan.

--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft