Open Bug 1029358 Opened 10 years ago Updated 1 year ago

Do email based scheduling, if serverside caldav scheduling failed

Categories

(Calendar :: Provider: CalDAV, enhancement)

enhancement

Tracking

(Not tracked)

People

(Reporter: ratki, Unassigned)

References

Details

User Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20140429 Firefox/24.0 Iceweasel/24.5.0 (Nightly/Aurora) Build ID: 20140429201742 Steps to reproduce: I use Egroupware community version 1.8 as a calendar server and Debian's iceowl 2.6.5 with icedove as client. I insert a new event with attendee outside of our domain... Actual results: Event is stored in egroupware.- OK My problem is that neither egroupware nor iceowl sends an e-mail to the attendee. Same behavior if I accept an invitation from outside of our domain. The chair won't get my positive/negative answer. Expected results: I wish I could force iceowl to send e-mail to partners outside of our domain. For me is good enough if I could define this only in pref.js (No GUI is needing): calendar.registry.XXX.forceSendEmailOutsideOfDomain boolean true calendar.registry.XXX.myDomain string @my.domain I know it isn't a bug, it is only a "nice to have". Thanks anyway, Tamás
Severity: normal → enhancement
The root cause is the (insufficient) serverside scheduling capability. With bug 1299610, we will implement an option to enforce sending outgoing scheduling messages by email, but without the whitelisting part for certain domains. Better then an explicit whitelisting, we should extend that implemantion by falling back to email scheduling once a serverside scheduling operation failed hard (schedule-status not 1.0, 1.1 or 1.2), which we can inspect when re-retrieving the event from the caldav server.
Status: UNCONFIRMED → NEW
Depends on: 1299610
Ever confirmed: true
Component: E-mail based Scheduling (iTIP/iMIP) → Provider: CalDAV
Summary: Change for using Egroupware (Wish, not bug] → Do email based scheduling, if serverside caldav scheduling failed
Version: Lightning 2.6.5 → Trunk
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.