Friday, October 31, 2025
5 changes · master
Enhancements to existing features
The asset list view has been adjusted to show additional useful information while keeping some fields hidden by default. This gives users more flexibility to see relevant asset details without cluttering the standard view.
Original PR description
This PR adds some new fields to the assets list view and makes some fields `optional='hide'`. Task [link](https://www.odoo.com/odoo/project.task/5163529) task-5163529
VoIP users can now close error screens when the issue does not block their work. This makes it clearer that minor errors can be dismissed and helps reduce confusion during calls or softphone use.
Original PR description
When the error is non-blocking, a close button is now added to the error screen in order to indicate that the error can be removed. Task ID: [4891947](https://www.odoo.com/odoo/project/5778/tasks/4891947)
This update removes outdated invisible fields from several Odoo views across website, accounting, helpdesk, WhatsApp, and related modules. The change simplifies internal screen definitions and reduces maintenance overhead without changing day-to-day functionality for users.
Original PR description
Invisible field from views are useless since: see: https://github.com/odoo/odoo/commit/5639ed865c5a3b82bab25b0ecac28c68c02e93065639ed8 see: https://github.com/odoo/odoo/pull/137031
This update simplifies how website builder options are defined and shared across related builder components. It helps developers maintain website editing features more consistently, reducing future maintenance effort without changing the business-facing behavior.
Original PR description
The commit: 1. use static property to configure a builder option 2. introduce the concept of dependencies to access the plugin's shared in builder option 3. make a plugin context the same for Plugin,…
The commit:
1. use static property to configure a builder option
2. introduce the concept of dependencies to access the plugin's shared
in builder option
3. make a plugin context the same for Plugin, BuilderOption and
BuilderAction to have the same API in each class.
Before this commit, to define an option, we had to define a javascript
object that would contain the information of the option within the
`builder_options` resource.
```js
class MyPlugin extends Plugin {
resources: {
builder_options: [
{
selector: "div.selector",
template: "my.owlTemplate",
cleanForSave() {}
// ... other option props
}
]
}
}
// For a custom component
class MyPlugin extends Plugin {
resources: {
builder_options: [
{
selector: "div.selector",
template: MyCustomComponent,
cleanForSave() {}
// ... other option props
}
]
}
}
class MyCustomComponent extends BaseOptionComponent {
// ...
}
```
When building anything for the builder, there is 3 classes that are
important: `Plugin`, `BaseOptionComponent`, `BuilderAction`.
In practice, the option object defined in builder_options feels
strange. On the other hand, making the configuration of the option as
a static property of the component somehow feels simpler as everything
related to that option is defined in the same class.
```js
class MyPlugin extends Plugin {
resources: {
builder_options: [MyCustomComponent]
}
}
class MyCustomComponent extends BaseOptionComponent {
static template = "my.owlTemplate";
static selector = "div.selector";
static cleanForSave(context) {}
// ...
}
```
To have the same mental context in the 3 important class, they all
share the same API (`dependencies`, `dispatchTo`, `getResource`, ...)
(see `Editor.getPluginContext`)
To access a plugin shared method, it's now the same for `Plugin`,
`BuliderAction` and `BaseOptionComponent`:
```js
class MyCustomComponent extends BaseOptionComponent {
static selector = "mySelector";
static dependency = "myPlugin";
myMethod() {
this.dependencies.myPlugin.pluginMethod();
}
}
```
To access a resource, dispatch, ...:
```js
class MyCustomComponent extends BaseOptionComponent {
static selector = "mySelector";
myMethod() {
const resource = this.getResource('myResource');
}
}
```
Forward-Port-Of: odoo/enterprise#96515
Forward-Port-Of: odoo/enterprise#94102Payroll rule parameters now keep a visible history when key values or their start dates change. This helps payroll teams audit configuration changes more easily from the rule parameter record itself.
Original PR description
This commit adds native-style tracking for the fields `date_from` and `parameter_value` of the model `hr.rule.parameter.value` inside its parent model `hr.rule.parameter` that nests parameter value lines in its form view. For this purpose, a chatter was thus added to `hr.rule.parameter` form view. TaskID: 5176977