Calendar Auto Configuration/Deployment

RESOLVED FIXED in 1.0b1

Status

Calendar
General
--
enhancement
RESOLVED FIXED
11 years ago
8 years ago

People

(Reporter: dbo, Assigned: dbo)

Tracking

({dev-doc-needed})

unspecified
1.0b1
dev-doc-needed
Bug Flags:
wanted-calendar1.0 +

Details

Attachments

(1 attachment)

(Assignee)

Description

11 years ago
Large deployments typically need auto configuration facilities. Regarding Sunbird/Lightning, this means auto configuration of users' calendars. Mozilla's auto configuration is commonly pref-based, see e.g. [1]. Similar to E-Mail accounts, I think of the following pref scheme:

STRING calendar.autoconf.calendars
  (comma separated list of cal-tokens)
BOOLEAN calendar.autoconf.only
  (optional, defaults to false,
   meaning all *non-autoconf'ed* calendars are unregistered/removed,
   i.e. only the autoconf ones are in place)
STRING calendar.autoconf.<cal-token>.uri
  (mandatory)
STRING calendar.autoconf.<cal-token>.type
  (mandatory)
STRING calendar.autoconf.<cal-token>.name
  (optional, defaults to uri.host)
STRING calendar.autoconf.<cal-token>.color
  (optional)
BOOLEAN calendar.autoconf.<cal-token>.visible
  (optional, defaults to true,
   meaning the calendar is pre-checked or not,
   technically whether in composite calendar or not)

e.g.
user_pref("calendar.autoconf.calendars", "cal1,cal2");
user_pref("calendar.autoconf.cal1.uri", "http://...ics");
user_pref("calendar.autoconf.cal1.type", "ics");
user_pref("calendar.autoconf.cal1.color", "#990000");
user_pref("calendar.autoconf.cal1.name", "ics cal");
user_pref("calendar.autoconf.cal2.uri", "https://...");
user_pref("calendar.autoconf.cal2.type", "wcap");

[1] <http://developer.mozilla.org/en/docs/MCD,_Mission_Control_Desktop_AKA_AutoConfig>

Comments please...
(Assignee)

Comment 1

11 years ago
I am asking myself why we should stick to storing the registered calendars in the storage.sdb. A fully pref-based registration would IMO avoid any further scheme for auto configuration (that I sketched above). Performance is IMO no problem; that data is read out once at startup, maybe listen to pref changes, but that's all.
Comments appreciated...
(Assignee)

Updated

10 years ago
Depends on: 403006
(Assignee)

Updated

10 years ago
Blocks: 410287
(Assignee)

Updated

10 years ago
Flags: wanted-calendar0.9+
(Assignee)

Updated

10 years ago
No longer blocks: 410287
Duplicate of this bug: 331901
(Assignee)

Updated

9 years ago
Flags: wanted-calendar1.0+
Flags: wanted-calendar0.9+
Flags: blocking-calendar1.0?
(Assignee)

Comment 3

9 years ago
Created attachment 356069 [details] [diff] [review]
patch - v1

With bug 403006 calendars could now be configured by pref.

This patch:
- changes calICompositeCalendar to not work by URI any longer
- calendar manager sanity checks the calendar.registry about stale entries (-> autoconf changes)
- fixes wcap subscription handling:
  -- if uuid changes, all subscriptions are reinstalled
  -- if default calendar's URI changes, subscribed URIs are corrected
Assignee: nobody → daniel.boelzle
Status: NEW → ASSIGNED
Attachment #356069 - Flags: review?(philipp)
(Assignee)

Updated

9 years ago
Flags: blocking-calendar1.0?
Keywords: qawanted
Comment on attachment 356069 [details] [diff] [review]
patch - v1

Patch looks good, nothing to complain about :-)

r=philipp
Attachment #356069 - Flags: review?(philipp) → review+
(Assignee)

Comment 5

9 years ago
For reference: Configuring a calendar is possibly e.g.

calendars.<id>.name
calendars.<id>.type
calendars.<id>.uri

W.r.t. type "wcap", this is the registration of the "default" calendar of a user. Subscribed calendars of that users will be registered on first startup. Changing the uri of this "default" section (e.g. admin decided to move accounts to a different machine) will patch all uris of subscribed calendars. Changing the id will remove formerly subscribed calendars and reinstall them (e.g. on changing user id).
(Assignee)

Updated

9 years ago
Keywords: dev-doc-needed
(Assignee)

Comment 6

9 years ago
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/b2cb2f44642f>

-> FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Keywords: qawanted
Resolution: --- → FIXED
Target Milestone: --- → 1.0
Target Milestone: 1.0 → 1.0b1
You need to log in before you can comment on or make changes to this bug.