Calendar Auto Configuration/Deployment

RESOLVED FIXED in 1.0b1

Status

--
enhancement
RESOLVED FIXED
12 years ago
9 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

12 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

12 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

11 years ago
Depends on: 403006
(Assignee)

Updated

11 years ago
Blocks: 410287
(Assignee)

Updated

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

Updated

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

Updated

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

Comment 3

10 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

10 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

10 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

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

Comment 6

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

-> FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 10 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.