Tickets :: [#1659] Kolab: visiting shared calender of a resource account breaks calendar view

6.0.0-beta1

8/14/25

Summary	Kolab: visiting shared calender of a resource account breaks calendar view
Queue	Kolab
Type	Bug
State	No Feedback
Priority	2. Medium
Owners
Requester	a.gungl (at) gmx (dot) de
Created	04/01/2005 (7440 days ago)
Due
Updated	05/06/2007 (6675 days ago)
Assigned	04/19/2007 (6692 days ago)
Resolved	05/06/2007 (6675 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch	No

05/06/2007 10:04:15 PM	Jan Schneider	Taken from Gunnar Wrobel State ⇒ No Feedback

04/19/2007 09:59:04 PM	Jan Schneider	Comment #8 State ⇒ Feedback Taken from stuart Assigned to Gunnar Wrobel	Reply to this comment
Is this still happening?

12/17/2005 05:32:37 PM	Chuck Hagenbuch	Comment #7 Version ⇒ Queue ⇒ Kolab	Reply to this comment
Move to Kolab queue.

07/11/2005 10:13:01 AM	Jan Schneider	State ⇒ Assigned

06/13/2005 06:10:13 AM	a (dot) gungl (at) gmx (dot) de	Comment #6	Reply to this comment
Sorry for the delay. Here is an example of such a broken message. Please note that <scheduling-id> equals to the subject: while <uid> has a completely unrelated value. If the message were conformant to the specs, then <uid> would have to have the same value as the subject: header. From: kleiner@osp-dd.de To: kleiner@osp-dd.de Subject: libkcal-1458384980.320 User-Agent: proko2/resmgr Reply-To: Date: Fri, 4 Mar 2005 15:43:17 +0100 X-Kolab-Type: application/x-vnd.kolab.event MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_1yc02fnwl43k" Content-Transfer-Encoding: 7bit X-UID: 12 X-Length: 1852 Status: R X-Status: NT X-KMail-EncryptionState: X-KMail-SignatureState: X-KMail-MDN-Sent: This message is in MIME format. --=_1yc02fnwl43k Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 7bit This is a Kolab Groupware object. To view this object you will need a client that understands the Kolab Groupware format. For a list of such clients please visit http:://www.kolab.org/kolab-clients.html --=_1yc02fnwl43k Content-Type: application/x-vnd.kolab.event; name="kolab.event" Content-Disposition: attachment; filename="kolab.event" Content-Transfer-Encoding: 7bit <?xml version="1.0"?> <event version="1.0"> <uid>kolab-f1a6f1682338cc50df93c790530662ff</uid> <scheduling-id>libkcal-1458384980.320</scheduling-id> <organizer> <display-name>Otto Mustermann</display-name> <smtp-address>mustermann@osp-dd.de</smtp-address> </organizer> <summary>Besprechung</summary> <location></location> <body><!--a75c305b1c0a6022--></body> <start-date>2005-03-03T11:30:00Z</start-date> <end-date>2005-03-03T13:00:00Z</end-date> <attendee> <display-name>Lisa Looser</display-name> <smtp-address>looser@osp-dd.de</smtp-address> <status>needs-action</status> <request-response>true</request-response> <role>req-participant</role> </attendee> <attendee> <display-name>Kleiner Besprechungsraum</display-name> <smtp-address>kleiner@osp-dd.de</smtp-address> <status>needs-action</status> <request-response>true</request-response> <role>req-participant</role> </attendee> </event> --=_1yc02fnwl43k--

06/10/2005 11:05:30 AM	stuart	Comment #5	Reply to this comment
Do you perhaps have any examples of these malformed messages? Otherwise, if I understand you correctly, the general format of these messages is that they do in fact have a <uid> field in the XML, however their subject line is set to something other than the Event's UID. Is this correct?

06/07/2005 08:44:45 PM	a (dot) gungl (at) gmx (dot) de	Comment #4	Reply to this comment
Well, it turned out that the resource manager is to blame. However, if you have a Kolab 2 server running for a while now, you'll end in trouble (given that you're activaly using resource accounts). IMO the solution is not (as originally expected) to correct the fact, that <sched-id> == <subject> != <uid> is set in those old messages. However, Horde _should_ recover from a <uid> without a corresponding <subject> i.e. IMAP message. Showing nothing (a blank page) in such a case brings nothing, I would like to see Horde skipping this particular event and trying to show the others. So yes, there is a fix needed in the sense of being gracefull in such a situation, even if currently only the resmgr is in the focus of the ones to be blamed.

06/07/2005 02:51:25 PM	Chuck Hagenbuch	State ⇒ Feedback

06/07/2005 11:47:31 AM	stuart	Comment #3	Reply to this comment
Andreas, what is the status of this issue? Is Horde still at fault here, or was it the resource manager that was causing the problems? If it is still a problem with Horde I can try to fix it now, but if it's a non-issue then we can close this ticket for the time being.

04/21/2005 07:25:04 AM	a (dot) gungl (at) gmx (dot) de	Comment #2	Reply to this comment
Stuart, there is currently a discussion on kolab-devel. It might be possible that Horde works as it should but that the Kolab resource manager incorrectly swaps <uid> and <scheduling-id>.

04/01/2005 08:15:16 AM	Jan Schneider	Assigned to stuart State ⇒ Assigned

04/01/2005 07:59:02 AM	a (dot) gungl (at) gmx (dot) de	Comment #1 Priority ⇒ 2. Medium Type ⇒ Bug Summary ⇒ Kolab: visiting shared calender of a resource account breaks calendar view Queue ⇒ Kronolith State ⇒ Unconfirmed	Reply to this comment
When you share the calendar of an automated resource account to a user, log in as that user and try to view that shared calendar, the Horde calendar view will fail as soon as some events are stored in that calendar. The problem is the Kolab resmgr rewriting the <uid> of the event's kolab.xml storing the original value in <scheduling-id>. Horde expects the <uid> to be the same like the Subject: of the IMAP message and fails in Kolab.php:299 rendering the Calendar view completely useless.