Closed Bug 463392 Opened 11 years ago Closed 10 years ago

caldav calendars are not visible in the 'select calendar' dialog

Categories

(Calendar :: Provider: CalDAV, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: andreas.treumann, Assigned: nomisvai)

References

Details

(Keywords: regression, Whiteboard: [needed beta][has l10n impact])

Attachments

(1 file, 2 obsolete files)

STEPS TO REPRODUCE:
===================

- create 2 local storage calendars
- create a caldav calendar
- open a iMip/iTip email
- push the 'Accept' button

RESULT:
=======

- the 'select calendar' dialog shows only the local storage calendars
- the caldav calendar is not visible

EXPECTED RESULT:
================

- all calendars should be visible

REPRODUCIBLE:
=============

- always

I checked this also with WCAP calendars and this kind of calendars are visible, too.
Flags: wanted-calendar1.0?
Version: Mozilla 1.8 Branch → Trunk
Isn't invitation handling disabled for CalDAV calendars?
I checked this with calendar.caldav.sched.enabled = 'true' and 'false'. In both cases I get no caldav calendar in the 'select calendar' dialog

lightning build 20081105022227
Regardless of caldav sched it ought to be possible to store iMIP invitations in the calendar.
Flags: wanted-calendar1.0? → blocking-calendar1.0+
This works for me using the latest nightlies and (2x Local, 1x Google CalDAV)  please confirm.
Keywords: qawanted
Whiteboard: [need confirm]
Whiteboard: [need confirm] → [not needed beta][no l10n impact]
I can confirm now under some extra circumstances. Possibly, this behavior is wanted, but maybe Daniel can confirm here:


The calendars available in the choose calendar dialog are filtered:


* Is a scheduling Calendar:
  * Only writable calendars
  * that have an organizer id
  * and have an iTIP transport

* If the iTIP method is REQUEST
  * Those calendars that have an email configured to match an attendee.


For some reason, this means that all calendars that are scheduling calendars and have "None" selected will not show up.
The calendar that I'm missing doesn't seem to have an itip.transport
Andreas: Which CalDAV server are you using?

Perhaps this issue is related to bug 454180.
Daniel, any updates on comment #5 ?
Assignee: nobody → simon.at.orcl
I think Lighting was trying too hard to be "smart" about what the user should do:
- If I receive an invitation at work and I want to add it to one of my personal calendar (which has a different "attendee" associated to it) I should be able to.
- If I want to import it in a caldav calendar that has auto-schedule support (no itip transport) I should be able to as well. 

So this patch removes these restrictions. I also fixed a display bug in the chooseCalendarDialog.xul causing the list of calendar to be incomplete (Thanks Philipp!)
Attachment #435201 - Flags: review?(philipp)
Status: NEW → ASSIGNED
Comment on attachment 435201 [details] [diff] [review]
Patch to enable all writable calendars for import

I talked to dbo via IRC and we came to the conclusion that just enabling all calendars this way isn't a good idea. The event comes in as an invitation that expects a reply. If we don't have a corresponding identity, we can't send a reply.

What we could do to fix this bug is modify the dialog a bit: If there are no calendars available with the right identity (what we have been checking before), then change the dialog text a bit, and change the "OK" button to "Import". The dialog should make clear that you are only saving a copy into the calendar and no invitations will be sent.

We need to be careful though, if the user publishes an event into a different scheduling calendar, then editing the event might cause the send-invitations dialog to show, right?
Attachment #435201 - Flags: review?(philipp) → review-
Attached patch patch v2 (obsolete) — Splinter Review
Try to bring a bit of the new caldav schedule draft into Lightning by introducing the use of SCHEDULE-AGENT=CLIENT for incoming imip invitations. I'm pretty sure that the things that need to be done are done correctly but they might not be done at the right place in the code so please let me know if that is the case.
Attachment #435201 - Attachment is obsolete: true
Attachment #442884 - Flags: review?(philipp)
If an invitation is received by e-mail, then we should reply by e-mail, even if the calendar I wish to insert it into is a scheduling-capable calendar, and so if that's what Simon's latest patch is doing with the SCHEDULE-AGENT=CLIENT change then it is a sensible addition.

I still wonder about the overly narrow specification of the calendar selection, however.

I personally have a gazillion e-mail addresses that all end up in the same mailbox.  If someone sends me an invitation to awm at debian.org, which I want to put into my CalDAV calendar, does this mean I cannot do that?  Were I to reply to an e-mail sent to that address the reply would normally come from my morphoss.com e-mail address, and it seems OK to me for the reply to an invitation to come from the e-mail address configured for the calendar that I put it in.

Another common situation is when a person is recipient of a role address, like 'reception@' or 'support@' and is invited to a meeting.  One individual recipient might be designated as the person who responds, or in some cases all recipients might want to insert the event into their calendars (such as an invitation sent to 'directors@' for a meeting with the company accountant).  The sender might not know if one or several of the recipients might respond, or who the responder(s) might be until the replies come in.  Similarly for when I receive an invitation to an event, but I delegate the attendance to someone else entirely by simply forwarding the invitation to them.
Duplicate of this bug: 547479
Comment on attachment 442884 [details] [diff] [review]
patch v2

