Add a property to calendar provider for invitation type

VERIFIED DUPLICATE of bug 428392

Status

Calendar
Internal Components
VERIFIED DUPLICATE of bug 428392
11 years ago
10 years ago

People

(Reporter: cmtalbert, Unassigned)

Tracking

unspecified
Bug Flags:
wanted-calendar0.9 +

Details

(Reporter)

Description

11 years ago
We need the ability to differentiate from providers that do their own invitation handling (i.e. GDATA and WCAP) and those that use out-of-band mechanisms like email.  

Philipp had an excellent idea about the way to do this using a property on the provider interface.  Here is his comment (from review on bug 379198):
> 
> >+    // XXX Until we rethink attendee support and until such support
> >+    // is worked into the event dialog (which has been done in the prototype
> >+    // dialog to a degree) then we are going to simply hack in some attendee
> >+    // support so that we can round-trip iTIP invitations.
> >+    // Since there is no way to determine the type of transport an
> >+    // attendee requires, we default to email
> To allow providers to override this, what do you say we add a provider property
> like so:
> 
>     var transportType = item.calendar.getProperty("itip.transportType") ||
> "email";
>     var emlSvc =
> Components.classes["@mozilla.org/calendar/itip-transport;1?type=" +
> transportType]
>                           
> .createInstance(Components.interfaces.calIItipTransport);
>

I think this could dovetail nicely with the work needed to create an invitation manager component that would watch all calendars and keep track of the invitations on those calendars.

Comment 1

11 years ago
+1
my draft caldav-sched calIItipTransport code has had to resort to '(if item.calendar.type == "caldav")' hacks thus far. I think this is exactly what's needed.

Comment 2

10 years ago
Either soft property or real API, it's wanted for 0.9.
Flags: wanted-calendar0.9+
Version: Trunk → unspecified
This bug might be fixed in bug 428392. Its an open question if the changes made are enough to allow custom transport types.

Unfortunately, I have found out there is no API to fully handle invitations in gdata. I might have to revert to doing email based scheduling also for gdata.
Fixed in bug 428392.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 428392
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.