Synchronise Lookup groups.
This causes Lookup groups and their members to be synchronised with groups in Google. As for people, there are various configuration options to control which groups to synchronise, and enforce limits on the number of changes the script will perform.
The group name and email in Google are based on the Lookup groupID and groupName, noting that the email is the group's unique identifier in Google:
email = {groupID}@{groups_domain} name = {groupName}@groups.lookup.cam.ac.uk
where groups_domain is a configurable secondary domain or domain alias for groups in Google.
The rationale for this choice is that it will allow for easier searching by Lookup groupID and groupName (assuming that searches operate from the start of these fields), while using a separate namespace for group identifiers to avoid possible conflicts with users and groups from other sources.
Note: The main sync.py script has become quite long, and could probably use refactoring, but keeping it as it is for now to make it easier to diff.
Closes #10 (closed)
Merge request reports
Activity
assigned to @rjw57
mentioned in issue #10 (closed)
219 330 } 220 331 google_user_creations[uid] = new_user 221 332 333 # For each group which exists in Google or the managed group set which is eligible, determine 334 # if it needs updating/creating. If so, record a patch/insert for the group. 335 google_group_updates = {} 336 google_group_creations = {} 337 for groupID, managed_group_entry in managed_group_entries_by_groupID.items(): 338 # Form expected group resource fields. Group names and descriptions can have a maximum of 339 # 73 and 4096 characters respectively in Google. 340 expected_google_group = { 341 'name': _trim_text( 342 managed_group_entry.groupName, maxlen=73, suffix='@groups.lookup.cam.ac.uk' 343 ), 344 'description': _trim_text(managed_group_entry.description, maxlen=4096) 345 } -
Groups are created with very permissive settings:
For some reason best known to Google, group settings are found in a completely different castle^WAPI: https://developers.google.com/admin-sdk/groups-settings/v1/reference/groups#json
I'd feel happier if managed groups were at least created with locked down permissions. Even better if those permissions were reset on each sync if necessary.
-
We had a conversation as per #10 (comment 153204) and decided that on creation we'd set the permissions as follows:
The API doesn't allow the group settings to be set exactly as above - Contact owners cannot be set to Group Owners only via the API, but it can be set to Group Managers, which ought to be good enough, since we don't actually have any owners or managers.
Further discussion suggested that we might need to grant Publish posts to at least Group Members.
The API has settings that allow all posts to be moderated, which might be useful, depending on how that is handled in practice.
On further reflection, it seems preferable to check those settings and apply them to all groups, if different, each time the script is run rather than only at group creation time. Doing it only at group creation runs the risk that the settings-update API call may fail, leaving the group with overly permissive settings. Also, given that not all options that are possible using the UI are possible using the API, further experimentation with the group settings should be done via the script rather than the UI. Thus it is useful for the script to update the settings of existing groups as well as new ones.
-
Ignore me. I just saw !7 (diffs) which implements this.
mentioned in issue #11 (closed)
-
I've added the decisions made and documented in #10 (comment 153204) to the appropriate review comments.
unassigned @rjw57
mentioned in commit 4917ca18
