Tickets :: [#5210] Kolab shares can break share panel

6.0.0-beta1

8/1/25

Summary	Kolab shares can break share panel
Queue	Kolab
Type	Bug
State	Not A Bug
Priority	1. Low
Owners	wrobel (at) horde (dot) org
Requester	michael.sheldon (at) credativ (dot) de
Created	04/04/2007 (6694 days ago)
Due
Updated	04/24/2007 (6674 days ago)
Assigned	04/23/2007 (6675 days ago)
Resolved	04/24/2007 (6674 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch	No

04/24/2007 11:17:03 AM	Gunnar Wrobel	State ⇒ Not A Bug

04/24/2007 11:16:42 AM	Gunnar Wrobel	Comment #6	Reply to this comment
Hm, ok. While this is not the Kolab default it is something that can be changed in a template. So this probably should get a configuration option within Horde. I was too quick on this. When I started looking at this today I realized that the template is actually not the only place where you need to change the prefix. Instead you actually need to modify the perl-kolab code since the prefix is hard coded in there. So this is nothing that can be configured and you'll also have to patch horde in this case.

04/23/2007 02:56:33 PM	Jan Schneider	State ⇒ Assigned

04/23/2007 02:18:49 PM	Gunnar Wrobel	Comment #5 State ⇒	Reply to this comment
Hm, ok. While this is not the Kolab default it is something that can be changed in a template. So this probably should get a configuration option within Horde.

04/23/2007 02:18:47 PM	Chuck Hagenbuch	State ⇒ Assigned Assigned to Gunnar Wrobel

04/23/2007 01:11:50 PM	michael (dot) sheldon (at) credativ (dot) de	Comment #4	Reply to this comment
The Kolab share driver should actually do that and return 'anonymous' at the moment. The error is only be raised in case the driver receives an IMAP folder name that it cannot handle, which should not happen. There is a getOwner() function in the Kolab share driver that tries to match the folder name with a regular expression. What is the name of the problematic folder? Ah, I see, you check against the share being of the form "share.something". Some of our customers prefer to have their shares in the form "CustormerName/something", which is why we experienced this problem.

04/10/2007 07:20:55 AM	wrobel (at) pardus (dot) de	Comment #3	Reply to this comment
The Kolab share driver should actually do that and return 'anonymous' at the moment. The error is only be raised in case the driver receives an IMAP folder name that it cannot handle, which should not happen. There is a getOwner() function in the Kolab share driver that tries to match the folder name with a regular expression. What is the name of the problematic folder?

04/08/2007 05:54:57 AM	Chuck Hagenbuch	Comment #2 State ⇒ Feedback	Reply to this comment
Seems to me like it'd be better for the Kolab driver to return "System" or some such for those cases. Returning a PEAR_Error for attributes is behavior not present in other usage of share or datatree objects.

04/04/2007 11:47:53 AM	michael (dot) sheldon (at) credativ (dot) de	Comment #1 Priority ⇒ 1. Low Type ⇒ Bug Summary ⇒ Kolab shares can break share panel Queue ⇒ Kolab New Attachment: panel-shares-with-no-owner.patch State ⇒ Unconfirmed	Reply to this comment
It's possible to have Kolab shares which have no owner (e.g. shares created by the kolab-webadmin). This breaks the panel in nag, kronolith and mnemo, since they then try to display the PEAR_Error object returned from trying to get an owner which doesn't exist. The warning produced (if display warnings is enabled) breaks the panel. The attached patch doesn't attempt to display the owner if a PEAR_Error has been returned for it.