# Prelude to autumn-round-vaccinations and appointments-2.0 - considerations

Hi,

I've been thinking a lot about what we're about to do with **Autumn-round-vaccinations** and **product-time restrictions with appointments**.

To my mind there are 2 major problems to be solved on the road to complete these two tasks:
- A. CalendarEntries have to be source of truth on availability of all SPs (what gets in the way is Planday being source of truth for lower-tier med staff (non-doctors))
- B. 1-to-1 relationship **booking<>service_provider**

I played a bit with Planday API and study it's docs, and here's what i found:

## Planday 2-way integration

### Objective
To sync Planday with HJ Platform in such way so that CalendarEntry objects could be the ultimate source of truth on all SPs availability.
* To do it, we need to establish 2-way sync with planday , at least for Clinic staff (who, right now, do not use CalendarEntries).
* 1-way integration simply won't do - it'd be risky and very confusing if changes in the platform wouldn't also end up in Planday.

### Planday -> Platform

Since, unfortunately, there's webhook functionality in Planday API, there's no way to react on Create/Update/Delete events on Planday directly.
We gonna have to fetch the list of Planday Shifts (equivalents to CalendarEntries) by modifiedFrom :( like every 5 minutes for instance, and create/modify corresponding CalendarEntries on HJ Platform.

CalendarEntries gonna need 2 more columns:
- splittable:bool, default: true (but for Planday, false <-- we don't need them to get split to 1h-ones on save! and this is currently the case with CEntries longer than 1h)
- last_change_origin:string (NULL or 'planday') - indicates where did the change went from - critical to prevent limbo of changes Planday->HJ->Planday again ...
- external_id:bigint to keep PlandayId of a corresponding Planday entry

### Platform -> Planday

there are necessary endpoints in Planday API to create/update/destroy Planday record after corresponding action on HJ platform calendar_entry object, provided we know it's planday_id (external_id)

### Important considerations
- We gonna need to make sure every enabled SP has a planday_id (48 of 92 active SPs is missing them) we gonna need someone to manually fill PlandayIDs for all (enabled) SPs (I can do that, if noone is to be found)

- is there a staging env for Planday integration testing - seems, the answer is no.

<!-- - **<IMPORTANT>** The major problem is that the integration would have to work differently for doctors and differently for other staff. Here's why:
- Staff is adding availability in Planday in X-hour-long ranges -> good! And we could do the same,... but
- we CANT do that for Doctors, because their CalendarEntries, even if they were X-hour long, will be chopped to 1-hour slots on save! (to be shown later nicely in the calendar) -->

### :warning: ALTERNATIVES to choose from :warning:

1. Go ahead with planday 2-way integration
<!-- 2. Stop splitting doctors calendar entries in 1h intervals (but that may get tricky, also business wise, would require re-learning etc.) and implement integration in a more concise, less quirky fashion -->
2. DITCH Planday and planday integration altogether, and recreate it's basic functionality in the platform, and force ALL - doctor or not - to define availability through our platform (a bit of a bumpy road, but it was planned to be done anyways) [maybe daily cal from this package would be a starting point ?https://www.npmjs.com/package/react-awesome-calendar?activeTab=readme]

Right now i'm kinda thinking that both options require roughly the same amount of time