5.2.0-git
04/18/2014

[#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 (at) mbpgroup (dot) com
Created 10/28/2008 (1998 days ago)
Due
Updated 01/12/2010 (1557 days ago)
Assigned 10/29/2008 (1997 days ago)
Resolved
Milestone
Patch No

History
02/25/2009 05:35:00 PM Jan Schneider Comment #21 Reply to this comment
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.
02/25/2009 05:04:29 PM CVS Commit Comment #19 Reply to this comment
02/25/2009 04:43:03 PM Klaus (dot) Steinberger (at) physik (dot) uni-muenchen (dot) de Comment #18 Reply to this comment
The patch fixes our problem too (duplicate bug 8015). Please include 
this fix into the next release.


02/05/2009 12:02:03 PM patrick (dot) abiven (at) apitech (dot) fr Comment #17 Reply to this comment
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


11/23/2008 08:35:59 AM hmmsjan (at) kpnplanet (dot) nl Comment #16 Reply to this comment
Thanks for the patch, the behaveour, entering the event in my own 
calendar, is what I as dumb user

would expect.


11/16/2008 10:22:51 PM Chuck Hagenbuch Comment #15
Priority ⇒ 1. Low
State ⇒ Accepted
Type ⇒ Enhancement
Reply to this comment
Converting this to an enhancement to be looked at with IMP 5 work.
11/03/2008 09:07:14 AM rsalmon (at) mbpgroup (dot) com Comment #14 Reply to this comment

[Show Quoted Text - 17 lines]
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.




11/03/2008 07:55:52 AM rsalmon (at) mbpgroup (dot) com Comment #13
New Attachment: itip.patch Download
Reply to this comment
I've attached a patch that seams to be working here.
No patch was attached.
11/01/2008 06:48:05 PM Chuck Hagenbuch Comment #12 Reply to this comment
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.
11/01/2008 11:32:02 AM Jan Schneider Comment #11 Reply to this comment
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.
11/01/2008 03:20:23 AM Chuck Hagenbuch Comment #10 Reply to this comment
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?
11/01/2008 03:19:27 AM Chuck Hagenbuch Comment #9 Reply to this comment
I've attached a patch that seams to be working here.
No patch was attached.
10/29/2008 09:03:33 AM rsalmon (at) mbpgroup (dot) com Comment #8 Reply to this comment
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.


10/29/2008 08:56:22 AM Jan Schneider Comment #7 Reply to this comment
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.
10/29/2008 03:56:16 AM Chuck Hagenbuch Comment #6
State ⇒ Feedback
Summary ⇒ itip: can't add event / shared calendar
Reply to this comment
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.
10/28/2008 02:44:21 PM Jan Schneider Comment #5 Reply to this comment
And this is something you have to teach your users, if I still didn't 
make this clear.
10/28/2008 02:43:32 PM Jan Schneider Comment #4 Reply to this comment
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.
10/28/2008 01:38:47 PM rsalmon (at) mbpgroup (dot) com Comment #3 Reply to this comment
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.




10/28/2008 11:12:49 AM Jan Schneider Comment #2
State ⇒ Not A Bug
Reply to this comment
Either use event invitations, or shared calendars.
10/28/2008 08:55:17 AM rsalmon (at) mbpgroup (dot) com Comment #1
State ⇒ Unconfirmed
Patch ⇒ No
Milestone ⇒
Queue ⇒ IMP
Summary ⇒ itip: can't add event / shared calendar
Type ⇒ Bug
Priority ⇒ 1. Low
Reply to this comment
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')) {