so_line_field

On a billable timesheet line, the Sales Order Item column decides which order line the logged hours are invoiced against. Odoo could render it with the plain many2one widget, and visually you would not see any difference. so_line_field exists for one reason that is invisible on screen: it records that a human made the choice.

The component wraps the standard Many2One and overrides only the update handler. When the value changes to a different sales order item and the record's is_so_line_edited flag is not yet set, the widget sets that flag to true in the same edit. Everything else, the dropdown, the search, the create options, comes straight from the many2one base via buildM2OFieldDescription.

There is also a small readonly nicety added in 19.0: when the field is empty and readonly, the template prints the field's falsy value label in muted text, which is why non-billable lines read as a label rather than an empty cell.

Timesheet-to-invoice mapping is where services companies leak revenue. Odoo computes a default sales order item for each timesheet line, but project leads reassign hours between order lines all the time: a support block here, a development package there. The business problem is what happens afterwards, when the project or task changes and the defaults are recomputed. Should the system overwrite the line a human deliberately set?

The is_so_line_edited flag this widget maintains is Odoo's answer: it marks the line as manually assigned so later recomputations can leave it alone. For your team this means two things. First, corrections made by a project manager stick. Second, if you build custom timesheet views and use the plain many2one widget instead of this one, that protection silently disappears, and users will report that "Odoo keeps changing my sales order item". That ticket is almost always a missing widget, not a bug.

How core uses it (timesheet list)

<field name="is_so_line_edited" column_invisible="True"/>
<field name="so_line" widget="so_line_field"
       options="{'no_create': True, 'no_open': True}"
       placeholder="Non-billable"
       invisible="not allow_billable"/>

Three details worth copying: the hidden is_so_line_edited column that receives the widget's flag write, no_create so users cannot invent order lines from a timesheet, and the placeholder that labels empty lines as non-billable.

Reusing it on a custom timesheet view

<field name="is_so_line_edited" invisible="1"/>
<field name="so_line" widget="so_line_field"
       options="{'no_create': True, 'search_threshold': 2}"/>

The flag field must be present, even invisible, wherever you place the widget. search_threshold is worth adding on databases with thousands of order lines so the dropdown does not query on every focus.

The entire delta over a plain many2one is one condition in the update handler, and reading it precisely avoids two wrong assumptions.

The flag is set once, never cleared. The widget writes is_so_line_edited: true only when the flag is currently false and the new item differs from the old one. Nothing in the widget ever resets it to false, so clearing the manual mark is a server-side or data operation, not something a user can do from this field.

The flag write happens in the same record update as the value. Both go through record.update(), so they save together. That is also why the flag field has to be loaded in the view: updating a field the view does not know about is not possible, and core marks it column_invisible rather than leaving it out.

The widget does not compute anything. Which sales order item a timesheet line gets by default is decided by the server. The widget's job ends at flagging the manual override so those computations can respect it.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The notes below are read from the public development branch, which is unstable and can change until release; we re-verify this page against the shipped version.

For this widget the development branch shows no behavior change. The file is rewritten onto the new Owl props system (useProps and many2OneFieldProps replace the static props spread), the update handler and the is_so_line_edited logic are untouched, and the registration name stays so_line_field. Views carry over; JavaScript patches against the component class will need review.