I’m using Google Calendar’s pack to create a table with all the events. However I don’t see how to add the current user’s calendar. I’d like to create a page where every user see their own calendar. Is this possible? I tried adding USER().Email as a formula but it didn’t work.
Additionally, I’d like to create a master view where a user can see different calendars, but I only see a way to add one calendar per table. Is that correct, is is not possible to add more than one calendar in the Event table?
When configuring the pack, you need to connect an account to it. This can be done in two ways: using a shared account or a private account.
Shared Account: One person (typically the admin, doc maker, or team leader) connects an account that is then used by all users of the doc.
Private Account: Each user connects their own account, allowing access to their individual data.
Based on your post, I assume you’re looking to use the private account option.
However, there are a few points I haven’t tested, so I’m unsure of the behavior. Hopefully, someone with more experience using this pack can provide additional insight:
Using the Pack’s Synced Table with Two-Way Sync:
If you use the table provided by the pack with two-way sync, I’m not sure how Coda handles different accounts. Ideally, the table should display only the events/calendars from the connected account of the specific user, but the behavior might differ. Testing this is straightforward—log in to Coda with two different accounts, configure the pack with private accounts, and observe how the table behaves.
Using Formulas to Manage Data:
If you use formulas, you may end up with one large table containing all events from all users. A button could trigger an action to fetch events for the current user and add them to the table. To manage this:
Include a People-type column that stores the user who added the events.
Use a filter formula, such as User() = [People column], to display only events for the current user.Note: While filtering the table by user provides some data separation, it is not a security feature. Users could potentially access all rows of the table.
EDIT: The sync table only accepts a shared account, so you likely cannot achieve what you want using the sync table. Instead, you’ll need to use the formula with a private account and accept the associated drawbacks.
For this, you can use the pack formula instead of the sync table (point 2 from my previous answer).
For example, you could create a button that uses the Calendars() and Events() formulas to retrieve calendars and events from each calendar, then add the data to another table.
However, there are two important considerations:
Security: As previously mentioned, this approach does not inherently secure the data. Users may still have access to rows from other users.
Manual Action: The button must be pressed manually. Automation cannot act on behalf of a user unless each user sets up and authorizes the action themselves.
Ok, so let’s see if I understood the approach correctly.
Thank you a lot for the detailed explanation!
One of the issues is that the sync size increases a lot quickly. This is for a team of 8 people, and the idea is to track the whole year.
Is the approach of just syncing the current month and retrieving the events into another table with a button correct? I understand this button should be performed per row (after each user categorizes the event).
I think in this case the shared would still work better than the private. I don’t fully understand how these work and why the table is only available with the shared. I’ll have to play a bit more with the pack.
Yes, you can do that. The pack formulas are used to retrieve calendars or events based on specific configurations (account, time range, permissions, etc.). These formulas are placed inside the action formula of a button, so every time you press the button, the action will run.
Within the same action formula, you need to program what to do with the information retrieved from the pack. In this case, we’re talking about adding the events to a table.
It’s important to note that there isn’t a direct link between the table and Google. The button acts as a gateway between the two. This means you’ll need to manually handle everything, such as avoiding duplicates and managing updates. Normally, there is an ID number associated with each element, which makes this much easier.
Not exactly per row, but each user needs to press the button regularly to update the table. The button will retrieve all calendars and events for that user within a specific time range and add them to a second table that contains all events from the last year (for example).
For this to work, the account connected to the Google Calendar pack must have access to all relevant calendars. For example, if you and I each have personal calendars, connecting your account as a shared account will not make my calendar available, as it exists only in my account.
A potential solution is to use a third account specifically for “aggregation.” All users can share their relevant calendars with this account directly in Google, and then this shared account can be connected to the Coda pack.