Intermittent Authentication Error When Using Another User’s Google Calendar as an AppSheet Calendar Data Source

AppSheet AppSheet Q&A
1

I created a schedule management app. I am the owner of the app.
However, the Google Calendar used for the schedule is owned by someone else, and he enters all of his appointments there, not only the ones used by the app.

At first, everything worked without any issues, but within the last year or so, authentication errors have started to occur. When I reload the calendar table from My Account → Sources in AppSheet, it gets fixed, but the same error occurs again periodically and the app becomes unusable.

This error is exactly the same as the one described here:
https://discuss.google.dev/t/error-message-for-calendar-datasource/122419

When I contacted support, they told me, “Please try transferring the calendar owner to the app owner once.” I’m considering doing that, but as mentioned above, the calendar owner stores all of his appointments there, so he is reluctant to change the ownership from him to me.

I built the app about two years ago, and there were no problems back then. Now, about once every two months, the error suddenly appears without any clear pattern.

My questions are:
Is it not expected (by design/specification) to use a calendar table owned by a different person in an app owned by someone else? Depending on the answer, I may need to ask him to separate his work and private events into different calendars.

Also, I don’t want to create a new calendar because I once made a mistake in an automation setting and accidentally deleted all the schedules in his calendar.

If there is a better solution, please let me know.

2

Hello @suzukixxx,

Welcome back! I hope we will get to see you here more often. I noticed that in the discussion you shared, Djigi mentions he shared the calendar instead of transferring ownership so please find below the steps to do so I searched for information on how to do that and I found the following:

  1. Open Google Calendar on a computer. Sign in with the account that owns the calendar.
  2. Find the calendar list. On the left, under My calendars, hover the calendar you want to share. Click the three-dot ⋮ menu.
  3. Choose Settings & sharing. This opens a page with every sharing option in one place.
  4. Add individuals. Scroll to Share with specific people & groups, type an email or Google Group, and set a permission level: from read-only to full management. Click Send.
  5. Copy a link for other apps. In Integrate calendar, grab the Secret iCal or Public HTML URL.
  6. Paste it into Outlook, Apple Calendar, or a website widget for a live feed.

Note that if “public” or “external” choices are grayed out, your Workspace admin has restricted sharing. Ask IT to adjust domain settings or use an internal Google Group instead.

Protect private events. Even on a shared calendar, mark sensitive meetings “Private” so guests only see busy blocks, not details.

I hope this helps!

P.S. Let me know how it goes :slight_smile:

2 Likes
3

If the calendar works and then after few months it suddenly doesn’t and that happens again, it sounds the access token is expired. Therefore the reauthentication via sources solves it.

2 Likes
4

Thank you for your courteous reply.

At the moment, I (as the app owner) have calendar access permissions. Those permissions also allow me to “manage sharing.” Even so, I still can’t understand why this issue is happening.

As for what you mentioned — “5. Copy a link for other apps. In Integrate calendar, grab the Secret iCal or Public HTML URL.” — I hadn’t known about this until now, so I thought it would be worth trying. However, I’m not sure how to incorporate the Secret iCal into AppSheet.

5

Thank you for your reply.
Based on the error message, that does seem to be the case. However, given that this error didn’t occur before and that it happens intermittently, I’m looking for a better solution than having users report it each time and reloading the calendar every time it happens.

1 Like
6

One reason for the expiration could be: your organization’s IT guys have forced a security policy change like requiring 2FA or changed session lengths. Worth to check.

2 Likes