Closed
Bug 428890
Opened 17 years ago
Closed 17 years ago
Free busy: add email-address-based free-busy URL template for CalDAV
Categories
(Calendar :: Provider: CalDAV, enhancement)
Calendar
Provider: CalDAV
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: roel.van.os, Unassigned)
Details
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5
Build Identifier: Thunderbird 2.0.0.12 (20080213), Lightning 0.8 (2008033121)
Some CalDAV servers support querying of free-busy information by e-mail address. For example, DAViCal accepts queries in the following form: http://calendar.example.net/freebusy.php/username@domain.tld
(Source: http://wiki.davical.org/w/Free_Busy).
It would be very useful to be able to specify the URL used for this kind of querying as a global setting or as a property of a calendar, as opposed to specifying the free-busy URL for each contact separately. This last method is supported by the Inverse SOGo Connector (http://www.inverse.ca/english/contributions/sogo_connector.html), however this has to be done for every contact separately.
Example: allow the user to specify the URL in the following manner:
http://calendar.example.net/freebusy.php/%u@%d, where %u and %d are expanded with the email address.
When a user uses the "Invite Adtendees" feature and adds an attendee, the free-busy information is retrieved from the server based on the email address.
As an alternative, the free-busy URL template could be set in the calendar properties dialog. When a user has multiple calendars, these should all be queried for free-busy information.
Reproducible: Always
Updated•17 years ago
|
Component: General → Provider: CalDav
QA Contact: general → caldav-provider
Comment 1•17 years ago
|
||
I'm not sure I understand. When openening the invite attendees dialog, my freebusy information is displayed in the first line. Are you requesting that more than one calendar is queried for the organizer's freebusy information?
I'm not sure how this should be done in a general manner, currently we have providers that register with the freebusy service and provide that sort of information. requests are merged, so if you request on different servers with the same user then you'll get a merged view.
Making the fb service group this by providers makes a server relate directly to a user, but what if the server has different calendars that do not belong to you as a user? Or what if you created the calendar for someone else (i.e you are the owner), but you just did so because the other person wasn't capable of doing so, meaning that the other person is using the calendar? This would mean you see freebusy information of possibly other users as your own.
It would be nice if you could further explain if I misunderstood something. Otherwise we would probably need some good UI how this could be realized, but I personally would vote for wontfix, since its already possible to see fb info for the organizer of the event and if you need to look at other calendars you own you can still do so using the normal calendar UI.
| Reporter | ||
Comment 2•17 years ago
|
||
I agree that this bug should be closed. The functionality that I was requesting will be available when the CalDAV scheduling extensions are supported.
I was trying to describe the method that Evolution uses (or rather, is supposed to use) for gathering free-busy info of other attendees beside the organizer. At the time I didn't know that the scheduling extensions would be supported, and that these are supposed to support my use case -- this is not very well documented for end users such as myself.
So you have my blessing to close this bug.
Comment 3•17 years ago
|
||
This functionality was only available in DAViCal because Evolution did it this way in the absence of any specification. The (draft-) scheduling extensions do define a way of getting this information, which is now also implemented in a current DAViCal release, and which works with Mozilla.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•