Wednesday, June 26, 2024
1 change
Code cleanup and technical improvements
Gantt views now load unavailability information together with the main schedule data instead of making extra back-and-forth requests. This streamlines scheduling screens across appointments, planning, HR, projects, manufacturing, and related areas, improving maintainability and likely responsiveness without changing the core user workflow.
Original PR description
We refactor the way unavailabilities are fetched in the gantt view. The main thing we want is to fetch unavailabilities along the main gantt data (groups and records). Indeed, we think it is bad to…
We refactor the way unavailabilities are fetched in the gantt view. The main thing we want is to fetch unavailabilities along the main gantt data (groups and records). Indeed, we think it is bad to have to fetch groups, create rows, send rows to the server, enrich those rows server side, send the enriched rows back. Moreover the API of gantt_unavailability was bad and forced most overrides to traverse the rows, convert the start_date, stop_date,...
So here we have make gantt_unavailability private, rationalize its API to make it a bit closer to the API of gantt_progress_bar, and call it directly in get_gantt_data.
Since the old API did allow to enrich a single row (e.g. in the case grouby=[]) or a row with a corresponding res_id = False, we still allow here to send unavailabilities for those cases in the following way:
```py
unavailabilities = {
'__default': { False: global_default_unavailabilities, ... },
<field_name>: { False: default_unavailabilities, ... },
...
}
```