day_selection

day_selection is a small subclass of the standard selection widget that solves a calendar problem: a day of month dropdown should not offer the 31st when the month is April, or the 30th when it is February.

The widget reads a second field on the same record, named by the month_field attribute, and filters its own selection entries down to the days that month actually has. The cutoff is computed with new Date(2020, month, 0).getDate(), deliberately anchored to 2020, a leap year, so February offers days 1 through 29 rather than 28.

Everything else, rendering, saving, the dropdown itself, is inherited unchanged from the selection widget, and the month field is registered as a field dependency so the record always loads it.

The widget exists because HR data entry mistakes here are expensive. An accrual plan that grants days on the 31st of a 30 day month silently skips allocations, and nobody notices until an employee's balance is short. Trimming the dropdown makes the invalid configuration impossible to type instead of merely discouraged.

The same pattern applies to any custom model with a month plus day pair: contract anniversary dates, recurring billing days, maintenance schedules. Reusing this widget (or its pattern) beats validating after the fact with constraints.

The biyearly carryover configuration from hr_leave_accrual_views.xml, two day fields each bound to their own month:

<field nolabel="1" name="first_month_day" widget="day_selection"
       month_field="first_month" placeholder="select a day"
       required="frequency == 'biyearly'"/>

<field nolabel="1" name="second_month_day" widget="day_selection"
       month_field="second_month" placeholder="select a day"
       required="frequency == 'biyearly'"/>

For your own model: make the day field a selection with keys 1 to 31, the month field a selection whose values are month numbers, and bind them with the attribute.

Two source details determine whether the filter works on custom models:

The month value must be numeric. The filter runs new Date(2020, month, 0), where JavaScript treats the value as a month index for which day 0 yields the previous month's last day. Odoo's accrual month selections store numeric strings (1 through 12), which coerce cleanly; a month selection storing keys like jan would make every comparison false and hide the entire day list.

The comparison is on selection keys. The filter keeps entries where option[0] <= lastDay, comparing the day field's selection keys against the computed day count. Your day selection keys must therefore be the day numbers themselves, as hr_holidays defines them.

The leap year anchor is a quiet product decision: by computing February against 2020 the dropdown always offers the 29th, and Odoo's server side handles the day in non leap years. If your business rule is stricter (never allow 29), this widget will not enforce it.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The changes below are read from the public development branch and are not final until release.

The widget survives unchanged in behavior. The diff is purely mechanical: the props declaration migrates to the new useProps and selectionFieldProps framework style, with the same required monthField and the same 2020 anchored filter. We will re verify this page against the released branch after the launch.