[Tickets #12342] Re: Caldav for -system- shares

[noreply at bugs.horde.org]

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

Ticket URL: http://bugs.horde.org/ticket/12342
------------------------------------------------------------------------------
  Ticket             | 12342
  Updated By         | Ralf Lang (B1 Systems GmbH) <lang at b1-systems.de>
  Summary            | Caldav for -system- shares
  Queue              | Kronolith
  Version            | Git master
  Type               | Enhancement
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


Ralf Lang (B1 Systems GmbH) <lang at b1-systems.de> (2013-07-11 13:29) wrote:

On 06.07.2013 07:05, Ralf Lang wrote:> On 05.07.2013 17:32, Jan  
Schneider wrote:
>>
>> Zitat von Ralf Lang <lang at b1-systems.de>:
>>
>>> If've been looking around for where to patch in -system- support for Dav
>>> shares. (kronolith, nag, turban).
>>>
>>> The Horde_Dav system expects -system- to be a user existing in
>>> Horde_Auth and having an Identity. I'm not sure if I should provide a
>>> static fake identity and always have a user -system- in the dav library
>>> or if I should promote -system- to a first class special user. I'm more
>>> leaning to the former (less invasive).
>>
>> Can you point to the code where this is required? Generally the former
>> sounds indeed like a better solution.
>
> I did a quick draft yesterday
>
> 1) Horde_Dav_Principals::getPrincipalsByPrefix
> - $users = array('-system-')
> + $users = array('-system-')
>
> 2) Horde_Dav_Principals::getPrincipalsByPath
> --        if ($this->_auth->hasCapability('list') &&
> --            !$this->_auth->exists($user)) {
> ++       if ($this->_auth->hasCapability('list') &&
> ++            !$this->_auth->exists($user) &&
> ++            $user != '-system-') {
>
>
> 3) Horde_Dav_Principals::_getUserInfo
> {
> ++  if ($user == '-system-') {
> ++      return array(
> ++          'uri' => 'principals/-system-',
> ++          '{DAV:}displayname' => '-systems-',
> ++          '{http://sabredav.org/ns}email-address' => ''
> ++	/* Can we leave email empty, set something static or
> ++           pull something from a fake identity? */
> ++  }
>     $identitiy = $this->_identities->create(user);
>
> This was enough for making system appear and list credentials under it
> (together with the kronolith patch from
> http://bugs.horde.org/ticket/12325 which was for WebDAV -- may need to
> amend callDavFoo too to make it actually crud events from calendars )

4) Horde_Dav_Principals

Give access to the calendars/-system- and principals/-system- level to  
all users. This probably needs more configuration.


     public function getGroupMembership($principal)
     {
         // All users should have access to the -system- share.
         // Needs reimplementation when horde finally implements group  
acls as share groups
         return array('principals/-system-');
     }

5) patch Kronolith_Application::davGetCollections to user '' in query  
but '-system-' in building structures.
We probably need this in nag to

     public function davGetCollections($user)
     {
++        $queryUser = $user == '-system-' ? '' : $user;

...

             ->listShares(
                 $GLOBALS['registry']->getAuth(),
                 array('perm' => Horde_Perms::SHOW,
--                        'attributes' => $user)
++                      'attributes' => $queryUser)
             );

6) Same show for nag

     public function davGetCollections($user)
     {
++    $queryUser = $user == '-system-' ? '' : $user;
         $shares = $GLOBALS['nag_shares']
             ->listShares(
                 $GLOBALS['registry']->getAuth(),
                 array('perm' => Horde_Perms::SHOW,
--                      'attributes' => $user)
++                    'attributes' => $queryUser)
             );


TODO: either implement filters for listSystemShares or add a  
systemShares filter option for listShares. listShares with  
permission::SHOW and empty user may return unrelated non-system 3rd  
party shares the user has SHOW access for.

Next: push a patch to master.