From Suzanne on Mon, Sep 19, 7:44 AM (2 days ago):

Hi Rob,

Hoping you can help me out with something. There are two RCSC classes in March that had screwed up dates. We changed the dates, but it was still incorrect on the Google Calendar, so we ended up deleting them and recreating new ones. The two deleted events are still on the google calendar though after two days. Can you please help removed, or help me understand how I can remove?

Thank you very much, -Suzanne

On every run, I get the following message (emails have been anonymized) for the same two users.

2022-02-02T03:41:28.586925Z  INFO scma_gcal_sync::output::gcal: Determined sync operations ops.len=4 ops=[Insert("[email protected]"), Insert("[email protected]"), Delete("[email protected]"), Delete("[email protected]")]

I suspect that Google Calendar is resolving email aliases behind the scenes. For example, if I insert [email protected] Google Calendar returns a response that it inserted [email protected]. But when I do an acl.list, I don't get back [email protected] . Instead, I get back [email protected]. In between the acl.insert response and and the acl.list, Google Calendar resolved the email alias and replaced the ACL rule with the resolved email address.

Until this is resolved, the calendar will be removed from these users' Google Calendar on every run and therefore unusable.

The first solution that comes to mind is an email map that maps an SCMA member's email address to the resolved email address. The email map would be represented as a list of key-value pairs. Or JSON. Something like:

{
  "[email protected]": "[email protected]",
  "[email protected]": "[email protected]"
}

The app currently uses an OAuth 2.0 Client ID (OACID) to authenticate with Google Calendar. It turns out that this flow generates OAuth tokens with a short lifetime (measured in days) when the Google Cloud Platform (GCP) project publishing status is "testing". To get tokens that unlimited lifetime tokens, the GCP project must be published. To get published, it needs to go through verification. To get verified, the app needs a privacy policy (see PRIVACY.adoc). Then you need to wait 4-6 weeks. I've initiated the process and am now waiting for the response.

The other option is to use a Service Account (SA) instead of the of an OACID. This has several benefits over the OACID.

• SAs don't require user interaction. Unlimited-lifetime OACID tokens require a one time user interaction to login and accept access.
• SAs don't require a verification process

There is one slight complication however. SAs do not have access to the user's Google Calendar data. Instead, SAs seem to only have access to GCP project data. In other words, the SA effectively has its own Google Calendar account. See SO. It can create a calendar then give co-ownership of said calendar to the user. But it cannot access a user's calendar directly. This requires the application to implement additional calendar management logic including calendar creation and granting co-ownership.

• [x] Create GitHub Action for production event sync
• [x] Create GitHub Action for production ACL sync (with ACL insert notifications disabled)
• [x] Transition all beta testers to production calendar
• [x] Clear with SCMA board
• [x] Beta test for one week
• [x] Announce SCMA Google Calendar on SCMA blog (to notify current members)
• [x] #37

scma-gcal-sync currently fetches all events when fetching the event list but then only uses the present/active and future events by default (see the --all option). This puts unnecessary load on the SCMA server and creates unnecessary traffic on the wire.

After some searching, I found some source code for Ohanah, the third-party Joomla extension that the SCMA website uses to manage events. I reviewed the source and found some promising query parameters. In particular, I found the starting_date parameter (see views/events/json.php:39).

I tried this with a YYYY-MM-DD formatted date and it worked!

Update the event list fetching to include this when the min_date is Some(date).

when none present. This was the original intent but not how it turned out.

The alternative is to keep the sections and display "None".

Example of Issue

Migrate from the old Ruby version to this new Rust version.

• [x] Disable scma-gcal-sync-rb workflow
• [x] Delete all events from the existing SCMA Google calendar
• [x] Change default calendar from "SCMA Test" to "SCMA"
• [x] Run scma-gcal-sync --all to fully populate the calendar
• [x] Publish a v1.2.0 release

This PR upgrades depedencies.

NOTES:

• hyper-rusttls had a breaking change that required a small refactor
• Cannot use yup-oauth2 v7. Need to use the same version as the Google API crates which is v6.

BREAKING CHANGE:

This change invalidates any previous OAuth tokens.

Occasionally an active user will be unexpectedly deleted from the Google Calendar ACL.

After some debugging, it was found that the email obfuscation used on the SCMA roster webpage sometimes reuses "addy" IDs for the same user. The scma-gcal-sync email deobfuscation algorithm assumes the "addy" IDs are unique. The deobfuscation algorithm needs to be updated to handle reuse of "addy" IDs.

The problem will cause a user to incorrectly have the email address of another user.

This problem can may also create problems with the Google Contacts syncing.

This PR adds the --auth-type (oauth|service-account|infer) option that defaults to infer. The possible values are:

• oauth -- Use OAuth user account authentication
• service-account -- Use service account authentication
• infer -- Infer the auth-type based on the service.
  • Google Calendar infers service-account
  • Google People infers oauth.

BREAKING CHANGE: This changes the default authentication type for the Google Calendar API from OAuth to service account authentication.

Closes #25

This release adds the ability to sync users to both the Google Calendar ACL (Access Control List) and Google Contacts. The ACL sync feature automates calendar access management. It gives all SCMA members read access to the calendar and removes access for any non-SCMA members (i.e. those that are no longer SCMA members).

Added

• Added auto create the named calendar if it doesn't exist
• Added --dry-run option
• Added Google Calendar ACL sync
• Added Google Contacts sync

Changed

• Normalize SCMA phone numbers using "+1##########" format. Previously used the whatever format was given which varied from member to member.
• Normalize SCMA emails to use all lowercase. Previously used whatever case was given which varied from member to member.

Running with RUST_LOG=debug doesn't enable debug output. This is likely due to the use of the add_directive("info".parse()?) call.

Removing the add_directive("info".parse()?) call, from the default EnvFilter, fixes RUST_LOG=debug. However, when RUST_LOG is undefined, now info output doesn't show.

A workaround is available at https://github.com/tokio-rs/tracing/issues/735#issuecomment-957884930