| Summary | Problem with invitations and WebDAV |
| Queue | Kronolith |
| Queue Version | HEAD |
| Type | Bug |
| State | Resolved |
| Priority | 2. Medium |
| Owners | Chuck Hagenbuch <chuck (at) horde (dot) org> |
| Requester | almarin (at) um (dot) es |
| Created | 04/17/2008 (24 days ago) |
| Due | |
| Updated | 04/30/2008 (11 days ago) |
| Assigned | 04/29/2008 (12 days ago) |
| Resolved | 04/30/2008 (11 days ago) |
| Attachments | |
| Milestone | 2.2 |
| Patch |
State ⇒ Resolved
Taken from
Should be fixed with this commit:http://lists.horde.org/archives/cvs/Week-of-Mon-20080428/077896.html
Milestone ⇒ 2.2
State ⇒ Assigned
Assigned to
Assigned to Chuck Hagenbuch
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?
State ⇒ Feedback
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?
Patch ⇒
Milestone ⇒
Queue ⇒ Kronolith
Summary ⇒ Problem with invitations and WebDAV
Type ⇒ Bug
Priority ⇒ 2. Medium
State ⇒ Unconfirmed
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.