Friday, October 3, 2025
26 changes · 19.0
Enhancements to existing features
Point of Sale now blocks keyboard-based order line changes while a popup is open, such as customer selection, notes, or coupon dialogs. This reduces accidental order changes and makes checkout interactions safer and more predictable for staff.
Original PR description
Before this commit: - Even when a popup (e.g., customer selection, note, coupon) was open, unfocused keyboard inputs could still update orderline values. After this commit: - Orderline editing via keyboard is disabled whenever a popup is active. - Prevents unintended changes and ensures a safer user flow in POS. Task-5033716 Forward-Port-Of: odoo/odoo#229479 Forward-Port-Of: odoo/odoo#226300
VoIP call handling has been improved so each active call keeps its own state instead of sharing one global state. This matters because attended transfers can involve multiple simultaneous call sessions, and the change reduces the risk of calls being mixed up or affected by timing issues.
Original PR description
The original VoIP code was written under the assumption that there would only ever be one session at a time. Consequently, much of the session state was stored in a global object called the UserAgent. However, Odoo 19 implemented an attended transfer in VoIP, creating situations in which two sessions occur simultaneously. For this reason, the asynchronous code should no longer update session properties stored on the global UserAgent, as the session may have changed in the meantime, which could lead to race conditions. This commit moves some logic from the UserAgent to the Session, and ensures all callbacks are properly mapped to the relevant session.
Resolved issues and error corrections
This fix prevents protected or non-editable links from being deleted when users paste text over their label. It helps preserve website menu items and other locked content, reducing accidental content loss while editing.
Original PR description
When the label of a link is fully selected and the user pastes some text, the link is removed. It was removed even if the link was in a `contenteditable=false` or was unremovable. This commit only…
When the label of a link is fully selected and the user pastes some text, the link is removed. It was removed even if the link was in a `contenteditable=false` or was unremovable. This commit only attempts to remove the link element after checking these conditions. It also only selects the link in the `before_paste` handler, and lets the normal paste logic remove it. Steps to reproduce (after 18.4, where it was noticed): - Copy some simple text - Open website builder - Select completely the label of a menu in the header - Paste - Bug: the menu item is removed, and replaced with simple text Steps to reproduce (in 18.0 and later): - Open "To-Do" app - Add a link in the middle of a line of text - With inspector, edit html to put `contenteditable="false"` on the container of the line, and `contenteditable="true"` on the link - Select completely the label of the link in the document - Paste some text - Bug: the link is removed, and the clipboard content is inserted after the non editable element task-5110141 Forward-Port-Of: odoo/odoo#229558 Forward-Port-Of: odoo/odoo#228223
The checkout now blocks carts from combining one-time purchases with subscription products and shows a warning when customers try. This prevents confusion where one-time items could appear as recurring subscriptions, helping customers better understand what they are buying.
Original PR description
**Version:** - saas-18.4 **Steps to reproduce:** - Create a one-time product. - Add the one-time product to the cart. - Add a subscription (recurring) product. - The one-time product is incorrectly shown as a subscription. **Issue:** - When a customer adds a one-time product to the cart and then adds a subscription product, the one-time product incorrectly gets treated as a subscription. **Solution:** - If the cart already contains a one-time product, the system will show a warning and block adding subscription products (and vice versa). **Impact:** - Customers can clearly understand whether they are buying a one-time product or a recurring subscription, without mixing them by mistake. Task-5046146 Forward-Port-Of: odoo/enterprise#93282
Italian ENASARCO taxes are now correctly treated as both withholding and pension fund contributions. This ensures invoices generate compliant electronic XML data and that the correct withholding setup is available immediately after installing the Italian localization modules.
Original PR description
* = l10n_it, l10n_it_edi, l10n_it_edi_withholding The ENASARCO tax works both as a Withholding (negative) tax and as a Pension Fund tax. It must appear in the XML in both sections DatiRitenuta and CassaPrevidenziale. - We modified the master data to amend this error. Now the correct Withholding type appears right after installing the module. - Since there was an explicit check on taxes being both, we removed it. - Removed an exception where ENASARCO taxes were allowed to have positive values Forward-Port-Of: odoo/odoo#228322 Forward-Port-Of: odoo/odoo#226357
RFQs created from Blanket Orders now keep the original unit of measure and price on each product line. This prevents incorrect or confusing values when the same product appears with different units or prices, improving purchasing accuracy.
Original PR description
## **Purpose:** When creating an RFQ from a Blanket Order, the product lines did not retain the UoM and price from the Blanket Order. This caused RFQs to display incorrect values, which could confuse users, especially when same product had multiple lines with different UoMs and prices. ## **With This Commit:** RFQs generated from Blanket Orders now correctly preserve the UoM and price from the original Blanket Order. This ensures consistency and accuracy, giving users the expected values in the RFQ lines. task - 5075869
This fixes an issue where increasing a sales order quantity after using a custom warehouse route could create an additional delivery for the wrong amount, or fail to create one at all. Businesses using multi-step deliveries and personalized routes will now get accurate replenishment and delivery quantities when sales orders are updated.
Original PR description
**Steps to reproduce:** - enable multi-step routes setting. - navigate to warehouse management/locations create a new location (the "test location"). - select "internal location" for the location…
**Steps to reproduce:** - enable multi-step routes setting. - navigate to warehouse management/locations create a new location (the "test location"). - select "internal location" for the location type. - select WH for the parent location - navigate to warehouse management/warehouses and select the warehouse corresponding to WH. - set the warehouse in 3 steps delivery. - click on the routes smart button. - click on the "deliver in 3 steps (pick+pack+ship)" route. - add a rule, for the action select "push to", for the operation type select "internal transfers", for the source location select the "test location" you just created and for destination location select "WH/Output". - save. - create a storable product and set an on-hand quantity - create a new sale order for 1 quantity of this product and confirm it - click on the picking smart button, change the destination location to the test location and validate - open the sale order and change the quantity to 3 **Current behavior:** A new picking is created from stock to packing zone (which is the expected behavior) but the quantity is 1 **Expected behavior:** The quantity should be 2. If we only increase the quantity by 1 on the sale order it does not even create the new picking **Cause of the issue:** The warehouse_id field is invisible in stock.rule form view when the action is push. Therefore, the rule is created without a warehouse_id. Also, moves created from a rule have the same warehouse_id as the rule. https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/stock/models/stock_rule.py#L275 So, when we validated our first move (from stock to the test location), this created a second move (from test location to output) that does not have a warehouse id (because it was created from our own push rule that we created). When we update the quantity of the sale ordre line, _action_launch_stock_rule calls _get_quantity_procurement to compute the current quantity on the moves. This method then calls _get_outgoing_incoming_moves to get the initial move created from the rule. In this case this should return only the first move created. But because the second move does not have a warehouse_id, it's rule.id is added to triggering_rule_ids. https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/sale_stock/models/sale_order_line.py#L315-L317 And the move is later added to the outgoing moves that will be returned. https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/sale_stock/models/sale_order_line.py#L322-L329 So the two moves are returned and the sum of the quantities of the moves is 2 instead of 1. https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/sale_stock/models/sale_order_line.py#L292-L294 So the product quantity for the procurement will be 1 (3-2) instead of 2 (3-1). https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/sale_stock/models/sale_order_line.py#L386 opw-5039249 Forward-Port-Of: odoo/odoo#229332 Forward-Port-Of: odoo/odoo#227421
Invoice PDFs now correctly include both the product name and any manually added or edited description. This prevents missing product information on customer-facing invoices and helps keep printed documents clear and complete.
Original PR description
Before this commit, When printing an invoice for a product with a manually added or edited description, only the description appeared in the PDF. Technical Reason: In commit https://github.com/odoo/odoo/commit/4f839fad0fb20688a740282e4172dbffa095fc51, the `updateLabel` function was added, which was used everywhere until version 18.4. From version 19 onward, it was replaced by `parseLabel` in https://github.com/odoo/odoo/commit/bc6592a8514d6557037868a0f42265070fa02263. As a result, the previous function no longer works. After this commit, Both product name and description will be displayed properly in the invoice PDF. task-5109497
The German POS certification integration now sends payment amounts in the format required by Fiskaly, preventing payment validation errors. It also avoids creating unnecessary zero-value payment lines caused by rounding when similar payments are combined.
Original PR description
This ticket fixes two bugs: ### Problem 1 Fiskaly requires `amounts_per_payment_type` values to be strings with 2 to 5 decimal places. After this PR: https://github.com/odoo/enterprise/pull/83300, amounts started being sent as numbers, which caused bad request error when paying a PoS order in version 19.0. ### Solution 1: Restore the use of `.toFixed(2)` to ensure amounts are sent as strings. ### Problem 2 When adding two payment lines with decimal amounts using the same payment method, the system merges both payments into a single line by adding the second amount to the first. This can cause a rounding difference and may trigger sending an additional payment line to Fiskaly with a 0.00 amount. ### Solution 2: Check if rounded change is zero before creating the change line. opw-5115157
Closing or reopening rental subscriptions for products sold as kits now keeps the delivered quantity accurate. This prevents incorrect return errors that could block users from closing subscriptions after validating deliveries.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Enable rental transfers; 2. have a rental product with a kit BoM; 3. create a subscription order in the Rental app; 4. add the rental product; 5. confirm…
Versions -------- - 18.0+ Steps ----- 1. Enable rental transfers; 2. have a rental product with a kit BoM; 3. create a subscription order in the Rental app; 4. add the rental product; 5. confirm order; 6. validate deliveries; 7. close the subscription. Issue ----- Invalid SQL command, cannot return more than was delivered. Cause ----- When closing or reopening a subscription, the `_compute_qty_delivered` method gets triggered. By default, these methods required the relevant moves to have the same `product_id` as the sale order line. For products with kit BoMs, the move's `product_id` is tied to the BoM instead of the final product, leading to `qty_delivered` getting reset reset to 0 on recompute. This causes an error, as `qty_returned` is non-zero. Solution -------- The `qty_delivered` for these lines was set in the `_action_done` method of `stock.move`. By instead moving this logic into a `_compute_qty_delivered` override, any recompute should have the same result, instead of getting reset to 0. opw-4833280 Forward-Port-Of: odoo/enterprise#96179 Forward-Port-Of: odoo/enterprise#88691
French FEC exports now skip invoice note and section rows that are not linked to an accounting account. This prevents non-accounting lines from appearing in official accounting export files, improving accuracy and compliance for French localization users.
Original PR description
Step to reproduce: - for l10n_fr Localization - Create a customer invoice and add a note or Add a section . - Go to accounting > reporting > FEC - Export FEC (don't exclude 0 lines) Obseravtion: - The journal items with note and section will be included in the FEC Cause: - for Fec report, we consider move_line which do not have account_id linked to it, due to left_join, hence lines with display_type line_note or line_section are included Fix: - use `join` instead of `left_join` - **v17.0, when the behaviour was as expected** https://github.com/odoo/odoo/blob/3d3898b442379d7416da0ee7e363b6587c725218/addons/l10n_fr_fec/wizard/account_fr_fec.py#L194-L196 opw-5079457 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227817
Discarding a quality worksheet wizard no longer creates a worksheet record or makes the quality check appear completed. This prevents incorrect quality status updates when users open a worksheet by mistake and cancel out.
Original PR description
**Problem:** Opening the worksheet wizard and discarding it makes the worksheet "completed" **Steps to reproduce:** - create a quality check - set a product - in type select worksheet - select the "quality issues" template - select a team - click on the worksheet smart button - discard **Current behavior:** the worksheet is marked has completed **Cause of the issue:** when discarding, this line causes the creation of an instance of worksheet.template linked to the quality.check via its worksheet_template_id https://github.com/odoo/enterprise/blob/a1dd58f2b59ecd2d22efd29eb0aace7bdca64f66/quality_control_worksheet/static/src/views/quality_worksheet_fromview.js#L35 which will make the worksheet_count field of the quality check worth 1 after discarding https://github.com/odoo/enterprise/blob/1c5e547b59a57c840ef72b2e76c6a6a627f1f18e/quality_control_worksheet/models/quality.py#L37-L39 opw-4980945 Forward-Port-Of: odoo/enterprise#95219
Restores access to individual account reports and monthly payroll menu entries in the Swiss payroll module. This ensures payroll teams can again find and use these reporting options as expected.
Original PR description
… menuitems Forward-Port-Of: odoo/enterprise#95929
This fix improves how manufacturing by-products are shown and handled in Shop Floor. Users now see the right by-products in the right place, clearer quantities, fewer irrelevant location details, and a more direct way to create tracked by-product quantities.
Original PR description
Shop Floor by-products fixes: - show by-products not linked to a workorder only on mo card - do not show locations for by-products - always show quantity done / to consume quantity - clicking (+) on tracked by-products now opens the create quant dialog rather than the quants list view task: 4781451 Forward-Port-Of: odoo/enterprise#96059 Forward-Port-Of: odoo/enterprise#91341
Fixed an issue that could cause the Sales dashboard to crash when opened without the subscription module installed. The dashboard no longer relies on a subscription-only field, improving reliability for Sales users.
Original PR description
The system will crash when the user opens the dashboard module.
**Steps to produce:**
- Install the `Sales` module with demo data.
- Open the dashboard module.
**Error:**
```py
KeyError: 'recurring_invoice'
ValueError: Invalid field product.template.recurring_invoice in condition ('recurring_invoice', '!=', True)
```
**Cause:**
- From this [PR], the field `recurring_invoice` is being used in the `spreadsheet_dashboard_sale` module. However, this field is actually defined in the `sale_subscription` module. Since `spreadsheet_dashboard_sale` does not currently listed `sale_subscription`in its `depends`.
**Solution:**
- In this PR, I have removed the reference from the domain from `spreadsheet_dashboard_sale` module.
[PR]: https://github.com/odoo/odoo/pull/225542
**sentry-6912254481**Field service sales order lines now recalculate their prices when a task's warranty status is turned on or off. This prevents items from incorrectly staying at zero price after warranty is removed, helping ensure accurate customer billing.
Original PR description
### Steps to reproduce:
- Create a sales order linked to the customer
- Assign a customer (partner) to the task and link the task to the sales order
- Create a sales order line for a product and link it to the task
- Verify the price unit matches the product's list price by default
- Set the task as under warranty
- Add or remove an item from SOL
- Verify the price unit is set to 0.0 in the sales order line
- Unset the warranty status
- Add an item to the SOL
### Cause:
When setting the task as under warranty we modify the price of each SOL to 0.0 but when unset the warranty option we try to fetch the prices from the SOL which we already set it to 0.0
### Fix:
Backporting https://github.com/odoo/enterprise/pull/85492/commits/8615fad5b75d32483b25cf9b1525883e7a730fac to check when writing on the under_warranty value we recompute the SOL prices
opw-4579404
Forward-Port-Of: odoo/enterprise#96045DHL delivery insurance settings are now applied when estimating shipping costs and creating shipments. This helps businesses charge correctly for insured deliveries and alerts users when insurance is not available for a route.
Original PR description
**PROBLEM** Insuring a delivery using the dhl carrier don't work. It doesn't affect the estimated rate of the delivery, and the shipment created when validating the delivery order isn't insured.…
**PROBLEM** Insuring a delivery using the dhl carrier don't work. It doesn't affect the estimated rate of the delivery, and the shipment created when validating the delivery order isn't insured. **STEP TO REPRODUCE** 1. Install the `delivery_dhl_rest` and the `l10n_be` modules (we will use the be demo company). 2. Set the insurance percentage of the dhl be delivery method to 100%, and set the region to Europe (the demo data is incorrect), and activate the debug (click the "No Debug" smart button to activate the log of requests). 3. Switch to the be company. 5. Create a sale order, with a customer located in Belgium, and add shipping using the dhl method. 6. Go to the delivery order, and validate it. 7. Go to settings/Technical/Logging and look at the rating_request and shipment_request, notice there is no information about insurance. **CAUSE** We don't send any info about insurance in the api requests. **FIX** Computing and sending the insured amount, only if the insurance percentage is not null. If the package can't be insured between the origin and the destination, a error message will be displayed when updating the delivery price. **TESTS PROBLEM/FIX** The localization of `your_company` was not recognized by DHL, leading to the DHL api returning a 0 delivery price. Switching the localization to Eghezee, Rue du Laid Burniat 5 fixes this. Assertion regarding the delivery price were restored. The picking date could sometimes be refused by DHL (stop working after arround 4/5 PM). Changing the picking date to, two day after, at noon works. `test_01_dhl_basic_be_domestic_flow` was modified to also test domestic shipment insurance in addition of the basic flow. Some code in it was refactor into inner function to avoid boilerplate. Adding `INSURED_RATE_MOCK_RESPONSE` to mock response in test_01. opw-4989281 Forward-Port-Of: odoo/enterprise#93105
Signed signature requests can no longer be deleted once completed. This helps preserve important signed records and reduces the risk of losing legally or operationally important documents.
Original PR description
backport of https://github.com/odoo/enterprise/commit/b2d32811877cdf1649095435ce16274ae96421f3 opw-5111568 Forward-Port-Of: odoo/enterprise#96081 Forward-Port-Of: odoo/enterprise#95922
The website SEO cover image now uses a relative image path when an existing image is selected. This prevents shop pages from failing with an error when the website has a configured domain or the saved image URL differs from the current domain.
Original PR description
Currently an error is generated when a user selects existing images inside the cover image of SEO. Steps to produce: - Install the `Ecommerce` module with demo data - Add existing image inside `website_meta_og_img` (Website > Editor > Site > Optimize SEO > Cover Image) -Set a domain on the website - Go to the shop page and get a 500 error Error: `ValueError: Extra URL must use same scheme and host as base, and begin with base path` This is because in 19 with commit https://github.com/odoo/odoo/commit/977e62d91f3e8235e251e9d21b08f53db1856c6b, Werkzeug `url_join` is replaced by odoo `urljoin`, which requires that the path that is appended has no host or the same host. Since the current code loads the scheme and host of the existing image, if the URL is different than the saved one (because of the domain or another reason), we get an error. This commit will fix the above issue by loading the relative URL instead of an absolute one. sentry-6912373261
Point of Sale now ignores number-entry input when users press Ctrl, Alt, or Command keyboard shortcuts. This prevents accidental quantities or values from being added to order lines while users use browser or system shortcuts such as zoom or tab navigation.
Original PR description
Before this commit, the NumberBuffer was listening to all keyup events. This caused unintended behavior when the user pressed browser/system shortcuts such as: - `Ctrl +` / `Ctrl -` on Windows/Linux (zoom in/out) - `⌘ +` / `⌘ -` on macOS (zoom in/out) - `Alt + <number>` or `Alt + <arrow>` (browser tab navigation, menu accelerators) Because the key itself (e.g. `"+"`, `"-"`, `"1"`) was part of `INPUT_KEYS`, the NumberBuffer captured the event and updated its state leading to unexpected inputs being added to the PoS order lines. opw-4965429 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227429
Products created under a parent company now keep the sales tax selected by the user instead of having a branch company's default tax added back automatically. This prevents incorrect tax settings when branches share taxes with their parent company.
Original PR description
**Issue description:** The logic introduced in #127196 adds default taxes from "other" companies to products created without a specific company. However, because child companies (branches) share…
**Issue description:** The logic introduced in #127196 adds default taxes from "other" companies to products created without a specific company. However, because child companies (branches) share taxes with their parent company, when creating a new product using the parent company and setting a specific tax (different from the default), the default tax was incorrectly added back to the product. This happened because the logic considered the branch an "other company" and applied its default tax. **FIX:** Exclude branch companies from the domain when we set the default tax of other companies on the product. **Steps to reproduce:** 1. Create a branch company. (It will automatically have the same default tax as its parent). 2. With the parent company selected, create a new product, leaving the 'Company' field empty, and change its sales tax to any tax other than the default, and save. 3. Notice that the default tax is set again on the product. opw-5094415 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229066
Product prices on the website now display using the correct currency precision for the active pricelist. This prevents shoppers from seeing unnecessary decimal places when a currency is configured to round to whole amounts, keeping storefront pricing consistent across sessions.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Set currency rounding of EUR to 1.0; 2. use the currency on a website pricelist; 3. go to a product page in /shop; 4. open the url in a new session. Issue…
Versions -------- - 17.0+ Steps ----- 1. Set currency rounding of EUR to 1.0; 2. use the currency on a website pricelist; 3. go to a product page in /shop; 4. open the url in a new session. Issue ----- From the editor, the price gets displayed as expected, with no decimals. In the new session, the price gets displayed with two decimals. Cause ----- The `_priceToStr` method used, always uses a `precision` of 2, except in editor mode when it will retrieve a different value from a hidden `.decimal_precision` element. Solution -------- Add the website's currency precision to `combination_info` via the controller, and use this value in `_priceToStr`. For the product configurator, store the currency precision in the `.js_price_total` element's dataset. Also insert the precision in the `.oe_price` element's dataset, allowing it to be used as a fallback in case the configurator template isn't up to date. opw-4996878 Forward-Port-Of: odoo/odoo#229416 Forward-Port-Of: odoo/odoo#224429
Fixed an issue where self-ordering kiosks could show a blank white screen when only child product categories contained products. The kiosk now selects an available child category so customers can continue ordering normally.
Original PR description
Problem: When the available categories for a point of sale contain one parent category and its child categories and the parent category itself does not have any products, the code filters out the top…
Problem: When the available categories for a point of sale contain one parent category and its child categories and the parent category itself does not have any products, the code filters out the top categories as those that have no parent category. If, in such a case, no products belong to the parent category itself, the selected category is undefined which leads to a blank white screen and the javascript error visible on the console. Purpose: If there are no top categories, the screen should ideally load the current category computed before. This fix leads to the one of the child categories being the selected category and the kiosk screen loads properly Steps to Reproduce on Runbot: 1. Create a point of sale. Go to Settings, choose no presets and “Kiosk” in the self-ordering option. 2. Create a parent POS category and two child POS categories. 3. Ensure there are products belonging to the two child categories and none to the parent category 4. Open settings for the POS and choose only these three categories in the “Restrict Categories” section. 5. Go to the point of sale and open the kiosk. Click on “Order Now”. The white screen appears and the js traceback error is visible on the console opw-5058245 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229592 Forward-Port-Of: odoo/odoo#228651
Spanish Modelo 303 VAT returns now exclude irrelevant tax tags when preparing closing entries. This helps ensure the generated closing entry reflects the correct tax return figures and reduces accounting correction work.
Original PR description
Before this commit the domain of the modelo 303 would take into account irrelevant tax_tags, causing the closing entry to be incorrect. Fixed this by adding an additional domain to the _get_vat_closing_entry_additional_domain function. Forward-Port-Of: odoo/enterprise#96106
This fix stops consolidated invoicing for Mexican Point of Sale orders when required localization fields do not match across the selected orders. Instead of producing a confusing system error, users now receive a clear validation message so they can correct the order grouping before billing.
Original PR description
Issue: Currently when we consolidate billing for PoS orders we receive an error because some l10n fields expect a single record and not a recordset. This can be solved by looping over the PoS orders instead and preparing the invoice values per order (this is how the sale orders handles consolidated billing) however, we run into an issue if not all PoS orders have the same l10n fields. Ideally PoS orders with different l10n fields should not be consolidated. Purpose of this PR: check to make sure that the three l10n_mx_edi fields are the same among PoS orders before creating consolidated invoice. raise a validation error if the fields are not the same. Steps to reproduce on Runbot: install pos and l10n_mx* create pos orders for same contact try to create invoices with consolidated billing enabled singleton error is raised Note: main discussion about consolidated billing with l10n_mx localization: #86255 opw-4802180 Forward-Port-Of: odoo/enterprise#86579
This fix ensures that protected bank account numbers cannot be altered once they are locked. It helps preserve payment data integrity and reduces the risk of accidental or unauthorized changes to stored bank details.
Original PR description
Before this fix it was possible to update sanitized_acc_number even if it is locked. Forward-Port-Of: odoo/odoo#229833 Forward-Port-Of: odoo/odoo#184736