GNOME Bugzilla – Bug 588858
Google through CalDAV meetings and organizers
Last modified: 2009-12-09 17:00:09 UTC
(A follow-up for bug #583374) Cannot create a meeting organized by someone else than a google account owner on the Google server using the CalDAV backend. The same applies to meeting requests and notifications on meeting changes received by mail.
(In reply to comment #0) > Cannot create a meeting organized by someone else than a google account owner > on the Google server using the CalDAV backend. Here it seems we should reconsider the way how new meeting organizers are picked up. There is chosen the correct organizer only if the email account with the same mail as the calendar reports exists and is active. Otherwise the default account mail is used as an organizer, regardless what the calendar returns as an e_cal_get_cal_address. I believe that we should always use the email returned from the ECal, regardless the existence and activity of a mail account with the same email address. > The same applies to meeting requests and notifications on meeting changes > received by mail. I'm quite sure with this that it's some kind of flaw on their side. Evolution uses standard PUT request with the component, and the only "bad" thing is the organizer, when I change it to the calendar owner then it works fine. I filled the issue to them here: http://code.google.com/p/google-caldav-issues/issues/detail?id=38
OK, I played slightly with this and realized they return this from the server when I try to create an event which is organized by someone else: > 403 Cannot create/update events where you are not the organizer Thus it seems they consider it a feature, unfortunately.
*** Bug 587472 has been marked as a duplicate of this bug. ***
I'm closing this as NotGnome, because of quite long discussion in Google's issue tracker (which hopefully will any Google developer read one day). http://code.google.com/p/google-caldav-issues/issues/detail?id=38
*** Bug 599226 has been marked as a duplicate of this bug. ***
*** Bug 601531 has been marked as a duplicate of this bug. ***