>             case "itip.transport":
>+                if (this.hasScheduling || this.hasAutoScheduling) {
>                     return this.QueryInterface(Components.interfaces.calIItipTransport);
>                 } // else use outbound email-based iTIP (from cal.ProviderBase)
Hmm we return the itip transport even for auto scheduling?

>-                    delete thisCalendar.mHrefIndex[eventUri.path];
>+                    let decodedHRef = decodeURIComponent(eventUri.path);
>+                    delete thisCalendar.mHrefIndex[decodedHRef];
What bug is behind this? In the future, I'd appreciate if you could split such things into different bugs. Small patches often means quicker reviews ;-)

>+            try {
>+                // canNotify should return false if the schedule agent is client
>+                // so the itip transport takes care of notifying participants
>+                return !(aItem.organizer.getProperty("SCHEDULE-AGENT") == "CLIENT");
>+            }
>+            catch (e) {}
Can we solve this without a swallowing catch block?

>+            if (aItipItem.responseMethod == "REPLY") {
>+                let imipTransport = cal.getImipTransport(this);
>+                if (imipTransport) {
>+                    cal.ERROR("imipTransport.sendItems");
I assume this is just debug? Please remove.


A few style nits:
b/calendar/base/modules/calItipUtils.jsm:169: Missing blank before `(`
+                       if(subItem.organizer) {

b/calendar/lightning/content/imip-bar.js:397: Trailing whitespace
+    

b/calendar/providers/caldav/calDavCalendar.js:2186: Trailing whitespace
+            // parameter SCHEDULE-AGENT set to CLIENT, this property is 


Also, for some reason, with the patch applied the Accept/Decline/Tentative Buttons do not show in the imip bar. r- because of this. Go ahead and create an extra patch for the strings though and check it in.
Attachment #442884 - Flags: review?(philipp) → review-
Attachment #444179 - Flags: review?(philipp) → review+
Comment on attachment 444179 [details] [diff] [review]
patch v3, fixed for review + bugfix in caldav multiget not calling the listener which means some itip replies were not being sent


r=philipp
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/ef67aa880d36>
-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0b2
Whiteboard: [not needed beta][no l10n impact] → [needed beta][no l10n impact]
Whiteboard: [needed beta][no l10n impact] → [needed beta][has l10n impact]
Hi Andrew, 

(In reply to comment #12)
> If an invitation is received by e-mail, then we should reply by e-mail, even if
> the calendar I wish to insert it into is a scheduling-capable calendar, and so
> if that's what Simon's latest patch is doing with the SCHEDULE-AGENT=CLIENT
> change then it is a sensible addition.
> 
Yes this is what the patch does. To be more precise, the SCHEDULE-AGENT parameter is defined in http://tools.ietf.org/html/draft-desruisseaux-caldav-sched (CalDAV Scheduling Extensions to WebDAV)and only applies to caldav servers returning "calendar-auto-schedule" in the DAV response header of an OPTIONS request.

> I still wonder about the overly narrow specification of the calendar 
> selection, however.

I agree with you that the current behavior is a bit restricted but it's not as bad as I initially though, here is the current behavior:

1) If one calendar is found with an email identity matching the invitation recipient, the user has to use this calendar to deal with the invitation
2) If more than one calendar is found with an email identity matching the invitation recipient, the user has to pick the calendar from a list limited to the calendars matching the email identity.
3) If no calendar identity matches the recipient, then the user has to pick the calendar from a list of all scheduling calendars matching the email identity.

CalDAV now always advertises support for itip.transport as does most other providers so when we say "scheduling calendars" it pretty much means "all calendars"...

I think that if a user gets to #3 he might run into important interoperability issues with the organizer of the meeting since the replies to the invitation will come from a different recipient so I actually like the current behavior of limiting the user's choices whenever possible, but extending it when running out of options.
Corresponding libical bug for tracking the support of the new SCHEDULE parameters to the library:
https://sourceforge.net/tracker/?func=detail&atid=116077&aid=3133591&group_id=16077
I'm seeing the exact same behavior with Lightning 1.1 in TB 9 on Win7. My CalDAV calendars are on Zimbra.
-> I don't consider this fixed. Reopen or a new bug?
(In reply to marcel from comment #21)
> I'm seeing the exact same behavior with Lightning 1.1 in TB 9 on Win7. My
> CalDAV calendars are on Zimbra.
> -> I don't consider this fixed. Reopen or a new bug?

Marcel, please file a new bug and reference this bug there. Thank you!
(In reply to Martin Schröder [:mschroeder] from comment #22)
> (In reply to marcel from comment #21)
> > I'm seeing the exact same behavior with Lightning 1.1 in TB 9 on Win7. My
> > CalDAV calendars are on Zimbra.
> > -> I don't consider this fixed. Reopen or a new bug?
> 
> Marcel, please file a new bug and reference this bug there. Thank you!

Done -> bug 719226
You need to log in before you can comment on or make changes to this bug.