[Tickets #11999] Re: Prevent inserting empty share "objects" into $all_shares array

noreply at bugs.horde.org noreply at bugs.horde.org
Fri Feb 8 09:34:55 UTC 2013


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

Ticket URL: http://bugs.horde.org/ticket/11999
------------------------------------------------------------------------------
  Ticket             | 11999
  Updated By         | Thomas Jarosch <thomas.jarosch at intra2net.com>
  Summary            | Prevent inserting empty share "objects" into
                     | $all_shares array
  Queue              | Horde Framework Packages
  Version            | Git master
  Type               | Bug
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              | 1
  Owners             |
------------------------------------------------------------------------------


Thomas Jarosch <thomas.jarosch at intra2net.com> (2013-02-08 09:34) wrote:

>>> I'm not so sure we should be silently ignoring any case where we
>>> can't load an explicitly requested share.
>>
>> Should we throw an error instead?
>
> Horde_Exception_NotFound should be thrown from the concrete share  
> class' _getShares() method.

I've checked the Kolab Share code and it does thrown an exception if  
one requests a share id that cannot be found.

While debugging this, I remember from my debug output that a rather  
long and a short share id was requested. Wild guess: The short id was  
just the username.

I think this might be a Kolab specific problem, call stack is roughly  
like this:

Base->getShares($ids) -> Kolab->_getShares($ids) -> Kolab->_getShareById($id).

The found share is stored with "$share->getName()" as the key.

Wild guess: For the Kolab case, "$share->getName()" might return  
something different than the request id. For example, you just  
requested the username as id and get an IMAP folder name back.

The Base->getShares() function assumes the returned array of share  
objects strictly uses the id as array key.

@Jan: Is it by design that "Kolab->_getShares($ids)" uses  
"$share->getName()" as key?
The SQL driver seems to work this way.

The "getName()" function in Share/Object/Kolab.php uses getId() as  
fallback if "share_name" is not available. So this some kind of  
fallback automagic...






More information about the bugs mailing list