Odoo Changelog — 2023-11-17

Friday, November 17, 2023

3 changes · master

Refactoring(3)

Code cleanup and technical improvements

[REF] web, *: Field component use field domain

Coremastermailweb

Field components now automatically use the filter rules already defined in the underlying business model when no separate filter is provided. This reduces duplicate configuration and makes field behavior more consistent when reused outside standard views.

Original PR description

The goal of this commit is to simplify the use of fields components with
a props domain (for example, x2ManyField, StatusBarField, ...) outside
a view and therefore outside the Field component. To do this, we'll use
the domain defined on the field (in python) if we don't pass domain props.

Before this commit, fields components with a domain props (x2ManyField, StatusBarField, ...)
used "[]" as the default value for the domain if we don't pass a domain props.

After this commit, if no props domain is passed or if the props domain is
a function returning no value, the default value will be the evaluated
domain defined for the field in python (record.fields[fieldName].domain).
If it doesn't have one, like before we will use "[]".

#fields#domains#consistency

[REF] mrp: remove is_done field

PR #104971

Coremastermrpmrp_subcontracting

An unused internal field related to manufacturing stock movements has been removed. This simplifies the manufacturing codebase and related views without expected changes to day-to-day user workflows.

Original PR description

There's no real use to the `is_done` field on `stock.move` so we're removing it 
task 2648449


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#manufacturing#cleanup#stock-moves

[REF] web: reduce number of useless try/catch

PR #142486

Coremasterweb

This change reduces unnecessary error handling during web context evaluation, such as when opening forms. It mainly improves developer troubleshooting by preventing avoidable caught errors without changing business workflows.

Original PR description

Before this commit, whenever we evaluate a partial context (for example, when opening a form view), we would do a large number of try/catch, with many of them resulting in an error.

This is because the context string represents an object with many field values, which are not in the evaluation context. The purpose of the evalPartialContext is to get the static values from the context. But these errors are annoying if we are debugging and have a break on caught exception setting on, which is usually what i do.

So, this commit improves the situation by avoiding the try/catch in some cases where we know that the operation will fail anyway. This is a heuristics, but it basically completely solves the issue in most cases.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#debugging#performance#web

The goal of this commit is to simplify the use of fields components with a props domain (for example, x2ManyField, StatusBarField, ...) outside a view and therefore outside the Field component. To do this, we'll use the domain defined on the field (in python) if we don't pass domain props. Before this commit, fields components with a domain props (x2ManyField, StatusBarField, ...) used "[]" as the default value for the domain if we don't pass a domain props. After this commit, if no props domain is passed or if the props domain is a function returning no value, the default value will be the evaluated domain defined for the field in python (record.fields[fieldName].domain). If it doesn't have one, like before we will use "[]".

Before this commit, whenever we evaluate a partial context (for example, when opening a form view), we would do a large number of try/catch, with many of them resulting in an error. This is because the context string represents an object with many field values, which are not in the evaluation context. The purpose of the evalPartialContext is to get the static values from the context. But these errors are annoying if we are debugging and have a break on caught exception setting on, which is usually what i do. So, this commit improves the situation by avoiding the try/catch in some cases where we know that the operation will fail anyway. This is a heuristics, but it basically completely solves the issue in most cases. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr