-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v5.x no longer works with hidden Birthday calendar #181
Comments
Also, it's easy enough for me to just swap out that logic in validateSettings for my own script...I'm mainly filing this for the benefit of others (and for myself in X years when I inevitably update this again and forget that I made a change). |
Hey @sbrocket, thank you very much for taking the time to raise your first issue on this repo! I see your point, and think you are correct that we should support this. And with your description, I also don't think that it makes much of a difference where we hardcode what. Unfortunately, I am swamped the next few weeks. As you already have working code, would you mind creating a PR with it? It would allow me to merge / fix the issue sooner :) |
@sbrocket I just wanted to check up again, whether you want to create a PR, so it is easier for me to plan accordingly? Either way, thank you for raising this issue! |
Yep I can send one, just been busy this week. |
@sbrocket any updates? No worries if you didn't find the time yet :) |
Any updates on this? |
Hi, |
Hello, the issue is comeback from today for me. Any news? |
Issue showed up for me as well today for the first time. I think it's fixed by the change suggested by @sbrocket or at least it causes 2187,2197c2187,2188
< // Get the calendar ID from Google Calendar.
< calendarId = CalendarApp.getAllCalendars().filter(function (cal) {
< // All the valid calendar IDs contain this string.
< return isIn('#[email protected]', cal.getId());
< }).map(function (cal) { return cal.getId(); });
<
< if (calendarId.length > 0) {
< settings.user.calendarId = calendarId[0];
< } else {
< log.add('Could not find the birthday calendar! Please check that you have enabled it!', Priority.FATAL_ERROR);
< }
---
> // Hardcode the calendar ID for the address book
> settings.user.calendarId = "addressbook#[email protected]"; I'll just submit a PR I suppose since this issue is a couple years old. |
Hardcode the calendar ID "addressbook#[email protected]" as suggested by @sbrocket in the issue GioBonvi#181.
Works like a charm, thank you @vEnhance |
nvm my test date was to far in the past |
Steps to reproduce
What action or series of actions is the cause of the issue?
Expected behavior
ContactsEventsNotifier should still be able to find the Birthday calendar since it still exists. It's just hidden from the Calendar UI.
Current behavior
"Could not find the birthday calendar! Please check that you have enabled it!" fatal error log results.
Context
Discovered while updating from an old v4.1.0 setup that used an
eventSource
setting of "CONTACTS_ONLY" to v5.0.2.Extended description
v4.x had an eventSource setting related to Google+ support which was understandably removed in v5.x. However, both the old eventSource "DEFAULT" and "CONTACTS_ONLY" settings were unrelated to Google+ and had different behavior. The former is the current logic in v5.x that attempts to grab a list of all calendars using the
CalendarApp.getAllCalendars()
function and filters the list based on a suffix of "#[email protected]", whereas "CONTACTS_ONLY" would simply use a hardcoded calendar ID of "addressbook#[email protected]".Unfortunately,
CalendarApp.getAllCalendars()
does not seem to return calendars that have been hidden from the Calendar UI list. Hiding the Birthdays calendar to declutter your calendar list is not an unreasonable thing to do when you already have something like ContactsEventsNotifier sending you emails in advance of people's birthdays.Possible solution
It's unclear to me whether or why it is necessary or preferrable to use the old v4.x "DEFAULT" logic that grabs all calendars and filters that list now that Google+ is gone, so I would propose just switching to using the hardcoded ID like "CONTACTS_ONLY" used to do. The current logic does not necessarily seem any more future proof than a hardcoded ID. Google could change the calendar ID to no longer end in "#[email protected]" just as easily as they could change the "addressbook" prefix. Neither change seems terribly likely anyway.
If someone is attached to the "grab all + filter" logic then I suppose a new setting could be added to provide a hardcoded calendar ID instead, but it's not obvious to me that there is any benefit to that.
The text was updated successfully, but these errors were encountered: