Changes have been made in Git for this ticket:

MFB: If updating a calendar event fails, try to import it instead (Bug #7589).

http://git.horde.org/diff.php/imp/docs/CHANGES?rt=horde-git&r1=8a0737a925868190cab1b15a3df527bedc43bb3a&r2=a5c8a2bfb38d3cc178709a8150e705db81f7cdbf
http://git.horde.org/diff.php/imp/lib/Mime/Viewer/itip.php?rt=horde-git&r1=a402ae9c74de4913a5347b5c7074d6e248778f17&r2=a5c8a2bfb38d3cc178709a8150e705db81f7cdbf

For a temporary fix in IMP 4.3, I opted for Chuck's original 
suggestion. If we find a matching event but fail to update it, then we 
try to import it instead.

Changes have been made in CVS for this ticket:

http://cvs.horde.org/diff.php/imp/docs/CHANGES?rt=horde&r1=1.699.2.381&r2=1.699.2.382&ty=u
http://cvs.horde.org/diff.php/imp/lib/MIME/Viewer/itip.php?rt=horde&r1=1.37.2.44&r2=1.37.2.45&ty=u

Changes have been made in CVS for this ticket:

http://cvs.horde.org/diff.php/kronolith/lib/api.php?rt=horde&r1=1.126.2.56&r2=1.126.2.57&ty=u

The patch fixes our problem too (duplicate bug 8015). Please include 
this fix into the next release.

Thanks for the patch. This feature is definitively valuable for large 
organizations. We are waiting it as a core feature of IMP.

Regards

Patrick

Thanks for the patch, the behaveour, entering the event in my own 
calendar, is what I as dumb user

would expect.

Converting this to an enhancement to be looked at with IMP 5 work.

Another way around could be (and I don't know if it is the right way to go) :

- if a user owns (or has access to) more than one calendar, then add a 
combo box to the itip driver which contains a list of calendars that 
the user can update ( and read ?). The selected calendar will be the 
user's default calendar.

Okay. The fact is that unless we simply switch them off, users are 
going to use invitations in a shared calendaring environment, so I 
think we ought to make this smoother. Saying it's a user education 
issue is fair, but I think the software needs to do some of that 
education; this is a pretty unintuitive error to push off on admins.



So: stepping back a bit, I think we should detect whether the event is 
already on a calendar that the user has access to. We should also 
check the permissions the user has to the event. That way we can offer 
a list of context-specific actions that we know should be possible:



- add this to my calendar (it's not there already)

- update this on my calendar (it's there on a calendar i own)

- create a copy on my calendar (i can see it on someone's calendar, 
but not write to it)

- etc.



I know this will take some API methods that aren't currently there, 
and it probably pushes this from bug to enhancement, but I _think_ 
that will keep things clear and make for a nicer user experience.

That sound like a rather arbitrary limitation to me, and I bet there 
are almost as many users inviting to events they created in another 
user's shared calendar, as users inviting to events created in their 
own shared calendars.

It seems like we should restrict the iTip actions to calendars the 
user owns, or has delegate permissions for. Does that make sense to you?

No patch was attached.

This was working up to itip.php,v 1.95 2008/08/21 23:02:28

My understanding of the itip driver is that it is using the user's 
default calendar to import a new event. If a user created more than 
one calendar (and doesn't have any shared calendar), the itip driver, 
until now, will always import into the default one.



I've attached a patch that seams to be working here.



with this patch, if the new event already exist in user's default 
calendar, it will be replaced and if it doesn't, the new event will be 
created.



it should not affect any other apps.

I expect this to cause even more confusion if not trouble. It's easy 
to imagine a user inviting another user to an event that this other 
user has write permissions for. If this other user is then adding the 
event, it would replace the inviter's event instead, because that's 
the one that the logic in replace() found.

We already have some logic in Kronolith's import method to restrict 
uid searches to the user's default calendar if an explicit calendar 
isn't passed, so we have worked around this problem some before, and I 
think it's going to continue to bite people, especially if we put a 
nicer GUI on scheduling - that'll still do iTip.



How about we just try calling import first, and if we get back an 
error, try replace (in the iTip driver, not in Kronolith)? We should 
also put logic in _kronolith_replace to keep looking through events 
with the same UID to see if the user has permissions to any of them, 
probably starting with the user's default calendar. I have vague 
memories of an open bug for that.

And this is something you have to teach your users, if I still didn't 
make this clear.

This has been discussed a few times, please check the mailing list 
archives. iTip invitations are for synching distinct calendars. It 
doesn't work if the users use the same calendars, due to sharing, 
because of duplicate event UIDs.

I don't understand your answer. If a user receives an event 
invitation, it shouldn't matter if he has read (or modify) permissions 
or not on some other user's calendars.



If a user can see another user's appointments doesn't mean that he has 
been invited too.



When a user receive an event invitation, it is because his presence 
has been requested at that meeting.



When I filled in this issue, I tried to described as simple as 
possible the issue we're having. But if user A creates a new event 
from is calendar and add 10 attendees including user B, user B won't 
be able to update his calendar and therefore won't known that he is 
supposed to attend to that meeting.

Either use event invitations, or shared calendars.

user A shared (SHOW and READ) is calendar to user B

user A add an event and add attended user B : notification is sent

user B open notification and select "Accept and Update in my calendar" 
-> "There was an error updating the event: Permission Denied"





I user A removes the shares on is calendar, user B will be able to 
accept the invitation.



I'm not sure is this issue is a kronolith issue or a IMP/itip issue.



problem seems to come from imp/lib/MIME/Viewer/itip.php / function 
render / case 'accept-import' / case 'vEvent'



the following call doesn't fail, so the code that follows will try to 
update the shared calendar instead of the calendar of the user that is 
logged in:



                     if ($registry->hasMethod('calendar/export') &&

                         !is_a($registry->call('calendar/export', 
array($guid, 'text/calendar')), 'PEAR_Error')) {