v5.x no longer works with hidden Birthday calendar

[sbrocket]

Steps to reproduce

What action or series of actions is the cause of the issue?

1. Hide the Birthday calendar at calendar.google.com (3-dot menu -> Hide from list)
2. Upgrade to or do new setup of v5.x of ContactsEventsNotifier

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.

[sbrocket]

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).

[plainerman]

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 :)

[plainerman]

@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!

[sbrocket]

Yep I can send one, just been busy this week.

[plainerman]

@sbrocket any updates? No worries if you didn't find the time yet :)

[plainerman]

Any updates on this?

[draxx31]

Hi, I get the same behavior.