Context
hr_shift structurally assumes one hr.shift.planning.line per employee per day: _generate_shift_lines creates exactly one line per weekday, the assignment kanban maps one template to that line, and days_data/state computations rely on that uniqueness.
This fits many teams, but not two common scheduling realities:
- Split shifts: home-care and cleaning organizations commonly schedule 7:00-11:00 + 16:00-20:00 on the same day for the same employee.
- Double shifts: 24/7 residential facilities occasionally need an employee to cover two contiguous shifts (day + evening).
What we considered
We maintain a module suite on top of hr_shift (coverage rules, open-shift claims, swaps, replacement cascades — pending the 19.0 migration in #38). We considered relaxing the one-line-per-day assumption in an extension module, but concluded it would fight the base module: line generation, the day-colored kanban cards (days_data serialized field), conflict detection and downstream logic all assume day uniqueness. An extension would be fragile against upstream evolutions.
Proposal (for discussion)
- Make the day-line relationship explicitly 1-N: keep generating one line per day by default, but allow adding extra lines on a day (new
action_add_extra_line + relaxed constraints).
- Conflict detection becomes overlap-based (template start/end times) instead of day-based.
days_data/kanban render a day as a set of templates rather than a single color.
- Related fix in the same area:
duration_hours is currently negative for shifts crossing midnight (_compute_shift_time combines start and end on the same date) — any overlap-based conflict detection needs that fixed first. We can submit a separate PR for it.
Would the maintainers be open to this direction for 19.0 (or master)? We are happy to implement and test it upstream — we'd rather build it here than diverge.
🤖 Generated with Claude Code
Context
hr_shiftstructurally assumes onehr.shift.planning.lineper employee per day:_generate_shift_linescreates exactly one line per weekday, the assignment kanban maps one template to that line, anddays_data/state computations rely on that uniqueness.This fits many teams, but not two common scheduling realities:
What we considered
We maintain a module suite on top of
hr_shift(coverage rules, open-shift claims, swaps, replacement cascades — pending the 19.0 migration in #38). We considered relaxing the one-line-per-day assumption in an extension module, but concluded it would fight the base module: line generation, the day-colored kanban cards (days_dataserialized field), conflict detection and downstream logic all assume day uniqueness. An extension would be fragile against upstream evolutions.Proposal (for discussion)
action_add_extra_line+ relaxed constraints).days_data/kanban render a day as a set of templates rather than a single color.duration_hoursis currently negative for shifts crossing midnight (_compute_shift_timecombines start and end on the same date) — any overlap-based conflict detection needs that fixed first. We can submit a separate PR for it.Would the maintainers be open to this direction for 19.0 (or master)? We are happy to implement and test it upstream — we'd rather build it here than diverge.
🤖 Generated with Claude Code