Can this be adapted to support multiple users in one run?

[rooday-doordash]

Basically could I create a single GCP project for my org's CalendarSync, and then reuse that client ID and client secret across many sync.yaml files (I'm imagining each user in my org would configure their file and add it to a repo), and then run calendar sync for those files? Would there need to be any change to CalendarSync, or if in it's current state could it do this?

- CalendarSync/
    - calendarsync
    - auth-storage.yaml
    - user1-sync.yaml
    - user2-sync.yaml
    ...

Then have some script that on a schedule does:

userConfigs = all *-sync.yaml files
for userConfig in userConfigs
    CALENDARSYNC_ENCRYPTION_KEY=sharedkey ./calendarsync --config userConfig

[rooday-doordash]

Actually the immediate issue I see with this is that when you run it, it brings you to project consent page, which users won't see if this runs on a service account. Is there any way this could be configured such that if we used a service account credentials that had access to the org's calendars, it could handle syncing for them without needing to show the consent screen?

[MichaelEischer]

Is there any way this could be configured such that if we used a service account credentials that had access to the org's calendars, it could handle syncing for them without needing to show the consent screen?

calendarsync just issues a regular oauth authentication reqest, see https://github.com/inovex/CalendarSync/blob/8b2c5a3e3d54c7fe98ec7a82cdeab3ef2fe5e6dd/internal/adapter/google/adapter.go#L109 . The consent page itself is controlled by GCP. If you have credentials that don't require such a consent then yes, otherwise no. (Don't know if GCP offers that option)

If you use the same service account for everything, then you can probably also share the auth-storage file between invocations. Just be careful to not sync the wrong calendars then. That way you'd only have to authenticate the service account once.