[dev] Assigning permissions dynamically in Turba

[Michael Rubinsky]

In working on this for a bit, I basically replaced all the 
Turba::hasPermission() calls throughout Turba with a 
$object->hasPermission() or $driver->hasPermission() as appropriate.  This 
works well for most of the cases where we check permissions from within 
Turba.  However, in Turba::getAddressBooks(), $cfgSources is run through 
Turba::permissionsFilter before the results are returned....and 
Turba::permissionsFilter checks the permissions against Horde 
permissions...so, in order for this to work, Turba::permissionsFilter would 
instead have to instantiate a driver object for each source within 
$cfgSources and then call $driver->hasPermission() for that particular 
source.  I guess I'm just worried about that being too much 
overhead...thoughts?

Also, I've been playing with trying to incorporate backend acls into the 
horde permissions system, but I'm not sure that it is turning out to be a 
workable idea.  Here are some of my observations, rants etc... any feedback 
is appreciated:

First of all, only Horde admins have access to the current permissions UI. 
This means that the Horde administrator would also have to have admin 
privileges on the IMSP server in order for this to fully work. 
Additionally, users would not be able to give other users rights on 
addressbooks that they own, since they don't have access to the perms UI.

Second, even IMSP admins won't necessarily have permissions to all 
addressbooks on the server, so they would not be visible to them from 
within the permissions UI...they wouldn't be able to assign/revoke 
permissions on all addressbooks, and they would *never* be able to assign 
permissions to user's default addressbooks (which would only be visible 
when logged in as that user).

So, I'm thinking that instead of tying the acls to Horde perms, I would 
provide a UI (in the options screen) for individual users to allow editing 
of acls for those sources that they have rights to do so.  Looking forward, 
maybe create the hooks into Horde permissions and then use those to make 
sure that any perms that might be granted via Horde perm UI 'makes sense' 
etc...

Thanks for reading!

--On Monday, June 20, 2005 12:00 PM -0700 dev-request at lists.horde.org wrote:

> Message: 5
> Date: Mon, 20 Jun 2005 13:52:18 -0400
> From: Chuck Hagenbuch <chuck at horde.org>
> Subject: Re: [dev] Assigning permissions dynamically in Turba
> To: dev at lists.horde.org
> Message-ID: <20050620135218.b7namgx23tb4gkw4 at marina.horde.org>
> Content-Type: text/plain;        charset=ISO-8859-1; 
format="flowed"
>
> Quoting Michael Rubinsky <mike at theupstairsroom.com>:
>
> > I'm trying to map IMSP acls to horde permissions for IMSP addressbooks 
now
> > that the read-only attribute is gone.  I've got the initial code worked
> > out, but am having a problem determining exactly *where* to call it 
from.
>
> What about if we put the check into the driver, so you could call
> $object->hasPermission($perm), and that'd call the driver object in
> tern. Then the IMSP driver can override the default implementation.
>
> Something similar in the driver object for permissions on the actual
> sources...
>
> > In a related question, I'm having trouble figuring a way to map the
> > permissions back the other way, from horde permissions to imsp acls. 
Are
> > there any existing permission hooks that I could tie into to determine 
when
> > a permission has been changed from with horde..something along the 
lines of
> > the horde shares stuff?  If not, would anyone object to adding them?
>
> Yeah, we'd need hooks for that part - no objection from me to adding them.
>
> -chuck
>
>




Thanks -
Mike