button_new_contract

An employee's terms change over time, and Odoo models that as versions: a new contract is a new version starting on a date, with the previous one closing before it.

Creating one is therefore not a simple record creation. The previous version has to be in a state that allows closing, and the new date must not collide with a contract that already covers it.

This widget wraps both checks around a date picker. Click, and it saves and asks whether the current version is finished; pick a date, and it asks whether that date is free; only then does it create the contract and load it.

Overlapping contracts are one of the more expensive HR data errors, because payroll consumes them and the mistake surfaces as a payment. Two checks before creation, both server side, is a proportionate amount of caution.

The design point worth borrowing is where the rules live. Contract validity is a Python concern, and the widget's job is only to ask at the right moments. Any customization to those rules belongs on the model, not here.

Placing it

<widget name="button_new_contract"/>

No attributes. It reads the employee and version from the record.

The sequence

save -> check current version finished
     -> pick a date
     -> check no existing contract on it
     -> create -> reload with the new version

Two checks, both server side.

The reload context

{ ...search context, version_id: new id }

Which is what makes the form show the new contract.

The reload at the end is the part worth understanding, because it is not a plain refresh.

After creating the contract the widget saves again, then reloads the model with the existing search context plus the new version identifier. That extra context key is what tells the employee form which version to display, so the user lands on the contract they just created rather than back on the old one.

The two checks are ordinary server calls whose only purpose is to raise. Neither returns a value the widget uses: if the rule is violated the call raises and the sequence stops with the server's own message, which is why there is no error handling in the file.

The picker is configured as date only and its apply handler guards against an empty date, so dismissing the picker does nothing rather than attempting a creation with no date.

One nuance in the first check: it is asked about the current version identifier, not the employee. That is deliberate, because the question is whether the version being replaced can be closed.

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 this page after the release.

A guard around the save. The development branch sets a flag on the record before saving and clears it afterwards, which suppresses a contract end-date dialog that would otherwise interrupt the sequence. The picker target also moves to a reference rather than a fixed identifier.