Skip to end of metadata
Go to start of metadata

Problem Statement

The Language Learning Center (LLC) adopted Google Calendar from UW Google Apps for shared resource calendaring among departmental staff. To do so, an admin in the LLC enabled UW Google Apps for a departmental Shared UW NetID and then created a few dozen "resource" calendars for electronic classrooms, labs, media suites, media equipment, etc. (All calendars created by the shared account are "resource" calendars.)

Given that graduate staff position appointees change regularly, the calendar admin had to update (add/delete) the various resource calendars whenever staff departed or came on board. This was a fair amount of manual effort.

While UW Google Calendar resource calendars (as opposed to a base shared, or otherwise, "user" calendar) can be shared out to UW groups, members are not automatically subscribed to the calendars. They must subscribe to them. This is an important fact and explains why the following solution was employed.

Solution

The LLC created a uw_llc home group in the UW Groups service and then created three subgroups, activating each subgroup for UW Google Apps:

  • uw_llc_staff_core, membership: core staff by UW NetID
  • uw_llc_staff_grad, membership: graduate staff by UW NetID
  • uw_llc_staff_all, membership: uw_llc_staff_core and uw_llc_staff_grad

Note: Individual staff members were added to the uw_llc_staff_core and uw_llc_staff_grad groups using their UW NetIDs, e.g., "smyth123" (without "@uw.edu").

Initially, the calendar admin must share the resource calendars to the group(s), e.g., "See all event details" or "Make changes to events", and may give individuals (e.g., a person who schedules rooms) with a privilege such as "Make Changes to Events" or "Make changes and manage sharing". The latter makes it so a person can manage sharing without having to log into the account for the shared UW NetID.

Note: when a user is a member of a group that has a lower level of privilege, e.g., "See all event details" or "Make changes to events", and also is individually granted greater privilege, e.g., "Make changes and manage sharing", the greater privilege trumps (as it should). This is known to be true when the user with greater privilege is granted that as a user; however, presumably the same effect would occur if that greater privilege was granted via a group.

Next, new staff are instructed (as part of routine new staff actions, outlined in our wiki) to copy the entire block of resource calendar addresses using the Calendar ID (URL) found on Calendar Details > Calendar Address (the Calendar Names will not work!); these are all listed comma-delimited on the LLC internal wiki:

uw.edu_b4cgt0n0clhpka5do@group.calendar.google.com, uw.edu_tkgp1h741an3li52s@group.calendar.google.com, (etc.)

The staff then to paste the Calendars into the "Other calendars" box, on the left side of the main calendar page, and press enter or return.

Result

This solution results in staff being subscribed to all the resource calendars in the department, with whatever calendar privileges shared out to the groups.

While there is some initial set up and documentation involved with this solution, we believe that having each new staff spend just a few minutes subscribing to a list of calendar IDs and a list of staff calendars, and then having an admin simply maintain the UW Groups memberships, makes a lot of sense from an efficiency perspective.

Staff can also share out their own calendars to a group, also by sharing their calendar to the Google group address (e.g., "uw_llc_staff_all@uw.edu"); then other staff must enter a comma-delimited string of staff UW NetIDs, e.g. "smyth123, perez987" to subscribe, since a group email "uw_llc_staff_all@uw.edu" doesn't resolve to the individual calendar IDs of group members. For this method, it is best for someone to maintain an updated list of all staff UW NetIDs on a wiki or other shared location.

Some other noteworthy issues:

  • For UW Google Apps, always use the @uw.edu form; not @u.washington.edu.
  • The mechanisms of the following continue to remain a bit elusive, but it appears that once a person is subscribed to a calendar, if that person is removed from sharing of that calendar, and then subsequently given access by that calendar being shared out to a group the person belongs to, that the calendar will show up in the person's list of calendar with no effort on behalf of the person. However there is often latency before this occurs, which varies widely. The reason for mentioning all this, is that the ramifications can confound testing and/or assumptions about how things work. Some additional testing might be in order to clarify the behavior.
  • One of our groups, created in the early days of groups, appeared to have been corrupted somehow; perhaps during an automated upgrading to a new version of Groups. After rebuilding the group, all worked fine.
  • No labels