accrual_levels

An accrual plan is a set of milestones: after so long, an employee starts earning so much time off, at a given frequency, with rules about what happens to unused days. Written as a table of technical columns it is close to unreadable, and it is exactly the configuration people get wrong.

This widget replaces that table. It renders each milestone as a card on a vertical timeline, with a label on the left saying when the milestone starts and a sentence on the right saying what it does. The sentence is assembled in the browser from the milestone's fields, so it always describes the real configuration rather than a stored description.

Cards are clickable and open the milestone in a full dialog. A trash icon on each row removes it, and a button at the bottom of the timeline adds a new one. There is no inline editing at all: the timeline is a reader, and every change goes through the dialog.

Accrual rules are where time off policy meets payroll, and a misconfigured plan is expensive in both directions. Employees who accrue too fast take leave they have not earned; employees who accrue too slowly complain, and the correction is retroactive. Anything that makes the rule readable before it goes live pays for itself.

The sentence rendering is the whole value here. A reviewer who does not know Odoo can read a card and confirm the policy, which means the HR lead can sign off on the configuration rather than approving a screen they do not understand. In a rollout, that shortens the accrual conversation from several meetings to one.

Where it needs care is the save prompt. Because milestones open in a dialog, the plan itself can have unsaved edits when you click a card, and the widget stops to ask what to do. Users who dismiss that dialog without reading it are the usual source of an accrual plan that looks right on screen and behaves differently in practice.

The core usage

<field name="level_ids" widget="accrual_levels"
       invisible="not level_ids"/>

No subview and no options. The invisible guard lets the form show an empty-state panel with its own create button when the plan has no milestones yet.

The fields the sentences need

<field name="carryover_date"/>
<field name="carryover_day"/>
<field name="carryover_month"/>
<field name="level_ids" widget="accrual_levels"/>

Only the first of these is declared as a dependency by the widget. Keep all three in any custom form.

The empty state core pairs with it

<div class="o_view_nocontent" invisible="level_ids">
  <button name="action_create_accrual_plan_level"
          type="object" string="Create a milestone"/>
</div>

The widget hides itself when the relation is empty, so the form supplies its own guidance instead of an empty timeline.

The data path is unusual. A relational field widget normally renders from the records the view already loaded. This one uses a record observer to call a plain read on the milestone model for the current ids, and renders from that result. The practical consequence is that the timeline shows server-side values, including fields the subview never declared, which is what lets the sentences reference a dozen fields without a subview at all.

The same observer tracks which ids were present when the form opened. Any milestone whose id was not in that first set is rendered with a New badge and a highlighted marker, so after creating one you can see which card you just added. It is a small touch that only makes sense once you know the widget keeps that original id list.

Editing goes through a two-step. Clicking a card checks whether the plan record is dirty. If it is, a confirmation dialog offers to save the changes first or to keep the old version, and only then calls a server method that returns the action for the milestone form. Creating uses a different server method with no id. Both are opened with the plan's id in context, and the form reloads the whole root record when the dialog closes.

Deleting is deliberately not symmetric with that. The trash icon removes the record from the loaded relation in the browser and nothing else; the deletion is only written when the plan itself is saved. So a user who deletes a milestone and then discards the form gets it back, which is the safer default for policy data.

One more detail worth knowing for translations: the day and month names in the sentences are produced by the client date library using the user's language from context, not by the server, so they follow the interface language rather than the record's language.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The development branch is unstable and this may still change; we re-verify the page after release.

No behavior change. The development branch differs only in formatting and in the migration from the older reactive-state helper to the new one. The server methods it calls, the field dependency, the save prompt and the local delete are all identical.