[#7589] itip: can't add event / shared calendar
Summary itip: can't add event / shared calendar
Queue IMP
Queue Version HEAD
Type Enhancement
State Accepted
Priority 1. Low
Owners
Requester rsalmon@mbpgroup.com
Created 2008-10-28 (4350 days ago)
Due
Updated 2010-01-12 (3909 days ago)
Assigned 2008-10-29 (4349 days ago)
Resolved
Milestone
Patch No

Comments
rsalmon@mbpgroup.com 2008-10-28 08:55:17
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')) {





Jan Schneider <jan@horde.org> 2008-10-28 11:12:49
Either use event invitations, or shared calendars.

rsalmon@mbpgroup.com 2008-10-28 13:38:47
> Either use event invitations, or shared calendars.



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.





Jan Schneider <jan@horde.org> 2008-10-28 14:43:32
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.

Jan Schneider <jan@horde.org> 2008-10-28 14:44:21
And this is something you have to teach your users, if I still didn't 
make this clear.

Chuck Hagenbuch <chuck@horde.org> 2008-10-29 03:56:16
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.

Jan Schneider <jan@horde.org> 2008-10-29 08:56:22
> 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.



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.

rsalmon@mbpgroup.com 2008-10-29 09:03:33
> 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.



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.



Chuck Hagenbuch <chuck@horde.org> 2008-11-01 03:19:27
> I've attached a patch that seams to be working here.



No patch was attached.

Chuck Hagenbuch <chuck@horde.org> 2008-11-01 03:20:23
> 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.



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?

Jan Schneider <jan@horde.org> 2008-11-01 11:32:02
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.

Chuck Hagenbuch <chuck@horde.org> 2008-11-01 18:48:05
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.

rsalmon@mbpgroup.com 2008-11-03 07:55:52
>> I've attached a patch that seams to be working here.

>

> No patch was attached.



rsalmon@mbpgroup.com 2008-11-03 09:07:14
> 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.



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.





Chuck Hagenbuch <chuck@horde.org> 2008-11-16 22:22:51
Converting this to an enhancement to be looked at with IMP 5 work.

hmmsjan@kpnplanet.nl 2008-11-23 08:35:59
Thanks for the patch, the behaveour, entering the event in my own 
calendar, is what I as dumb user

would expect.



patrick.abiven@apitech.fr 2009-02-05 12:02:03
> Thanks for the patch, the behaveour, entering the event in my own

> calendar, is what I as dumb user

> would expect.

>

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

Regards

Patrick



Klaus.Steinberger@physik.uni-muenchen.de 2009-02-25 16:43:03
The patch fixes our problem too (duplicate bug 8015). Please include 
this fix into the next release.



CVS Commit <cvs@lists.horde.org> 2009-02-25 17:04:29

CVS Commit <cvs@lists.horde.org> 2009-02-25 17:32:06

Jan Schneider <jan@horde.org> 2009-02-25 17:35:00
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.

CVS Commit <cvs@lists.horde.org> 2010-01-12 23:59:57