[Tickets #1107] RESOLVED: Meeting attendees get email with bogus UID for cancelled or changed event

[bugs at bugs.horde.org]

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

Ticket URL: http://bugs.horde.org/ticket/?id=1107
-----------------------------------------------------------------------
 Ticket             | 1107
 Updated By         | kevin_myer at iu13.org
 Summary            | Meeting attendees get email with bogus UID for cancelled or changed event
 Queue              | Kronolith
 Version            | 2.0
 State              | Resolved
 Priority           | 1. Low
 Type               | Bug
 Owners             | Horde Developers
-----------------------------------------------------------------------


kevin_myer at iu13.org (2005-04-09 18:11) wrote:

I don't have a live HEAD install that I can test, but if, by current code,
you mean 2.0.2 as well, the problem is still there.  There never was a
problem with the iTip attachment - it contains the correct UID.  But, when
the attendee chooses to add the event to _their_ calendar, a brand new ID
(correctly) and a brand new UID (incorrectly) is generated.  As a result,
when future iTip attachments come in for the same event, the event can't be
found because it has a new UID on the attendee's calendar.

After looking at the path back through the code, I think its actually a bug
of the IMP iTip MIME Viewer class, on or about line 124 (same logic is
included in the Horde  icalendar MIME Viewer class, on or about line 73), so
this is really misfiled by me.

$guid = $registry->call('calendar/import', array($components[$key]));

That call will always generate a new UID - the API for kronolith_import even
states that's what it will return (I'm learning to read code :)  There's no
logic that I can see that ever checks to see what the UID is in the iTip
attachment - the calendar/import call will always return a new one, even if
one already exists..