[dev] Horde_Share_Base::listShares()

[Gunnar Wrobel]

Zitat von Jan Schneider <jan at horde.org>:

> Zitat von Gunnar Wrobel <wrobel at horde.org>:
>
>> 1) Why do we have a separate Sql and Sql_Hierarchical driver?  
>> Wouldn't it make sense to collapse the two and always be  
>> hierarchical? I'd have no problems supporting a tree structure with  
>> the Kolab driver. In fact I'd like to do that.
>
> I'm all for it, if it makes sense for Michael.
>
>> 2) Can we move the handling of credentials into the backend? I  
>> admit I didn't go through the full Share code yet so I might not  
>> know all implications of this. But my impression so far was that  
>> the Sql driver operates in "Admin" mode. It has full access to the  
>> DB and can do things like listAllShares() - independant of the  
>> permissions. On the other hand listShares() needs a specific user  
>> ID. I'm unable to support this scheme with the Kolab backend.  
>> Simply because ACLs are *always* applied in the backend. The IMAP  
>> connection has been authenticated for a specific user and I'm not  
>> able to escape the boundaries of this user. I could of course list  
>> all shares on the server but I would have to authenticate as  
>> "manager" (or whatever the root/admin IMAP account is named) to the  
>> server. I don't mind the listAllShares() method so much but I would  
>> like to get rid of the $userid parameter in listShares().
>
> IIRC we are using the parameter actively in a few places, e.g. for  
> sending calendar agendas. I'd rather avoid instantiating a new Share  
> object each time.

Understandable. I will have to think about this again. I would  
definitely like to solve this problem for the Kolab server as this  
already led to a few problems with some of the scripts that rely on  
admin access in Horde3. They just didn't work with Kolab which not  
every user would know of course.

Maybe one could add some kind of "admin" switch that indicates to the  
backend that it should operate in admin mode. The Sql driver wouldn't  
be affected. But the scripts that rely on admin access would be  
required to allow for additional admin parameters that need to be  
passed to the backend initialization.

Will think about this further when I'm deeper in the share code.

Cheers,

Gunnar

>
> Jan.
>
> -- 
> Do you need professional PHP or Horde consulting?
> http://horde.org/consulting/
>
> -- 
> Horde developers mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org

-- 
Core Developer
The Horde Project

e: wrobel at horde.org
t: +49 700 6245 0000
w: http://www.horde.org

pgp: 9703 43BE
tweets: http://twitter.com/pardus_de
blog: http://log.pardus.de