Daily updates from Odoo
Tuesday, October 7, 2025
5 changes · saas-18.4
Enhancements to existing features
The Brazilian AvaTax product form now shows “LC116 Code” instead of “Mercosul NCM Code” when configuring services. This reduces confusion by using the correct terminology for service tax codes while keeping product code labeling unchanged.
Original PR description
Purpose:- - In Brazil, NCM is a code that has an acronym to specify the Mercosul Common Name for products, and for services, the right name is LC116 (Complementary Law 116), which specifies the federal code for a service. - But we have the same field `l10n_br_ncm_code_id` to configure both NCM for goods and LC116 for services and the same table can be used for both the cases. - So while configuring fiscal information for a service, user don't understand why it still shows the NCM label instead of LC116. Before this commit:- - Label `Mercosul NCM Code` was displayed for services confusing users. After this commit:- - Label `Mercosul NCM Code` is replaced with `LC116 Code` only for services. - Tooltip is also improved for better understanding. task-5096435 Forward-Port-Of: odoo/enterprise#96228 Forward-Port-Of: odoo/enterprise#95404
Bank reconciliation now creates the accounting entry as soon as an XML file is uploaded. This lets the imported transaction details be linked directly to the bank statement line, making reconciliation smoother and more complete.
Original PR description
When uploading a xml from the bank rec widget, the move will be created directly so we can put the move lines in the bank statement line. task-5107112 Forward-Port-Of: odoo/enterprise#95345
This update streamlines how developers configure website builder options, making related settings easier to keep together and reuse. It mainly affects appointment, online booking, and rental website features, helping future improvements be delivered more consistently with limited direct user impact.
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');
}
}
```The website HTML builder now uses a cleaner internal structure for configuring editing options and sharing functionality between builder components. This makes future website editing features easier to build and maintain, with little direct impact on end users.
Original PR description
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. See https://github.com/odoo/odoo/pull/220746
This update adds automated checks for appointment booking flows, including capacity handling, availability, cart bookings, invoice confirmation, and final event creation. These tests help reduce the risk of booking errors and improve reliability across appointment sales and payment scenarios.
Original PR description
\* = website_appoinment_sale, appointment_account_payment Add tests to ensure correct behaviour for the various scenarios. The following tests are added: - Users/resource's capacity computation when manage capacity is on and off. - Unavailability computation of users/resources in the `calendar.event`. - Check the bookings of user/resource in the cart for the availability after the invoice is confirmed. - Creation of the actual event when the booking from the cart is confirmed. Task-4919317