<?xml version="1.0" encoding="ISO-8859-1"?>
<?xml-stylesheet href="http://bugs.horde.org/themes/feed-rss.xsl" type="text/xsl"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
 <channel>
  <title>email alarm shows from-to instead of title</title>
  <pubDate>Tue, 08 Jul 2008 22:42:00 -0400</pubDate>
  <link>http://bugs.horde.org/ticket/6519</link>
  <atom:link rel="self" type="application/rss+xml" title="email alarm shows from-to instead of title" href="http://bugs.horde.org/ticket/6519/rss" />
  <description>email alarm shows from-to instead of title</description>

  
  
  <item>
   <title>When a user is reminded by email of an upcoming event, Horde</title>
   <description>When a user is reminded by email of an upcoming event, Horde/Kronolith always sends 
&quot;Event from %s to %s&quot;
instead of  the title of the event.
The reason for this is that the admin user the alarm script is run as does not heave the permissions to view a calendar (at least the one I use does not).
Horde does not check for admin permissions when listing the shares but only looks at the share permissions.

Note:
- This problem does not occur if your admin happens to have the right to at least read the calendar.
- This does not occur if the user you are trying this with is also the first entry in the horde admin array.
- For the admin alarms script to work correctly, I have used scripts-alarms.php from CVS


The problem starts in kronolith/lib/Driver.php:

In function getTitle, the permissions are checked. If the user does not have enough permissions, &quot;Event from %s to %s&quot; is returned.

    function getTitle($user = null)

        if ($this-&gt;isPrivate() &amp;&amp; $this-&gt;getCreatorId() != $user) {
            return sprintf(_(&quot;Private Event from %s to %s&quot;), $start, $end);
        } elseif ($this-&gt;hasPermission(PERMS_READ, $user)) {
            return strlen($this-&gt;title) ? $this-&gt;title : _(&quot;[Unnamed event]&quot;);
        } else {
            return sprintf(_(&quot;Event from %s to %s&quot;), $start, $end);
        }

hasPermission calls getShare(). Because a PEAR error is returned, the function returns false.

        return (!is_a($share = &amp;$this-&gt;getShare(), 'PEAR_Error') &amp;&amp;
                $share-&gt;hasPermission($user, $permission, $this-&gt;getCreatorId()));


getShare checks if the $GLOBALS['all_calendars'] array contains the current calender.
In the case of the alarm script, $this-&gt;getCalendar() returns the user's calendar (eg. &quot;myuser&quot;). But the global list of all calendars (the current user may access) does not contain this calendar. Eg. when the alarms.php script is run as admin &quot;root&quot; ((because that is the first entry in the horde admins array), all_calendars only contains &quot;root&quot;.
Therefore the function raises a PEAR error - which makes getShare() return false (above).

    function &amp;getShare()
    {        
        if (isset($GLOBALS['all_calendars'][$this-&gt;getCalendar()])) {
            $share = $GLOBALS['all_calendars'][$this-&gt;getCalendar()];
        } else {
            $share = PEAR::raiseError('Share not found');
        }
        return $share;
    }


Tracking this further down, I came to /lib/Horde/Share/datatree.php.
In function _listShares, the list of readable shares is generated.

function &amp;_listShares($userid, $perm = PERMS_SHOW, $attributes = null)
    $criteria = $this-&gt;_getShareCriteria($userid, $perm, $attributes);
    ...
    $sharelist = $this-&gt;_datatree-&gt;getByAttributes($criteria, DATATREE_ROOT, true, 'id');


$criteria holds the output of _getShareCriteria(), whose first parameter is the current user (eg. root). _getShareCriteria now builds a criteria list that makes sure only the readable shares are returned. It does not check for admin permissions.
$criteria is then passed to $this-&gt;_datatree-&gt;getByAttributes() which builds and runs the actual SQL queries. Eg.:


SELECT c.datatree_id, c.datatree_name FROM horde_datatree c LEFT JOIN horde_datatree_attributes a1 ON a1.datatree_id = c.datatree_id 
    WHERE c.group_uid = 'horde.shares.kronolith' AND (a1.attribute_name = 'owner' AND a1.attribute_value = 'root')   
    GROUP BY c.datatree_id, c.datatree_name, c.datatree_order 
    ORDER BY c.datatree_order, c.datatree_name, c.datatree_id;
    
SELECT c.datatree_id, c.datatree_name FROM horde_datatree c LEFT JOIN horde_datatree_attributes a1 ON a1.datatree_id = c.datatree_id 
    WHERE c.group_uid = 'horde.shares.kronolith' AND (a1.attribute_name = 'perm_users' AND a1.attribute_key = 'root' AND a1.attribute_value \\&amp; 2)   
    GROUP BY c.datatree_id, c.datatree_name, c.datatree_order 
    ORDER BY c.datatree_order, c.datatree_name, c.datatree_id;
    
SELECT c.datatree_id, c.datatree_name FROM horde_datatree c LEFT JOIN horde_datatree_attributes a1 ON a1.datatree_id = c.datatree_id 
    WHERE c.group_uid = 'horde.shares.kronolith' AND (a1.attribute_name = 'perm_creator' AND a1.attribute_value \\&amp; '2')   
    GROUP BY c.datatree_id, c.datatree_name, c.datatree_order 
    ORDER BY c.datatree_order, c.datatree_name, c.datatree_id;

SELECT c.datatree_id, c.datatree_name FROM horde_datatree c LEFT JOIN horde_datatree_attributes a1 ON a1.datatree_id = c.datatree_id 
    WHERE c.group_uid = 'horde.shares.kronolith' AND (a1.attribute_name = 'perm_default' AND a1.attribute_value \\&amp; '2')   
    GROUP BY c.datatree_id, c.datatree_name, c.datatree_order 
    ORDER BY c.datatree_order, c.datatree_name, c.datatree_id;




I am not sure how to handle this correctly. Should _getShareCriteria check if the user is admin (and AUTH_HANDLER is set to true)?

</description>
   <pubDate>Sat, 22 Mar 2008 13:05:28 -0400</pubDate>
   <link>http://bugs.horde.org/ticket/6519#t44144</link>
  </item>
  <item>
   <title>It's much easier, we simply allow admins full access to the </title>
   <description>It's much easier, we simply allow admins full access to the event title in getTitle() now.</description>
   <pubDate>Sat, 22 Mar 2008 14:47:45 -0400</pubDate>
   <link>http://bugs.horde.org/ticket/6519#t44148</link>
  </item>
  

 </channel>
</rss>
