Auto-provisioning calendar data/shared calendars

[Rich Graves]

So, at long last, we've made a decision to license Zimbra for our 3000-some users, just as UW-Milwakee did for their 65,000 users. See https://apps.carleton.edu/campus/its...dar_Report.pdf and https://www4.uwm.edu/imt/about/news/zimbra/index.cfm

Carleton College will be engaging Zimbra's professional services team to, essentially, determine the "right" answers to the various questions posed in this thread. To the maximum extent possible, all work done will be released under licenses at least as liberal as Zimbra itself. Everyone benefits when common solutions can be adopted.

Our likely strategy will include designating our Moodle installation as the authoritative source and/or aggregation point for all course-related calendar and task data, so that professors need only make changes using appropriate Moodle tools, and the changes will cascade to each student's Zimbra calendar using iCalendar or XML protocols chosen with Zimbra professional services' help. There's some likelihood that some small amount of new code will need to be written on the Zimbra side to handle course adds, drops, and changes. That code probably won't be appropriate for general distribution along with Zimbra, but we won't consider it proprietary.

[nrc]

Originally Posted by Rich Graves

So, at long last, we've made a decision to license Zimbra for our 3000-some users, just as UW-Milwakee did for their 65,000 users. See https://apps.carleton.edu/campus/its...dar_Report.pdf and https://www4.uwm.edu/imt/about/news/zimbra/index.cfm

Carleton College will be engaging Zimbra's professional services team to, essentially, determine the "right" answers to the various questions posed in this thread. To the maximum extent possible, all work done will be released under licenses at least as liberal as Zimbra itself. Everyone benefits when common solutions can be adopted..

Great to hear.

We're still demoing at our institution, fighting the momentum toward Exchange created by previous IT administrations, but the development team jumped on the bandwagon when we showed them the calendaring features and explained the interfaces available.

[Rich Graves]

Two slightly different solutions for two slightly different use cases.

1) The general "Residential Calendar" and "Academic Calendar"

These calendars are and will continue to be maintained in a non-Zimbra content management system. We (i.e., Matt Bockol, not me) wrote some code to make a proper iCal feed out of it. We created a "web services group calendars" resource account that subscribes to the feed via iCal, set up a cron job to refresh that iCal feed periodically, and then re-share that calendar with everyone. Upon account creation, we mount the two public calendars at /Residential Calendar and /Academic Calendar using zmmailbox (see schemers' posts above). This is a lot faster than subscribing each individual user to the iCal feed.

2) Course schedules and Moodle one-offs

We chose to feed course schedule data into our Moodle LMS, and re-export it from there as a single iCal feed, not one feed (or share) per course. This required a moderate amount of coding, all external to Zimbra, to munge our student registration data and beat the alpha-quality iCal support in the latest version of Moodle into shape, but it's done now, and the code could be made available to other institutions on request.

We created two new Moodle REST URLs:

2a) List all users on the Moodle system (since not every Zimbra user is a Moodle user)

2b) Accepts two arguments: username and a sha1(secret key+username) digital signature (which along with source IP address serves as authentication, and discourages user A from stealing user B's iCal feed). Returns that user's iCal feed.

All users are subscribed to their own personal Moodle calendars URL, including the sha1 signature. The initial load of about 2,200 users' calendars took 7 hours. Incremental updates take about a half hour. We plan to refresh course schedules and force reload of the iCal feeds (see responses from Zimbra employees above) on a nightly basis.

We have just one problem with this system -- next post.

[Rich Graves]

Our calendar provisioning code boils down to:

my $add_command = "zmmailbox -z -m " . $user . " cf --view appointment --color cyan --flags \"b#\" \"/Moodle\""; 

my $urlset_command = "zmmailbox -z -m " . $user . " mfu \"/Moodle\" \"$cal_url\"";

my $sync_command = "zmmailbox -z -m " . $user . " syncFolder \"/Moodle\"";

Problem: At first, we did not properly check the return code/output of $add_command. We have five users who had a top-level *email* folder named Moodle. Those folders are now in a state where neither the iCal feed nor the emails previously in those folders are accessible. How can we fix them? zmmailbox mfu doesn't seem to let you unset the URL.

[mmorse]

hm, can't set the modifyFolderURL back to what it was? (try this on a test account because I would hate to have you loose mail in those folders) plus you might need to change the defaultView/foldertype so that you could go into the mail app to actually check if everything's showing up fine. Then instead of rename, transfer/copy the mail to a new folder/possibly grab it out to a .zip with rest. (transfer/copy instead of rename just so your sure there's no quirks leftover.) then delete the offending folder.

[hchan]

re: automating icalendar share reload

I'm reading through this thread and am still not clear on how to automate the reload for a calendar share that I'm bringing in from an outside ics. Right now, I'm manually going in and reloading the calendars but having been burned by an event that didn't show up because of a missed manual reload, I'd like to get very clear on how to automate this.

Or has this been fixed yet? I'm currently using the Network Edition version 5.0.4 soon to be 5.0.5...

Thanks.

[webman]

Is there any detailed documentation on the --view and --flags parameters used by zmmailbox? I can't seem to find out what they are/do. Thanks

[Rich Graves]

There still is no server support for auto-refreshing feeds, but you can make a cron job. The command line to refresh the "Feed" folder for user@example.com is zmmailbox -z -m user@example.com syncFolder /Feed. RSS and iCal are the same.

For user-specific provisioned calendars, we sync all users (enumerate with zmprov gaa example.com) hourly; for more stable holiday and academic schedule calendars, we sync daily into an account that shares several calendars with all users.

--view is self-correcting:

mbox foo@example.com> cf --view bogus /that
ERROR: zclient.CLIENT_ERROR (invalid view: bogus, valid values: [appointment, contact, conversation, document, message, wiki, task, voice])

--flags, I'm not sure. For calendars, --flags '#' means the calendar will be selected, i.e., show/hide checkbox checked.

[hchan]

re: cron job to automatically reload a calendar feed

Ok, so if I'm understanding this correctly, if I have a user, e.g. user@example.com on my system who is receiving an iCal feed from outside and is sharing to a group of internal users, all I need to do to get up to date data to the internal group is to put the following into a crontab (as the "zimbra" user)?

zmmailbox -z -m user@example.com syncFolder /Feed

Thanks in advance. I just wanted to be absolutely clear on what I have to do.

[hchan]

FWIW, when I used the zmmailbox command above in a crontab to handle 5 different iCal feeds, I caused the system to fail when I increased the frequency to once very 10 minutes.

Is there any update on when iCal feed refreshes can be done in a cleaner way? Any suggestions on how to better do the zmmailbox crontab method?

Thanks.