Should be fixed with this commit:

http://lists.horde.org/archives/cvs/Week-of-Mon-20080428/077896.html

Looking at this more closely, we should just specify the exact 
calendar - we only care if the event already exists in the calendar 
being uploaded. That will require another parameter to getByUID, but 
that's alright.

Sorry, but i think that the problem still in that conditions. 
Specifically, the first one is not compatible with the scenario 
described:



- if one matches, but the user doesn't have permission, skip it



in the scenario, only one matches (UID_A in Calendar_A created by 
User_A), but user_B doest't have permission on Calendar_A, but he 
wants to write in Calendar_B.



I think the solution would be check permission only if the calendar_id 
of one of the events found in database is the same that target one. 
For me, makes sense check permission only where we want to operate, i 
mean, the target calendar.



So i propose 2 steps:



Step 1: find an event stored in the calendar where i want to write 
(given by variable $calendar extrated before):



$existing_events = &$kronolith_driver->getByUID($uid,true);

foreach ($existing_events as $ee){

     if ($calendar==$ee->getCalendar()){

       $existing_event=$ee;

    }

}



Step 2: if any event selected, then check permission as done before



¿What do you think?

Seems to me like we should add true (the $getAll) parameter to the 
getByUID call, and then loop through all events with that UID and say 
that:



- if one matches, but the user doesn't have permission, skip it

- if one matches and the user does have permission, the event exists

- if none match or none that match are editable by this user, consider 
the event to not exist, instead of skipping it.



That sound right?

I have detected this problem with invitations and WebDAV publishing:



User_A creates an event with UID_A in calendar_A, and he invites to User_B.



User_B has Lightning pointing to Calendar_B throw WebDAV. After 
accept, Lightning try to publish event with UID_A in Calendar_B, but 
nothing happen. What is going on?



After have a look at code, in api.php: _kronolith_put, line 476 we have:



$existing_event = &$kronolith_driver->getByUID($uid);

if (!is_a($existing_event, 'PEAR_Error')) {

    // Entry exists.

    if (($existing_event->isPrivate() &&

       $existing_event->getCreatorId() != Auth::getAuth()) ||

       !$existing_event->hasPermission(PERMS_EDIT)) {

       continue;

    }



In the scenario described:

- Kronolith tries to find an event with UID_A, and it exists because 
was created by User_A in Calendar_A.

- $existing_event->hasPermission(PERMS_EDIT) fails because User_B 
doesn't have permission on Calendar_A, but User_B doesn't want to edit 
Calendar_A. User_B only wants to create an event with UID_A in 
Calendar_B.



I think that !$existing_event->hasPermission(PERMS_EDIT) should be 
removed, but i don't really know the real implications. That condition 
was added in version 1.212 of api.php, with others. I think a similar 
behaviour should occurs in _kronolith_import.