Odoo Changelog — 2024-02-01

Thursday, February 1, 2024

1 change · master

Improvements(1)

Enhancements to existing features

[IMP] planning: make planning a planning app (research)

Enterprisemasterplanningproject_timesheet_forecastsale_planningHigh impact

Planning shifts are changed to represent the exact working periods rather than broad multi-day blocks that are later adjusted against schedules. This makes planning clearer and overlap checks more reliable, with a new split option to turn long shifts into schedule-based working segments.

Original PR description

Currently, it is possible to create a shift for, say, a whole week. When your shift expands from su 00:00 to sa 23:59, we find its intersection with your schedule and deduce the allocated time.…

Currently, it is possible to create a shift for, say, a whole week. When your shift expands from su 00:00 to sa 23:59, we find its intersection with your schedule and deduce the allocated time. Typically, 40h.

In my opinion, a planning app should be used to know exactly when you will be working on what. So, in an overall functional perspective, it doesn't make a lot of sense to have a 168h long shift when you work 40h a week.

Now, from a technical perspective, I also think the current state complexifies the code. Say that you want to check if 2 shifts are overlapping (which, obviously, is one of the main questions you ask yourself when planning) -for now, let's forget about `allocated_percentage`. In theory, it should be trivial. However, when the start/end to consider is in fact the start/end of the work interval that is inside the shift (let alone the lunch break), what could have required 1 LOC now requires to search in other tables, asking again, essentially, "when is the resource actually working?". And if you have to do it in a SQL query (see `_compute_overlap_slot_count`), well you just don't because it is too complex,
and you end up with an uncorrect result.
The same question is asked and answered not very elegantly when trying to assign shifts automatically (see `auto_plan_ids`).

My sense is that we should keep it simple and stupid: `allocated_hours = (end_datetime-start_datetime) * allocated_percentage` Now, in order not to force the user to create 10 shifts for a week where is used to only create one of them, I suggest adding a button "scissors" on the from view that instead of saving one big shift, would fragment it once and for all into the 10 desired shifts, taking into account the resource's schedule.

Technical downsides:
- (Way) more records in DB.

Functional downsides:
- I think Odoo consultants are used to creating, say, 3 one-week shifts whose sum of percentages is 100%. With this commit, their gantt view will be clogged with 6 shifts per day. But again, my point is: it doesn't sound like the proper way to use a planning app.
- If you have a one week shift, and you fall sick on tuesday, we now have to reassign all the following shft, rather than splitting it and reassigning the 2nd part.

task-?

#planning#shifts#gantt#scheduling

Currently, it is possible to create a shift for, say, a whole week. When your shift expands from su 00:00 to sa 23:59, we find its intersection with your schedule and deduce the allocated time. Typically, 40h. In my opinion, a planning app should be used to know exactly when you will be working on what. So, in an overall functional perspective, it doesn't make a lot of sense to have a 168h long shift when you work 40h a week. Now, from a technical perspective, I also think the current state complexifies the code. Say that you want to check if 2 shifts are overlapping (which, obviously, is one of the main questions you ask yourself when planning) -for now, let's forget about `allocated_percentage`. In theory, it should be trivial. However, when the start/end to consider is in fact the start/end of the work interval that is inside the shift (let alone the lunch break), what could have required 1 LOC now requires to search in other tables, asking again, essentially, "when is the resource actually working?". And if you have to do it in a SQL query (see `_compute_overlap_slot_count`), well you just don't because it is too complex, and you end up with an uncorrect result. The same question is asked and answered not very elegantly when trying to assign shifts automatically (see `auto_plan_ids`). My sense is that we should keep it simple and stupid: `allocated_hours = (end_datetime-start_datetime) * allocated_percentage` Now, in order not to force the user to create 10 shifts for a week where is used to only create one of them, I suggest adding a button "scissors" on the from view that instead of saving one big shift, would fragment it once and for all into the 10 desired shifts, taking into account the resource's schedule. Technical downsides: - (Way) more records in DB. Functional downsides: - I think Odoo consultants are used to creating, say, 3 one-week shifts whose sum of percentages is 100%. With this commit, their gantt view will be clogged with 6 shifts per day. But again, my point is: it doesn't sound like the proper way to use a planning app. - If you have a one week shift, and you fall sick on tuesday, we now have to reassign all the following shft, rather than splitting it and reassigning the 2nd part. task-?