Some ideas to improve the experience of developing this tool:

• Add a dry run mode: runs normally except that it logs what should be written to Google Calendar instead of actually writing it.
• Add a flag-as-test mode: runs normally but flags events written to Google Calendar as tests (by adding [TEST] in the summary for example)
• Allow for the target calendar to be overridden using a calendar ID in an environment variable so that all events are written to it instead of the primary calendar of any given user. This target calendar must be writeable for all users.
• Extract a pure function from the current code base that can map a collection of Alibeez leaves to a collection of { action, eventId, eventBody } triplet so that testing this mapping becomes trivial and modifying it is safer.

Currently, this connector generates meetings for the duration of the leave with the "Absence" label.
It would be better to have a "leave" generated, since Google Agenda now supports it.

According to https://developers.google.com/calendar/api/v3/reference/events/insert?hl=fr
it would be as simple as setting eventType to outOfOffice.

However, a data migration may be required for all users, since it will impact the already defined leaves.

Set the status to vacation on Slack

After an incremental sync, the connector saves the current date-time and uses it on the next sync to filter the leaves on their update date. The format of the date-time used by the connector is ISO 8601 with a trailing Z to denote the use of UTC, however Alibeez seems to still interpret the date-time as a local one. This means, for the case of France in the summer, that the connector pulls 2-hour worth of leaves that were already pulled at the last sync.

The proposed solution is to save the update date of the last leave that was sync'd, instead of the current date-time.

The Google Calendar API allows to pull the color palette of a Calendar, so it would be possible to ask the user for their preferred color. Suggested by @patou.

• document environment variables (see for example https://github.com/Zenika/platon/blob/master/.env.example)
• describe how to init a user
• describe how authentication to Google works
• inform that an Alibeez test instance is available to test the connector

This is required to make the connector work for all employees. This could be implemented either directly in the connector, or through a proxy such as https://github.com/Zenika/multibeez.

Use case: I'd like all my leaves to show up in the calendar of my personal Google account or other professional Google accounts.

Solution: have a settings page where I can add/remove multiple users, which would be invited to the events generated by the connector.