You're right.  Sorry for wasting your time.  I don't have the time to 
track all CVS commits and only read so far in the code to see what the 
Kronolith import API returns, based on it's description :/  But one 
more thing to cross off my fix-before-deploying Horde list.. :)

calendar/import, implemented in _kronolith_import, calls 
$event->fromiCalendar(). The first lines in that function are:



         // Unique ID.

         $uid = $vEvent->getAttribute('UID');

         if (!empty($uid) && !is_a($uid, 'PEAR_Error')) {

             $this->setUID($uid);

         }



This was merged to Driver.php in revision:

http://cvs.horde.org/co.php/kronolith/lib/Driver.php?r=1.116.2.5



... which was after the Kronolith 2.0.2 tag (1.116.2.3):

http://cvs.horde.org/kronolith/lib/Driver.php



So wait for 2.0.3 final or try the RC. This ticket is still resolved.

Please bring discussions/questions onto the Kronolith or dev mailing 
lists. This ticket is for a single issue.

Apple's iCal does not retain the Kronolith UID after an import/export 
sequence.  I just read the spec for the UID value and it's ambiguous 
about whether or not it must be maintained as is, but it does state 
that:



Implementations MUST be able to receive and persist values of at least 
255 characters for this property.



Persist has the connotation that it is going to continue to be used as 
the same value as it was when it entered the system.  So Apple's iCal 
either doesn't meet spec, if thats a proper interpretation, or I'm 
just wishfully thinking for an easy offline solution :/



Of course, when I import a 6AM - 7AM test invitation event into 
Apple's iCal, it throws up a notice that the event starts at 10AM, but 
when I accept it and it actually displays the time, its 6-7AM.  So it 
must not know about GMT during  import :)

Also, one other area for you to think about.  Similar situation but 
different application.  We're going to have to come up with an offline 
solution so some of our itinerant staff can view their calendars when 
they're on the road.  One option is using a Palm (but syncing them is 
conceptual only, at this point, since we must have serial devices 
currently).  The other option is to use Apple's iCal and export your 
Kronolith calendar and import it into iCal.  But, because UIDs are not 
preserved when the information is exported from iCal and imported back 
into Kronolith (because the import method always returns a new UID), 
you end up with duplicate events.  I don't know the iCal spec in any 
great detail - _should_ events generated in one system maintain their 
UID in another system?  Should an export from Kronolith that's 
imported into Apple's iCal, that's exported from iCal and imported 
into Kronolith have the same UID the whole way through?  And if it 
should, and we can make the import function become aware of existing 
events by matching UIDs, then I think we can have ourselves a poor 
man's sync, and a palatable offline solution.

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..

This bug, as described, does not occur with the current code. Events 
are stored iwth the same UID, and different ids, and can be updated 
through itip attachments just fine. There are some tweaks to look at 
with deleting events and reminders, but the UIDs in the emails work 
just fine.

The problem as I reported it still exists in the latest set of 
released Horde modules (Horde 3.0.3 and Kronolith 2.0.2).



I create an event, send an invitation to an attendee.  They accept, 
add it to their calendar and I can update their status.  If I delete 
the event and elect to send them a notification, the notification 
contains the UID of my event.  When they attempt to delete the event 
from their calendar, the UID is not found because when the event was 
first created on their calendar, it was assigned a new UID, not the 
one that is on my event.  As far as I can tell, only event_id needs to 
be unique.  event_uid can (and should be) shared for meetings with 
multiple attendees.



Or perhaps this is intentional?

Resolving; don't reopen unless this is really different from bug 1153.

I think that the fix for bug 1153 fixes this; your analysis is going 
at it the other way, but if UID was empty in the initial email, that'd 
result in a new UID being generated when the user added it to their 
calendar. UIDs *should* be unique per event, and the same across 
calendars.



Please test CVS or 2.0.2 when it comes out and let us know.

Duplicate of bug 1053, but this one has the better analysis.

If you create an event and add some attendees, an email gets sent to 
those attendees.  The attendee can accept the event and add it to 
their calendar.  If, at a later date, you, as the event coordinator, 
cancel the event, you can choose to notify attendees thats its been 
canceled.  The email that gets generated to send to the receipients 
contains the UID of the event.  However, if the attendee attempts to 
delete the event from their calendar, it fails with a message about 
the UID being invalid.  I believe what is happening is that the UID 
being sent in the iTip attachment  is  the UID from the event 
organizer's calendar, but this is a different UID on the attendee's 
calendar.  So when they go to delete an event, its obviously not 
there.  I'm not sure how to fix this, other than when the event is 
added to the attendee's calendar, it uses the same UID as the meeting 
organizer.  Or, when the meeting cancellation occurs, Kronolith has to 
do a lookup on all attendees calendars to figure out what the UID is 
on their calendar but thats close to impossible, as they could change 
the event name, or their calendar may not even be shared.