Tickets :: Comment on [#11999] Prevent inserting empty share "objects" into $all

Search Results: 69 of 250 [ <<First <Prev Next> Last>> ] [ Return to Search Results ]

* Your Email Address
* Spam protection	Enter the letters below: . ..___..__.. ..__ \|_/ \| \| \|\|\ \|[__) \| \ \| \|__\\| \\|\|
Comment	>>>> 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... >
Attachment
Watch this ticket

Saved Queries