Daily updates from Odoo
Friday, July 17, 2026
354 changes
22 changes
Enhancements to existing features
The payment form no longer shows the Payment Identifier field because it does not provide useful information for users. This keeps the payment screen cleaner and helps users focus on relevant payment details.
Original PR description
- The Payment Identifier field has been permanently hidden from the payment form view, as it does not provide actionable or useful information to the end user. community pr - https://github.com/odoo/odoo/pull/266072 task- 6237870 Forward-Port-Of: odoo/enterprise#118183
Resolved issues and error corrections
Coding editor activity in the timesheet assistant now uses the correct event category, so it displays with the intended code-related icon. This avoids confusing or missing visual cues when users review assistant events.
Original PR description
In the assistant, events from a coding editor use the "code" event type, which doesn't exist. This PR changes it to the correct value, which is "development". Task-6392585 Forward-Port-Of: odoo/enterprise#124502
Payroll schedule options in the Kuwait payroll localization now appear in the user's selected language. This fixes a missed localization issue so business users see consistent translated labels in payroll configuration.
Original PR description
The values returned by `_get_selection_schedule_pay()` wern't translated. This localization was missed by this forward port: 961bedf91d754cce5d3cdecabe1e504770902d05 opw-6359395
Chilean point-of-sale receipts with SII barcodes now print correctly instead of crashing during receipt generation. This ensures sales can be validated and customers can receive compliant receipts without interruption.
Original PR description
Steps to reproduce: - Have a Chilean company with DTE configured (a resolution number/date and a signed boleta/factura, so the order's move has an SII barcode) - Open a PoS session, pay an order and validate it Issue: The receipt fails to render and printing crashes with: `TypeError: ctx.image.l10n_cl_sii_barcode_image.to_base64 is not a function` Cause: Commit 0b50021bdae adapted this template as part of the BinaryValue migration (odoo/odoo#244421), calling `to_base64()` on the barcode image. However `l10n_cl_sii_barcode_image` is a computed `fields.Char` that already holds a base64 string (`_pdf417_barcode` returns `b64encode(...).decode()`), not a Binary, so it is never wrapped in a `BinaryValue`. Moreover, this template is also rendered client-side by the PoS QWeb engine, where the value loaded from the server is a plain string with no `to_base64` method either. opw-6389718 Forward-Port-Of: odoo/enterprise#124438
Service sale order lines created from field service planning now let Odoo calculate prices automatically. This ensures customer pricelists and product pricing rules are applied correctly instead of being bypassed by a fixed unit price.
Original PR description
Before this commit, in the method `_generate_service_sale_order_lines` the `price_unit` for sale order lines used an explicitly defined unit price. This prevented the pre-computation of the price. It may cause some issues, for example if there was a pricelist defined on the product, we didn't apply the prices from that pricelist. This commit removes explicit definition of the `price_unit` to let the sale order creation process handle it. [error-941068](https://runbot.odoo.com/odoo/error/941068)
The Balance Sheet report now displays numeric column headers with the correct spacing. This small visual fix improves readability and consistency in financial reports without changing any report data or calculations.
Original PR description
Due to `padding: 0.25rem 0.75rem !important;` To reproduce: - Open Balance Sheet - Check the Balance column numeric-header
Opening the template picker from an audit report article without a parent no longer causes an error. Instead, users see a clear message when no article template is available, keeping the audit report editing flow usable.
Original PR description
Currently, users encounter a traceback when clicking the "Load a Template" button in the WYSIWYG article helper if the article is linked to an audit report and has no parent article. Steps to…
Currently, users encounter a traceback when clicking the "Load a Template" button in the WYSIWYG article helper if the article is linked to an audit report and has no parent article. Steps to reproduce: 1. Install `accountant_knowledge`. 2. Create and open a new audit report. 3. Delete all content from article (the root). 4. Click the "Load a Template" button in the helper. => Crash with `AssertionError: Invalid falsy real id.` The issue occurs because the method responsible for loading the annex to display (see: `get_suggested_templates`) expects at least one record in the recordset. When the article has no parent, the recordset is empty, causing the method to fail. Before attempting to load a template, we will check whether the article has a parent article. If no parent exists, no template will be provided to the template picker. In that case, the picker will display a helper message indicating that no article template is available to load. Task [link](https://www.odoo.com/odoo/project.task/6333859) Task-6333859 Forward-Port-Of: odoo/enterprise#121807
This fixes cases where Point of Sale payments could get stuck when websocket connections were unavailable and the system fell back to longpolling. It also corrects Six payment handling in kiosk mode, improving payment reliability for affected stores.
Original PR description
A change from odoo/enterprise#116705 made the `iot_http_service` try to access the `self_ordering_mode` on the session`, leading to longpolling failure on non-self order as data would be undefined. Also, a mistake in error catching in the longpolling service made it so that an event request thrown would abort directly with the previous one, instead of only the previous one. If websocket was unavailable at the same time, it would result on the PoS getting stuck waiting for confirmation of the payment. In addition, we fixed Six payments in Kiosk, failing because it tryed to access `user.id` where user was `undefined`. task-6391166
Colombian electronic invoice XML imports now treat the listed price as the actual unit price, matching DIAN rules. This prevents incorrect negative discounts from appearing on vendor bills when imported products have quantities greater than one.
Original PR description
Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price…
Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price unit. However, in Colombia, the DIAN treats the PriceAmount node as the exact price unit. This was not flagged in the system so the parser incorrectly divides the PriceAmount by BaseQuantity, resulting in negative discounts to be added to match the subtotal. Solution: Extract the basis_qty logic into a helper method so other localizations can override when needed. Current behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets incorrectly divided, resulting in negative discounts on the vendor bill. Expected Behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets parses as the exact unit price with no negative discounts applied. task-6215466 Forward-Port-Of: odoo/enterprise#124567 Forward-Port-Of: odoo/enterprise#122313
This fix prevents an accounting dashboard filter from accidentally affecting document creation during Mexican electronic invoicing payment updates. It avoids an error that could block users from updating payments on CFDI invoices after reconciling bank transactions.
Original PR description
Issue: The `default_type` context can leak into documents creation with invalid values (e.g., 'sale' for documents.document.type), causing a ValueError. Steps to reproduce: - Use a Mexican company with CFDI credentials configured. - Install the documents_account module and create a folder for journals where you will place customer payments. - Create an invoice with "payment policy = PPD", and send it to CFDI. - Create a bank transaction and reconcile it with the invoice. - Go to the Accounting Dashboard, remove current filters, and group by "Type" (this injects default_type into the context). - From there, enter the "Sales" journal and open the invoice. - Click on the "Update Payments" button. - Result: `ValueError: Wrong value for documents.document.type: 'sale'` Fix: Clean context from the `default_*` keys when creating the attachment of the document. opw-6141172 Forward-Port-Of: odoo/enterprise#124578 Forward-Port-Of: odoo/enterprise#124074
This fix ensures contract updates use the right template, preferring the current contract version when available or falling back to the template from the salary offer. This helps HR teams avoid incorrect contract documents during offer and contract update workflows.
Original PR description
contract update template should come from current version if any or from the offer's contract template. Task-6094733 Forward-Port-Of: odoo/enterprise#124638 Forward-Port-Of: odoo/enterprise#123450
Since 414e55cf7c397, we can assign multiple users to a user-defined filter but because it's now a many2many, any user that got archived won't be shown in the `user_ids` fields anymore, it could mislead the filter being a global filter; whereas it's not. This commit also display archived users so we can see all users effectively assigned to the user-defined filter. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275841
Original PR description
Since 414e55cf7c397, we can assign multiple users to a user-defined filter but because it's now a many2many, any user that got archived won't be shown in the `user_ids` fields anymore, it could mislead the filter being a global filter; whereas it's not. This commit also display archived users so we can see all users effectively assigned to the user-defined filter. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275841
The more() action helper caches the More Actions object and only refreshes its inner actions list, leaving disabledCondition unchanged. As a result, if the dropdown is created while disabled, it remains disabled even after the composer is re-enabled. Individual actions (e.g., Attach files) don't exhibit this issue because they use a dynamic callback `(({ owner }) => owner.areAllActionsDisabled)` that is evaluated when needed. task-6393956 --- I confirm I have signed the CLA and read th
Original PR description
The more() action helper caches the More Actions object and only refreshes its inner actions list, leaving disabledCondition unchanged. As a result, if the dropdown is created while disabled, it remains disabled even after the composer is re-enabled.
Individual actions (e.g., Attach files) don't exhibit this issue because they use a dynamic callback `(({ owner }) => owner.areAllActionsDisabled)` that is evaluated when needed.
task-6393956
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#276870Steps to produce: --- - Install the `sales` module. - Create a product and `enable track inventory.` - Log in as user with only view access rights in products and also have the sales access rights. - Create a sale order containing product and confirm it. Issue: --- - An access error is raised during order confirmation. Root cause: --- - In [commit], to handle inventory tracking, the `qty_available` field was moved to `product.product`. Unlike before, this value is increased or
Original PR description
Steps to produce: --- - Install the `sales` module. - Create a product and `enable track inventory.` - Log in as user with only view access rights in products and also have the sales access rights. -…
Steps to produce: --- - Install the `sales` module. - Create a product and `enable track inventory.` - Log in as user with only view access rights in products and also have the sales access rights. - Create a sale order containing product and confirm it. Issue: --- - An access error is raised during order confirmation. Root cause: --- - In [commit], to handle inventory tracking, the `qty_available` field was moved to `product.product`. Unlike before, this value is increased or decreased depending on the operation performed. - As a consequence, creating or updating a sale order triggers a write to this `qty_available` field on the related product. This write happens under the current user's permissions, so users who only have read access to products (but can create/edit sale orders) hit an `AccessError`, since they lack write access on `product.product`. Solution: --- - Use `sudo()` when accessing the required product quantity information to ensure the operation can be completed without requiring additional product access rights. The same issue also occurs when confirming a purchase order. [commit]: https://github.com/odoo/odoo/commit/ca96992919b11105da44238c3e522f8eec4a740b opw-6290608 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276563 Forward-Port-Of: odoo/odoo#270067
Version: --------- - 19.0+ Steps to Reproduce: ----------------------- 1. Install sale_management, purchase, stock modules. 2. Create a storable product with Tracking: By Lot, 3. Create two Purchase Orders, each for 10 units. Receive PO-1 → 10 units with tagged as lot-1 Receive PO-2 → 10 units with tagged as lot-2 4. Create two Sale Orders: SO-1 → deliver 2 units from lot-1 (validate) SO-2 → deliver 4 units from lot-2 (validate) 5. Open Inventory > Reporting > Stock,
Original PR description
Version: --------- - 19.0+ Steps to Reproduce: ----------------------- 1. Install sale_management, purchase, stock modules. 2. Create a storable product with Tracking: By Lot, 3. Create two Purchase…
Version:
---------
- 19.0+
Steps to Reproduce:
-----------------------
1. Install sale_management, purchase, stock modules.
2. Create a storable product with Tracking: By Lot,
3. Create two Purchase Orders, each for 10 units.
Receive PO-1 → 10 units with tagged as lot-1
Receive PO-2 → 10 units with tagged as lot-2
4. Create two Sale Orders:
SO-1 → deliver 2 units from lot-1 (validate)
SO-2 → deliver 4 units from lot-2 (validate)
5. Open Inventory > Reporting > Stock,
click "Total Value", then check the "Remaining Quantity" column
Issue:
-------
Observed : remaining_qty = 10 for lot-2 receipt, 4 for lot-1 receipt
Expected : remaining_qty = 8 for lot-1 receipt (10−2), 6 for lot-2 receipt (10−4)
Cause:
--------
When the "Remaining Quantity" column is computed, the following call
chain executes:
stock.move._compute_remaining_qty()
→ calls product.product._get_remaining_moves()
→ calls product._run_fifo_get_stack() ← HERE is the problem
https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L372
`_get_remaining_moves` calls `_run_fifo_get_stack()` with NO lot
argument. Inside `_run_fifo_get_stack`, because no lot is given, it
computes the stack size from the TOTAL product qty across all lots:
https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L583
fifo_stack_size = 14 (10 received lot-1 + 10 received lot-2
− 2 delivered lot-1 − 4 delivered lot-2)
It then builds a domain to find incoming moves with NO lot filter:
https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L607
https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L614-L618
```Domain: [('is_in', '=', True), ('product_id', '=', X)]
↳ returns both receipts ordered:
[lot-2 receipt (10 qty), lot-1 receipt (10 qty)]
then walks this list consuming `fifo_stack_size = 14`:
So it take: [move_lot1_receipt(10)] First Lot
remaining_qty_on_first = min(10, 14) = 10
after consuming fifo_stack_size → 14−10=4 left → move_lot1 gets 4
```
So back in `_get_remaining_moves`:
qty_by_move = {
lot-2 receipt → 10, ← wrong (should be 6)
lot-1 receipt → 4, ← wrong (should be 8)
}
- The root cause: `_run_fifo_get_stack` is designed for products that
have one shared FIFO stack. For lot-valuated products, each lot is an
independent inventory layer. Running a single combined stack mixes both
lots together, so the deductions (2 from lot-1, 4 from lot-2) are not
attributed to the correct receipt moves — the algorithm just consumes
from the oldest receipts first with no awareness of which lot was
actually delivered.
Fix:
-----
`_run_fifo_get_stack` already accepts a `lot=` argument that:
- sets `fifo_stack_size = lot.product_qty` (correct per-lot qty)
- adds `('move_line_ids.lot_id', 'in', lot.id)` to the domain
so only the receipts that touched that specific lot are returned
The only missing piece was calling it per lot instead of once globally.
- With the fix, the stack for each lot is built correctly:
lot-1: fifo_stack_size = 8 → lot-1 receipt remaining_qty = 8 ✓
lot-2: fifo_stack_size = 6 → lot-2 receipt remaining_qty = 6 ✓
---
opw-6311341
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#276690
Forward-Port-Of: odoo/odoo#272411[FIX] fleet: fix vendor bill vehicle association bug Bug reprod: Go to 19.2 or above 1 - Go to vendor bills. 2 - Create an invoice line add vehicle. 3 - Click to vehicle via the link 4 - You will see fleet model and try to press to some smart buttons, traceback will occur (Odometer, Services...) Bug cause: 1 - When we press to smart buttons for Odometer or Services we are going to return_action_to_open function. 2 - In this function corresponding action's
Original PR description
[FIX] fleet: fix vendor bill vehicle association bug Bug reprod: Go to 19.2 or above 1 - Go to vendor bills. 2 - Create an invoice line add vehicle. 3 - Click to vehicle via the link 4 - You will see…
[FIX] fleet: fix vendor bill vehicle association bug
Bug reprod: Go to 19.2 or above
1 - Go to vendor bills.
2 - Create an invoice line add vehicle.
3 - Click to vehicle via the link
4 - You will see fleet model and try to press to some smart buttons, traceback will occur (Odometer, Services...)
Bug cause:
1 - When we press to smart buttons for Odometer or Services we are going to return_action_to_open function.
2 - In this function corresponding action's xml id is calculated and we are calling that action and that will load some view.
3 - self.env.context is passed directly as a context
4 - In the view_move_form (That include invoice lines, account_id and vehicle_id fields), account_id has a context list_view_ref="account.view_account_list_from_entry"
5 - This context is passed in self.env.context and that's why it tries to load this list_view when we press to odometer,service smart buttons, which shouldn't be the case.
6 - In 19.1 this context is not in self.env.context because >=19.2 m2o_cell_with_extra_m2o_fields is used for account_id and account_id and vehicle_id fields are combined in the single cell.
7 - That's why the context of account_id is passed to the vehicle page as well.
Bug solution:
1 - In the return_action_to_open function I'm dropping the list_view_ref context and we can load the correct related views about odometer or service or other ones.
task - 6385611
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
Forward-Port-Of: odoo/odoo#276167Issue: ---------------------------------------- The units (day, year, etc.) aren't being translated in the Milestones view. Steps to reproduce: ---------------------------------------- - Switch the language to French - Go on an Accrual plan form view - In the milestones view, the units aren't translated Cause: ---------------------------------------- We input the key value of the selections fields `start_type` and `added_value_type`. These values aren't translated. Solution: --
Original PR description
Issue: ---------------------------------------- The units (day, year, etc.) aren't being translated in the Milestones view. Steps to reproduce: ---------------------------------------- - Switch the language to French - Go on an Accrual plan form view - In the milestones view, the units aren't translated Cause: ---------------------------------------- We input the key value of the selections fields `start_type` and `added_value_type`. These values aren't translated. Solution: ---------------------------------------- We create a dictionary with the same keys as the fields and a translated value as values. In the view, we read the values of the dictionary to get the translated units. opw-6367235 Forward-Port-Of: odoo/odoo#276665 Forward-Port-Of: odoo/odoo#275575
If we are in a case of a salary simulation, we don't care about future public holidays. The unlink done in _delete_future_public_holidays_timesheets was causing some cache invalidations which were messing up with the original offer. Forward-Port-Of: odoo/odoo#276520
Original PR description
If we are in a case of a salary simulation, we don't care about future public holidays. The unlink done in _delete_future_public_holidays_timesheets was causing some cache invalidations which were messing up with the original offer. Forward-Port-Of: odoo/odoo#276520
It can happen that _ref_vat has some lazy translate object. Without the self.env._ the translation would be ignored. (no translation language detected, skipping translation) runbot-941504 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276076 Forward-Port-Of: odoo/odoo#275561
Original PR description
It can happen that _ref_vat has some lazy translate object. Without the self.env._ the translation would be ignored. (no translation language detected, skipping translation) runbot-941504 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276076 Forward-Port-Of: odoo/odoo#275561
**Purpose of this PR:** Before this PR, the Voice detection sensitivity indicator in call settings could get stuck showing the last detected level after clicking "Stop" right after "Test". The `AudioWorkletNode`'s port kept receiving tic messages briefly after `disconnect()`, since disconnecting only unroutes the audio graph and does not stop the worklet from posting pending messages. <img width="546" height="73" alt="voice_test_bug" src="https://github.com/user-attachments/assets/05a10d23
Original PR description
**Purpose of this PR:** Before this PR, the Voice detection sensitivity indicator in call settings could get stuck showing the last detected level after clicking "Stop" right after "Test". The…
**Purpose of this PR:** Before this PR, the Voice detection sensitivity indicator in call settings could get stuck showing the last detected level after clicking "Stop" right after "Test". The `AudioWorkletNode`'s port kept receiving tic messages briefly after `disconnect()`, since disconnecting only unroutes the audio graph and does not stop the worklet from posting pending messages. <img width="546" height="73" alt="voice_test_bug" src="https://github.com/user-attachments/assets/05a10d23-fe60-4a85-b906-bfec6d235ec5" /> Steps to reproduce: 1. Open Voice & Video Settings. 2. Start the Voice detection sensitivity test. 3. Quickly click Stop immediately after clicking Test. 4. It may take a few tries, but eventually the Voice detection sensitivity indicator remains stuck at the last detected level. > [!NOTE] > this is timing-dependent. A tic message must already be in-flight from the worklet thread when `disconnect()` runs, so it won't happen every attempt. This race condition existed in the `disconnect` callback of `_loadAudioWorkletProcessor` since #66611, but stayed silent until #183969 introduced the Voice detection sensitivity feature in call settings, exposing it. This PR clears `port.onmessage` before disconnecting so late tic messages can no longer update the Voice detection sensitivity indicator after monitoring has stopped. Forward-Port-Of: odoo/odoo#275933
Before this commit: If a user, with crm.leads linked to it, decided to request a password reset AND during that password reset process decided to activate the google oauth for their account, it would cause a crash. The reason is, during the password rest + oauth activation, self.env.user is an empty record set, which obviously will fail during the _is_portal check, due to its call to ensure_one() opw-6347228 Forward-Port-Of: odoo/odoo#275375
Original PR description
Before this commit: If a user, with crm.leads linked to it, decided to request a password reset AND during that password reset process decided to activate the google oauth for their account, it would cause a crash. The reason is, during the password rest + oauth activation, self.env.user is an empty record set, which obviously will fail during the _is_portal check, due to its call to ensure_one() opw-6347228 Forward-Port-Of: odoo/odoo#275375
Code cleanup and technical improvements
This update removes duplicate holiday-planning code because the same behavior is already provided by a related scheduling module. This reduces maintenance risk without changing how users manage planning or leave.
Original PR description
After commit e0b126c, `_handle_flexible_leave_interval` is already implemented in `hr_holidays_gantt` and covers the same case previously handled in `planning_holidays`. https://github.com/odoo/enterprise/blob/7ed917c1de11e29257a726efd4dafe403b9efba1/hr_holidays_gantt/models/resource_calendar.py#L17-L20 Since `planning_holidays` depends on `hr_holidays_gantt`, the duplicate implementation in `planning_holidays` is no longer necessary. **opw-6243778** Forward-Port-Of: odoo/enterprise#124477 Forward-Port-Of: odoo/enterprise#119229
7 changes
Resolved issues and error corrections
Since 414e55cf7c397, we can assign multiple users to a user-defined filter but because it's now a many2many, any user that got archived won't be shown in the `user_ids` fields anymore, it could mislead the filter being a global filter; whereas it's not. This commit also display archived users so we can see all users effectively assigned to the user-defined filter. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275841
Original PR description
Since 414e55cf7c397, we can assign multiple users to a user-defined filter but because it's now a many2many, any user that got archived won't be shown in the `user_ids` fields anymore, it could mislead the filter being a global filter; whereas it's not. This commit also display archived users so we can see all users effectively assigned to the user-defined filter. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275841
In previous refactor [1], we wrapped the "vat" field under a "vat_div" div. This broke some xpath depending on the "vat". This commit repair those views. [1]: https://github.com/odoo/odoo/commit/825e7c803a4effd601fb247c660416f1cc6d26d7 task-6382108
Original PR description
In previous refactor [1], we wrapped the "vat" field under a "vat_div" div. This broke some xpath depending on the "vat". This commit repair those views. [1]: https://github.com/odoo/odoo/commit/825e7c803a4effd601fb247c660416f1cc6d26d7 task-6382108
A previous commit updated the `commonExtraData` from `GeneratePrinterData` in order to update the style from the pdis tickets. However, since `commonExtraData` is used for both receipt and pdis tickets, the change caused a bug for receipts tickets. This commit reverts the `commonExtraData` and update the code in order to still have the correct data dunble for pdis tickets. --- FIX Task: https://www.odoo.com/odoo/project/1737/tasks/6133403 Forward-Port-Of: odoo/odoo#276909
Original PR description
A previous commit updated the `commonExtraData` from `GeneratePrinterData` in order to update the style from the pdis tickets. However, since `commonExtraData` is used for both receipt and pdis tickets, the change caused a bug for receipts tickets. This commit reverts the `commonExtraData` and update the code in order to still have the correct data dunble for pdis tickets. --- FIX Task: https://www.odoo.com/odoo/project/1737/tasks/6133403 Forward-Port-Of: odoo/odoo#276909
### Steps to reproduce: - Open the Todo app - In the editor, insert the following content: `<p>a</p><div class="oe_unbreakable"><br></div><p>b</p>` - Double-click the empty unbreakable node - Open the color picker and hover over a color - Toolbar and color picker get closed ### Root cause: - Hovering a color in an empty unbreakable node replaces the `<br>` with a `<font data-oe-zws-empty-inline>` containing a ZWS (`\u200b`). This triggers a selectionchange where `isToolbarVisible()`
Original PR description
### Steps to reproduce: - Open the Todo app - In the editor, insert the following content: `<p>a</p><div class="oe_unbreakable"><br></div><p>b</p>` - Double-click the empty unbreakable node - Open…
### Steps to reproduce: - Open the Todo app - In the editor, insert the following content: `<p>a</p><div class="oe_unbreakable"><br></div><p>b</p>` - Double-click the empty unbreakable node - Open the color picker and hover over a color - Toolbar and color picker get closed ### Root cause: - Hovering a color in an empty unbreakable node replaces the `<br>` with a `<font data-oe-zws-empty-inline>` containing a ZWS (`\u200b`). This triggers a selectionchange where `isToolbarVisible()` finds no `<br>` and no visible text, returns false, and closes the toolbar — which reverts the preview, reopens the toolbar, and causes a flicker loop. ### Solution: - Instead of calling `fillEmpty()` (which inserts a ZWS placeholder) on empty blocks containing `<br>` preserve the `<br>` element by appending it directly inside the `<font>` tag which keeps toolbar open. task-6312933 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276776 Forward-Port-Of: odoo/odoo#271507
### Issue: The 'Schedule an appointment' and 'Next Events' CTA buttons were not updated even when their conditions were satisfied. ### Steps to reproduce: - Install only Website. - In the configurator, choose 'Schedule Appointments' as the main objective. - Complete the setup and create the website. - The CTA button remains 'Contact Us' instead of 'Schedule an appointment'. ### Reason: The `get_cta_data()` method is overridden in specific modules to update the CTA button base
Original PR description
### Issue: The 'Schedule an appointment' and 'Next Events' CTA buttons were not updated even when their conditions were satisfied. ### Steps to reproduce: - Install only Website. - In the configurator, choose 'Schedule Appointments' as the main objective. - Complete the setup and create the website. - The CTA button remains 'Contact Us' instead of 'Schedule an appointment'. ### Reason: The `get_cta_data()` method is overridden in specific modules to update the CTA button based on conditions. However, it is called before those modules are installed, so the overridden logic is never executed. ### Fix: Ensure that `get_cta_data()` is called and the CTA button is updated after the required modules are installed. task-[6383681](https://www.odoo.com/odoo/project/974/tasks/6383681) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261781
[FIX] fleet: fix vendor bill vehicle association bug Bug reprod: Go to 19.2 or above 1 - Go to vendor bills. 2 - Create an invoice line add vehicle. 3 - Click to vehicle via the link 4 - You will see fleet model and try to press to some smart buttons, traceback will occur (Odometer, Services...) Bug cause: 1 - When we press to smart buttons for Odometer or Services we are going to return_action_to_open function. 2 - In this function corresponding action's
Original PR description
[FIX] fleet: fix vendor bill vehicle association bug Bug reprod: Go to 19.2 or above 1 - Go to vendor bills. 2 - Create an invoice line add vehicle. 3 - Click to vehicle via the link 4 - You will see…
[FIX] fleet: fix vendor bill vehicle association bug
Bug reprod: Go to 19.2 or above
1 - Go to vendor bills.
2 - Create an invoice line add vehicle.
3 - Click to vehicle via the link
4 - You will see fleet model and try to press to some smart buttons, traceback will occur (Odometer, Services...)
Bug cause:
1 - When we press to smart buttons for Odometer or Services we are going to return_action_to_open function.
2 - In this function corresponding action's xml id is calculated and we are calling that action and that will load some view.
3 - self.env.context is passed directly as a context
4 - In the view_move_form (That include invoice lines, account_id and vehicle_id fields), account_id has a context list_view_ref="account.view_account_list_from_entry"
5 - This context is passed in self.env.context and that's why it tries to load this list_view when we press to odometer,service smart buttons, which shouldn't be the case.
6 - In 19.1 this context is not in self.env.context because >=19.2 m2o_cell_with_extra_m2o_fields is used for account_id and account_id and vehicle_id fields are combined in the single cell.
7 - That's why the context of account_id is passed to the vehicle page as well.
Bug solution:
1 - In the return_action_to_open function I'm dropping the list_view_ref context and we can load the correct related views about odometer or service or other ones.
task - 6385611
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
Forward-Port-Of: odoo/odoo#276167Before this commit, a crash could occur in kanban views but it required a very precise timing. If 2 renderings of the kanban renderer occurred at the same time, one coming from a group that has just been opened, and one coming from a new groupby being applied in the search view, we tried to scroll to the opened group to ensure that it is in the viewport, but we couldn't find it. Task~6391414 Forward-Port-Of: odoo/odoo#276750 Forward-Port-Of: odoo/odoo#276488
Original PR description
Before this commit, a crash could occur in kanban views but it required a very precise timing. If 2 renderings of the kanban renderer occurred at the same time, one coming from a group that has just been opened, and one coming from a new groupby being applied in the search view, we tried to scroll to the opened group to ensure that it is in the viewport, but we couldn't find it. Task~6391414 Forward-Port-Of: odoo/odoo#276750 Forward-Port-Of: odoo/odoo#276488
22 changes
Enhancements to existing features
It is mandatory in BE to add a legal note on the invoice when using a "Co-Contractant" tax task-5905176 Forward-Port-Of: odoo/odoo#275388 Forward-Port-Of: odoo/odoo#251797
Original PR description
It is mandatory in BE to add a legal note on the invoice when using a "Co-Contractant" tax task-5905176 Forward-Port-Of: odoo/odoo#275388 Forward-Port-Of: odoo/odoo#251797
In multicompany, it can happen that one company (let's call it company Origin) cannot handle a payment method in their country, so it uses another company's (company MoneyHandler), even if it's in another country. The accounting flows must be then adjusted: - In company Origin, the invoice must be matched by a clearing entry - In company MoneyHandler, payment must match its move (if it exists) with a clearing entry. The payment move doesn't exist if `account_accountant` is installed but no O
Original PR description
In multicompany, it can happen that one company (let's call it company Origin) cannot handle a payment method in their country, so it uses another company's (company MoneyHandler), even if it's in…
In multicompany, it can happen that one company (let's call it company Origin) cannot handle a payment method in their country, so it uses another company's (company MoneyHandler), even if it's in another country. The accounting flows must be then adjusted: - In company Origin, the invoice must be matched by a clearing entry - In company MoneyHandler, payment must match its move (if it exists) with a clearing entry. The payment move doesn't exist if `account_accountant` is installed but no Outstanding account is configured on the payment method line. Same but opposite thing must happen for credit notes in company Origin that match a reimbursement in company MoneyHandler. Cancellation of a payment must be reflected on the entries: deleting when feasible, reversing when not (unless a lock date/hash is present, which would block the cancellation) _(To do: testing/review, credit note, cancellation/reversal of the payment)_ Task [link](https://www.odoo.com/odoo/project.task/6037525) task-6037525 Forward-Port-Of: odoo/odoo#259197
Resolved issues and error corrections
When creating or editing a portal billing address, the Company Name field was pre-filled from `commercial_company_name`. For contacts without a parent company, the commercial partner is the contact itself, so the contact name was shown as the company name. Use the partner's actual parent company name instead, so the field stays empty when no company is linked while still showing the existing parent company when one exists. see: https://github.com/odoo/odoo/commit/18a59cf26f2d9400f76deec483
Original PR description
When creating or editing a portal billing address, the Company Name field was pre-filled from `commercial_company_name`. For contacts without a parent company, the commercial partner is the contact itself, so the contact name was shown as the company name. Use the partner's actual parent company name instead, so the field stays empty when no company is linked while still showing the existing parent company when one exists. see: https://github.com/odoo/odoo/commit/18a59cf26f2d9400f76deec483f6ddab87da0c55 Task-6372638 Forward-Port-Of: odoo/odoo#274972
Problem: When a user attempts to create a new partner, and before saving the partner, they attempt to create a bank account in the same form view, they will be faced with a validation error for missing partner_id on the bank account. Solution: This commit solves this issue by only allowing the user to modify bank accounts for existing partners (with id). task-6373918
Original PR description
Problem: When a user attempts to create a new partner, and before saving the partner, they attempt to create a bank account in the same form view, they will be faced with a validation error for missing partner_id on the bank account. Solution: This commit solves this issue by only allowing the user to modify bank accounts for existing partners (with id). task-6373918
[1] added a bus channel for discuss categories. This can be done with or without any token. When the token is not passed, `verify_limited_field_access_token` is still called and crashes. When no token is provided, we should use category access rights instead and avoir verifying the token (which is `None`). [1]: https://github.com/odoo/odoo/pull/243131 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: ---
Original PR description
[1] added a bus channel for discuss categories. This can be done with or without any token. When the token is not passed, `verify_limited_field_access_token` is still called and crashes. When no token is provided, we should use category access rights instead and avoir verifying the token (which is `None`). [1]: https://github.com/odoo/odoo/pull/243131 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
### STEPS TO REPRODUCE: 1. Install AI, Livechat, and Website 2. Open Livechat and create a new channel 3. Ensure there is a welcome message 4. Add a rule with any AI Agent 5. Navigate to Settings > Website, enable Live Chat, and select the channel you just created 6. Go to the Website, click on the chat bubble, and verify that the first message shows "unnamed" as the sender of the welcome message ### CAUSE When a default message exists, the `author_id` is resolved by looking at the c
Original PR description
### STEPS TO REPRODUCE: 1. Install AI, Livechat, and Website 2. Open Livechat and create a new channel 3. Ensure there is a welcome message 4. Add a rule with any AI Agent 5. Navigate to Settings > Website, enable Live Chat, and select the channel you just created 6. Go to the Website, click on the chat bubble, and verify that the first message shows "unnamed" as the sender of the welcome message ### CAUSE When a default message exists, the `author_id` is resolved by looking at the current channel's history. However, it only checks `livechat_agent_history_ids`. Since a bot can also send the welcome message instead of an agent, `livechat_bot_history_ids` should also be checked.
A previous commit updated the `commonExtraData` from `GeneratePrinterData` in order to update the style from the pdis tickets. However, since `commonExtraData` is used for both receipt and pdis tickets, the change caused a bug for receipts tickets. This commit reverts the `commonExtraData` and update the code in order to still have the correct data dunble for pdis tickets. --- FIX Task: https://www.odoo.com/odoo/project/1737/tasks/6133403
Original PR description
A previous commit updated the `commonExtraData` from `GeneratePrinterData` in order to update the style from the pdis tickets. However, since `commonExtraData` is used for both receipt and pdis tickets, the change caused a bug for receipts tickets. This commit reverts the `commonExtraData` and update the code in order to still have the correct data dunble for pdis tickets. --- FIX Task: https://www.odoo.com/odoo/project/1737/tasks/6133403
The service worker required for push notifications is only available to internal users. This commit fixes the test setup by ensuring non-internal users are no longer registered, matching the expected flow. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269210
Original PR description
The service worker required for push notifications is only available to internal users. This commit fixes the test setup by ensuring non-internal users are no longer registered, matching the expected flow. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269210
Steps to reproduce: 1. Drop a .s_tabs snippet 2. Click inside a tab to move the selection in it 3. Press backspace (remove each tab name + the last one should be empty) 4. Click on the "+" in the sidebar to add a Tab => Crash or on step 3: 3. Press backspace to delete one tab => Check the DOM: the tab has been removed, but the tab-pane element is still in the DOM and won't be deleted. This is easily fixed by adding `oe_unremovable` on tab links. task-4671317 Forward-Port-Of: odo
Original PR description
Steps to reproduce: 1. Drop a .s_tabs snippet 2. Click inside a tab to move the selection in it 3. Press backspace (remove each tab name + the last one should be empty) 4. Click on the "+" in the sidebar to add a Tab => Crash or on step 3: 3. Press backspace to delete one tab => Check the DOM: the tab has been removed, but the tab-pane element is still in the DOM and won't be deleted. This is easily fixed by adding `oe_unremovable` on tab links. task-4671317 Forward-Port-Of: odoo/odoo#275240
The partner credit limit warning on quotations and customer invoices depends on which company the user is currently working in, instead of the company of the document itself. Steps to reproduce: - Enable Sale Credit Limit in the settings of My Company (San Francisco) - Set a Credit Limit of 100 on a customer, e.g. Deco Addict - Create a draft quotation of 500 for that customer => The credit limit warning banner is displayed, as expected - Switch the active company to any other company, fo
Original PR description
The partner credit limit warning on quotations and customer invoices depends on which company the user is currently working in, instead of the company of the document itself. Steps to reproduce: -…
The partner credit limit warning on quotations and customer invoices depends on which company the user is currently working in, instead of the company of the document itself. Steps to reproduce: - Enable Sale Credit Limit in the settings of My Company (San Francisco) - Set a Credit Limit of 100 on a customer, e.g. Deco Addict - Create a draft quotation of 500 for that customer => The credit limit warning banner is displayed, as expected - Switch the active company to any other company, for example My Company (Chicago), keeping access to both companies - Open the same quotation again => The warning banner is gone, although neither the quotation nor the customer changed The credit fields used to build the warning are evaluated against the user's active company: credit_limit is a company-dependent field, and credit / credit_to_invoice are computed on the receivables of the current company. When the active company is not the document's company, the warning is checked against the wrong ledger and the wrong limit, so it can disappear on an over-limit customer or show up for a healthy one. Both computes already contain the line that was meant to handle this, but the result of with_company() was discarded, making it a no-op. Assign it, as every other compute in these files already does, so the warning is always evaluated in the document's company. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276308
\* : html_editor Commit [1]: Steps to reproduce: replacing image stuck issue when deleted 1. Go to Website > Edit. 2. Add any picture snippet (e.g., Text-Image). 3. Click the 'Replace' button and upload an image. 4. Open the media dialog again and delete the uploaded image. 5. Click the 'Discard' button. 6. Try to save the changes. Issue: - The website gets stuck in the same position and does not allow saving. - In the Python terminal, a missing error warning appears because the
Original PR description
\* : html_editor Commit [1]: Steps to reproduce: replacing image stuck issue when deleted 1. Go to Website > Edit. 2. Add any picture snippet (e.g., Text-Image). 3. Click the 'Replace' button and…
\* : html_editor Commit [1]: Steps to reproduce: replacing image stuck issue when deleted 1. Go to Website > Edit. 2. Add any picture snippet (e.g., Text-Image). 3. Click the 'Replace' button and upload an image. 4. Open the media dialog again and delete the uploaded image. 5. Click the 'Discard' button. 6. Try to save the changes. Issue: - The website gets stuck in the same position and does not allow saving. - In the Python terminal, a missing error warning appears because the image is deleted from both `ir.ui.view` and `ir.attachment`. Expected behaviour: - Saving should be allowed with a default image, that is similar to other images. This commit catch the warning response and replaces the deleted image, allowing the website to save changes without getting stuck. Commit [2]: resolve traceback when leaving edit mode via browser Steps to reproduce: 1. Go to Website > Edit. 2. Open the snippet modal and select any snippet. 3. Press the 'Back' button in your browser. 4. A dialog will appear asking to discard changes; click 'OK'. 5. A traceback error occurs, and an empty space appears in the editor. Issue: - Previously, a commit addressed a similar scenario, but that time the browser had an event listener bind on hashchange. - Now, that `hashchange` event of browser has been replaced with `popstate`, which triggers before the 'window' event listener. - As a result, the editor is left in an unstable state, causing a traceback error. Solution: - This commit ensures the 'window' event executes before the browser event. - It verifies if the editor is open and forces a `skipLoad`, preventing the `route_change` call in the browser. task-4570164 Forward-Port-Of: odoo/odoo#275334 Forward-Port-Of: odoo/odoo#199193
Issue: There is a missing closing curly bracket on line 67 in odoo/addons/stock/static/src/stock_forecasted/forecasted_details.xml (View) This PR corrects this error opw-6367046 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274575
Original PR description
Issue: There is a missing closing curly bracket on line 67 in odoo/addons/stock/static/src/stock_forecasted/forecasted_details.xml (View) This PR corrects this error opw-6367046 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274575
The "Opening thread with needaction messages should mark all messages of thread as read" test opens a channel that holds an inbox (needaction) message and asserts mark_all_as_read is sent. Two flows can mark that message as read: the channel messages fetch, through set_message_done, and mark_all_as_read, sent by markAsRead when the channel gets focused on open. When the self member's new_message_separator is 0, opening the channel fetches its messages around 0, and that fetch marks the messag
Original PR description
The "Opening thread with needaction messages should mark all messages of thread as read" test opens a channel that holds an inbox (needaction) message and asserts mark_all_as_read is sent. Two flows can mark that message as read: the channel messages fetch, through set_message_done, and mark_all_as_read, sent by markAsRead when the channel gets focused on open. When the self member's new_message_separator is 0, opening the channel fetches its messages around 0, and that fetch marks the message as read and drops the needaction counter to 0 before markAsRead runs. mark_all_as_read is then skipped and the step assertion receives nothing. Give the member a non-zero separator (the pre-existing message is already read) so opening the channel no longer fetches around 0, leaving mark_all_as_read as the flow that marks the inbox message read. https://runbot.odoo.com/odoo/error/243651 Forward-Port-Of: odoo/odoo#276181
**Purpose of this PR:** Before this PR, the Voice detection sensitivity indicator in call settings could get stuck showing the last detected level after clicking "Stop" right after "Test". The `AudioWorkletNode`'s port kept receiving tic messages briefly after `disconnect()`, since disconnecting only unroutes the audio graph and does not stop the worklet from posting pending messages. <img width="546" height="73" alt="voice_test_bug" src="https://github.com/user-attachments/assets/05a10d23
Original PR description
**Purpose of this PR:** Before this PR, the Voice detection sensitivity indicator in call settings could get stuck showing the last detected level after clicking "Stop" right after "Test". The…
**Purpose of this PR:** Before this PR, the Voice detection sensitivity indicator in call settings could get stuck showing the last detected level after clicking "Stop" right after "Test". The `AudioWorkletNode`'s port kept receiving tic messages briefly after `disconnect()`, since disconnecting only unroutes the audio graph and does not stop the worklet from posting pending messages. <img width="546" height="73" alt="voice_test_bug" src="https://github.com/user-attachments/assets/05a10d23-fe60-4a85-b906-bfec6d235ec5" /> Steps to reproduce: 1. Open Voice & Video Settings. 2. Start the Voice detection sensitivity test. 3. Quickly click Stop immediately after clicking Test. 4. It may take a few tries, but eventually the Voice detection sensitivity indicator remains stuck at the last detected level. > [!NOTE] > this is timing-dependent. A tic message must already be in-flight from the worklet thread when `disconnect()` runs, so it won't happen every attempt. This race condition existed in the `disconnect` callback of `_loadAudioWorkletProcessor` since #66611, but stayed silent until #183969 introduced the Voice detection sensitivity feature in call settings, exposing it. This PR clears `port.onmessage` before disconnecting so late tic messages can no longer update the Voice detection sensitivity indicator after monitoring has stopped. Forward-Port-Of: odoo/odoo#275933
When a push subscription is renewed by the browser (typically every few days), the pushsubscriptionchange event fires and the service worker attempts to re-register the new subscription endpoint via register_devices(). However, the VAPID public key was missing from the request kwargs. The server-side register_devices() always validates the VAPID key first and raises InvalidVapidError when it is absent. This caused the renewed subscription to never be saved in the database, silently breaking p
Original PR description
When a push subscription is renewed by the browser (typically every few days), the pushsubscriptionchange event fires and the service worker attempts to re-register the new subscription endpoint via…
When a push subscription is renewed by the browser (typically every few days), the pushsubscriptionchange event fires and the service worker attempts to re-register the new subscription endpoint via register_devices(). However, the VAPID public key was missing from the request kwargs. The server-side register_devices() always validates the VAPID key first and raises InvalidVapidError when it is absent. This caused the renewed subscription to never be saved in the database, silently breaking push notifications after the first subscription renewal. Fix by extracting the applicationServerKey from the new subscription's options and encoding it as a base64url string (without padding) — matching the existing logic in webclient.js _arrayBufferToBase64(). Description of the issue/feature this PR addresses: Current behavior before PR: Subscriptions don't get renewed causing push notifications to stop eventually. Desired behavior after PR is merged: Subscriptions get renewed successfully. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276085 Forward-Port-Of: odoo/odoo#275217
This fixes two bugs in the web push subscription flow: - register_devices() compared partner records with 'is not' instead of '!='. Records loaded via sudo() live in a different environment than self.env.user, so 'is not' was always True and the ownership guard never behaved as intended. Use '!=', which compares record identity by model and id as Odoo's ORM intends. - webclient.js sent the previous subscription endpoint under the snake_case key 'previous_endpoint', while the server reads i
Original PR description
This fixes two bugs in the web push subscription flow:
- register_devices() compared partner records with 'is not' instead of '!='. Records loaded via sudo() live in a different environment than self.env.user, so 'is not' was always True and the ownership guard never behaved as intended. Use '!=', which compares record identity by model and id as Odoo's ORM intends.
- webclient.js sent the previous subscription endpoint under the snake_case key 'previous_endpoint', while the server reads it as 'previousEndpoint' (kw.get('previousEndpoint', endpoint)). The mismatch meant the lookup always fell back to the new endpoint, so a refreshed subscription created a duplicate device instead of updating the existing one. Send the camelCase key to match the server.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#276082Since 414e55cf7c397, we can assign multiple users to a user-defined filter but because it's now a many2many, any user that got archived won't be shown in the `user_ids` fields anymore, it could mislead the filter being a global filter; whereas it's not. This commit also display archived users so we can see all users effectively assigned to the user-defined filter. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275841
Original PR description
Since 414e55cf7c397, we can assign multiple users to a user-defined filter but because it's now a many2many, any user that got archived won't be shown in the `user_ids` fields anymore, it could mislead the filter being a global filter; whereas it's not. This commit also display archived users so we can see all users effectively assigned to the user-defined filter. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275841
Remove the generic active 296 and 297 impairment accounts and make the existing French PCG 296/297 subaccounts active instead, because what we use in the balance sheet formulas are the subaccounts, and it's better to remove the generic ones to not give users the ability to post on these generic accounts, also adapt their translations to be aligned with PCG wording. Move pcg_2962 from the companies chart file to the base French chart file, as 2962 is a general PCG account and not a compa
Original PR description
Remove the generic active 296 and 297 impairment accounts and make the existing French PCG 296/297 subaccounts active instead, because what we use in the balance sheet formulas are the subaccounts, and it's better to remove the generic ones to not give users the ability to post on these generic accounts, also adapt their translations to be aligned with PCG wording. Move pcg_2962 from the companies chart file to the base French chart file, as 2962 is a general PCG account and not a company related one. Note: this is how things were already in 19.0 and this is how they should be, the changes happened by mistake as an unwanted side effect of commit 4f6068a6c88bf0530c19254df403e1194823b415 task-[6226138](https://www.odoo.com/odoo/project/967/tasks/6226138) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265196
### Overview The SMS Queue Manager cron throws a traceback in a multi company environment when processing sms's that belong to distinct companies. ### Changes Before this commit, the _process_queue method tied to the cron was blindly batching sms's belonging to multiple companies without an sms_api context. The error results because the _send method that's called expects a singleton company when it tries to set the sms_api for the record set, but this isn't the case when the selected sm
Original PR description
### Overview The SMS Queue Manager cron throws a traceback in a multi company environment when processing sms's that belong to distinct companies. ### Changes Before this commit, the _process_queue…
### Overview The SMS Queue Manager cron throws a traceback in a multi company environment when processing sms's that belong to distinct companies. ### Changes Before this commit, the _process_queue method tied to the cron was blindly batching sms's belonging to multiple companies without an sms_api context. The error results because the _send method that's called expects a singleton company when it tries to set the sms_api for the record set, but this isn't the case when the selected sms batch is multi company. After this commit, the _process_queue method now follows the same pattern as the send method, grouping by sms_api / company within the batch, and eliminating the need to check for singleton, as all calls to _send will now have the sms_api context passed in. ### Steps to Reproduce on fresh 19.0 db: 1. Make sure sms / sms_twilio are installed. 2. Create two companies with their own SMS config. 3. Create two sms records, one with each company. 4. Ensure the state of the sms's is 'outgoing'. 5. Execute the SMS Queue Manager Cron. Observe the traceback: ValueError: Expected singleton... opw-6371272 Forward-Port-Of: odoo/odoo#276426
Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price unit. However, in Colombia, the DIAN treats the PriceAmount node as the exact price unit. This was not flagged in the system so the parser incorrectly divides the PriceAmount by BaseQuantity, resulting in negative discounts to be added to match the subtotal. Solution: Extract the basis_qty logic into
Original PR description
Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price…
Problem: When importing XML files to generate vendor bills, the system uses UBL parser and assumes that the PriceAmount node needs to be divided by the BaseQuantity node to obtain the exact price unit. However, in Colombia, the DIAN treats the PriceAmount node as the exact price unit. This was not flagged in the system so the parser incorrectly divides the PriceAmount by BaseQuantity, resulting in negative discounts to be added to match the subtotal. Solution: Extract the basis_qty logic into a helper method so other localizations can override when needed. Current behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets incorrectly divided, resulting in negative discounts on the vendor bill. Expected Behavior: When importing a Colombian XML with a product that has a BaseQuantity greater than 1, the PriceAmount gets parses as the exact unit price with no negative discounts applied. Task [link](https://www.odoo.com/odoo/project.task/6215466) task-6215466 Forward-Port-Of: odoo/odoo#276430 Forward-Port-Of: odoo/odoo#273129
Before this commit: If a user, with crm.leads linked to it, decided to request a password reset AND during that password reset process decided to activate the google oauth for their account, it would cause a crash. The reason is, during the password rest + oauth activation, self.env.user is an empty record set, which obviously will fail during the _is_portal check, due to its call to ensure_one() opw-6347228 Forward-Port-Of: odoo/odoo#275375
Original PR description
Before this commit: If a user, with crm.leads linked to it, decided to request a password reset AND during that password reset process decided to activate the google oauth for their account, it would cause a crash. The reason is, during the password rest + oauth activation, self.env.user is an empty record set, which obviously will fail during the _is_portal check, due to its call to ensure_one() opw-6347228 Forward-Port-Of: odoo/odoo#275375
Steps to reproduce: - Go to Website - Upload an image in the company logo (navbar) - Open the website editor and click on the logo - Open the image info panel Current behavior: When clicking on the website logo in the editor, the size shown is always a constant number ~5.9kB, regardless of the actual size of the uploaded logo. The correct size is visible in the browser DOM. This gives users the wrong impression that their image is being heavily compressed or losing quality when it isn'
Original PR description
Steps to reproduce: - Go to Website - Upload an image in the company logo (navbar) - Open the website editor and click on the logo - Open the image info panel Current behavior: When clicking on the…
Steps to reproduce: - Go to Website - Upload an image in the company logo (navbar) - Open the website editor and click on the logo - Open the image info panel Current behavior: When clicking on the website logo in the editor, the size shown is always a constant number ~5.9kB, regardless of the actual size of the uploaded logo. The correct size is visible in the browser DOM. This gives users the wrong impression that their image is being heavily compressed or losing quality when it isn't. Reason: When clicking the logo, the editor tries to find the original, unprocessed version of the image so it can support cropping and other edits. It does this by asking the server to match the image's URL to a stored attachment. The website logo is served through a dynamic link (`/web/image/website/<id>/logo/<name>`) that isn't tied to a regular attachment record the way normal content images are, since it isn't uploaded through the usual media picker. Because of this, the server can't find a matching original, and the editor is left without a valid image source to work with. As a fallback, the editor tries to load a placeholder path instead of a real image. This request fails and silently resolves to Odoo's generic "image not found" placeholder. All further processing (and the size calculation) then happens on this small placeholder image instead of the actual logo, which is why the size shown never changes. Fix: When `get_image_info` does not return a usable `original`, `loadImageInfo` now falls back to using the image's own current src as `originalSrc`, instead of leaving it unset. This ensures `loadImage` always receives a valid, resolvable URL, so image processing (and the size shown) reflects the actual logo. opw-6260496 Forward-Port-Of: odoo/odoo#273542
9 changes
New functionality added to Odoo
### Description of the issue/feature this PR addresses: Adds the Saudi ZATCA identification fields (building number, plot identification, identification scheme/number) to the portal billing address form so customers can fill them themselves. ### Current behavior before PR: The fields exist only in the backend; portal customers can't enter them. ### Desired behavior after PR is merged: Saudi-company customers can fill the fields on the portal (shown only when the billing country is SA
Original PR description
### Description of the issue/feature this PR addresses: Adds the Saudi ZATCA identification fields (building number, plot identification, identification scheme/number) to the portal billing address form so customers can fill them themselves. ### Current behavior before PR: The fields exist only in the backend; portal customers can't enter them. ### Desired behavior after PR is merged: Saudi-company customers can fill the fields on the portal (shown only when the billing country is SA; number disabled for the TIN scheme, with server-side validation). task-5188361 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270973
Enhancements to existing features
Move French e-invoicing technical statuses out of the main invoice UI and into the chatter. The PPF status is kept available in debug mode for troubleshooting, while regular users get a concise chatter summary with the PA status, PPF status, and any returned errors. Duplicate Lifecycle XML attachments are no longer posted in the chatter. Task-6273270 Forward-Port-Of: odoo/odoo#276770 Forward-Port-Of: odoo/odoo#269465
Original PR description
Move French e-invoicing technical statuses out of the main invoice UI and into the chatter. The PPF status is kept available in debug mode for troubleshooting, while regular users get a concise chatter summary with the PA status, PPF status, and any returned errors. Duplicate Lifecycle XML attachments are no longer posted in the chatter. Task-6273270 Forward-Port-Of: odoo/odoo#276770 Forward-Port-Of: odoo/odoo#269465
Resolved issues and error corrections
Before this commit: If a user, with crm.leads linked to it, decided to request a password reset AND during that password reset process decided to activate the google oauth for their account, it would cause a crash. The reason is, during the password rest + oauth activation, self.env.user is an empty record set, which obviously will fail during the _is_portal check, due to its call to ensure_one() opw-6347228 Forward-Port-Of: odoo/odoo#275375
Original PR description
Before this commit: If a user, with crm.leads linked to it, decided to request a password reset AND during that password reset process decided to activate the google oauth for their account, it would cause a crash. The reason is, during the password rest + oauth activation, self.env.user is an empty record set, which obviously will fail during the _is_portal check, due to its call to ensure_one() opw-6347228 Forward-Port-Of: odoo/odoo#275375
Currently, overlays remain open when the POS screensaver is loaded [^1]. #### Steps to reproduce: - Open the POS interface. - Open a dropdown/popover menu (e.g., the navbar hamburger menu). - Wait for the screensaver (SaverScreen) to trigger due to inactivity. - The open dropdown menu remains visible on top of the screensaver. #### Issue Dropdowns and popovers are rendered as active overlays outside the main screen container. While the screensaver setup closes active dialogs, it doe
Original PR description
Currently, overlays remain open when the POS screensaver is loaded [^1]. #### Steps to reproduce: - Open the POS interface. - Open a dropdown/popover menu (e.g., the navbar hamburger menu). - Wait for the screensaver (SaverScreen) to trigger due to inactivity. - The open dropdown menu remains visible on top of the screensaver. #### Issue Dropdowns and popovers are rendered as active overlays outside the main screen container. While the screensaver setup closes active dialogs, it does not handle active overlays. #### Fix Retrieve the overlay service in SaverScreen and close all active overlays during its setup phase using a dedicated `closeAllOverlays` method. [^1]:  Forward-Port-Of: odoo/odoo#276672 Forward-Port-Of: odoo/odoo#274716
#### Description of the issue this PR addresses: - Tables containing only a `<caption>` (or a `<thead>` without a `<tbody>`) could reach the editor with no `<tbody>`. - Since table width and margin are moved to the `<tbody>` during setup in 19.0–19.2, such tables caused the editor to fail. - Table operations such as resizing and adding rows or columns also expect a `<tbody>` to exist. #### Desired behavior after PR is merged: - Tables without a `<tbody>` are normalized during editor setup
Original PR description
#### Description of the issue this PR addresses: - Tables containing only a `<caption>` (or a `<thead>` without a `<tbody>`) could reach the editor with no `<tbody>`. - Since table width and margin are moved to the `<tbody>` during setup in 19.0–19.2, such tables caused the editor to fail. - Table operations such as resizing and adding rows or columns also expect a `<tbody>` to exist. #### Desired behavior after PR is merged: - Tables without a `<tbody>` are normalized during editor setup. - `<thead>` is converted or merged into `<tbody>`. - A missing `<tbody>` is created when necessary, preventing the editor from crashing. task-6391354 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#276588
### Issue: The 'Schedule an appointment' and 'Next Events' CTA buttons were not updated even when their conditions were satisfied. ### Steps to reproduce: - Install only Website. - In the configurator, choose 'Schedule Appointments' as the main objective. - Complete the setup and create the website. - The CTA button remains 'Contact Us' instead of 'Schedule an appointment'. ### Reason: The `get_cta_data()` method is overridden in specific modules to update the CTA button base
Original PR description
### Issue: The 'Schedule an appointment' and 'Next Events' CTA buttons were not updated even when their conditions were satisfied. ### Steps to reproduce: - Install only Website. - In the configurator, choose 'Schedule Appointments' as the main objective. - Complete the setup and create the website. - The CTA button remains 'Contact Us' instead of 'Schedule an appointment'. ### Reason: The `get_cta_data()` method is overridden in specific modules to update the CTA button based on conditions. However, it is called before those modules are installed, so the overridden logic is never executed. ### Fix: Ensure that `get_cta_data()` is called and the CTA button is updated after the required modules are installed. task-[6383681](https://www.odoo.com/odoo/project/974/tasks/6383681) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261781
Steps to reproduce: ------------------- - Install `mrp` and `sale_management` modules - Enable Units of Measure from settings - Create a storable product configured as a Kit: - Set UoM to Units - Add component and it's UoM in Kg in Product form. - Create and confirm a Sales Order with the kit product - Validate the generated delivery order - Print the delivery slip Issue: ------ The delivery slip correctly displays component quantities in Kg, but also shows an additional conve
Original PR description
Steps to reproduce: ------------------- - Install `mrp` and `sale_management` modules - Enable Units of Measure from settings - Create a storable product configured as a Kit: - Set UoM to Units - Add…
Steps to reproduce:
-------------------
- Install `mrp` and `sale_management` modules
- Enable Units of Measure from settings
- Create a storable product configured as a Kit:
- Set UoM to Units
- Add component and it's UoM in Kg in Product form.
- Create and confirm a Sales Order with the kit product
- Validate the generated delivery order
- Print the delivery slip
Issue:
------
The delivery slip correctly displays component quantities in Kg,
but also shows an additional converted quantity in Units (e.g., 1000 Units),
which is incorrect and misleading.
Cause:
------
During sale order confirmation, the following flow is executed:
`action_confirm → _action_confirm → _action_launch_stock_rule → _prepare_procurement_values`
In `_prepare_procurement_values`, the `packaging_uom_id` is set from the
sale order line UoM (Units) and propagated to the generated stock move:
https://github.com/odoo/odoo/blob/647febbf46160c000bf11af8325cc80d0916eb67/addons/sale_stock/models/sale_order_line.py#L296
When the delivery (picking) is created, kit components generate stock moves where:
- `product_uom` is defined in the component’s UoM (e.g., Kg)
- `packaging_uom_id` remains in Units (inherited from the sale order line)
While generating the delivery slip, `_get_aggregated_product_quantities`
computes `packaging_quantity` using `packaging_uom_id`:
https://github.com/odoo/odoo/blob/647febbf46160c000bf11af8325cc80d0916eb67/addons/stock/models/stock_move_line.py#L888
In Mrp this calls the template:
`stock_report_delivery_aggregated_move_lines`
https://github.com/odoo/odoo/blob/647febbf46160c000bf11af8325cc80d0916eb67/addons/mrp/report/report_deliveryslip.xml#L60
In this template, a condition renders packaging quantities when
`packaging_uom_id` differs from `product_uom`. As a result, quantities are
converted from the component UoM (Kg) into the packaging UoM (Units).
https://github.com/odoo/odoo/blob/647febbf46160c000bf11af8325cc80d0916eb67/addons/stock/report/report_deliveryslip.xml#L261
For kit components, this conversion is not meaningful and leads to incorrect
values (e.g., Kg → Units resulting in 1000 Units), causing misleading output
in the delivery slip.
Fix:
----
Add a `_compute_packaging_uom_id` override in `sale_mrp` and
`purchase_mrp` that resets `packaging_uom_id` back to
the component's own `product_uom` whenever the move originates from a
phantom BoM line, without touching `sale_line_id`/`purchase_line_id`
themselves.
<details>
<summary>Click here to see the results:</summary>
<p><strong>Before:</strong></p>
<div class="image-row">
<img src="https://github.com/user-attachments/assets/5d8b2154-d794-4ce4-90a6-1a0aeaca8604" />
</div>
<p><strong>After:</strong></p>
<div class="image-row">
<img src="https://github.com/user-attachments/assets/79d708de-19e3-452d-9033-322a297c38e9" />
</div>
</details>
---
opw-6136928
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#262705It can happen that _ref_vat has some lazy translate object. Without the self.env._ the translation would be ignored. (no translation language detected, skipping translation) runbot-941504 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275561
Original PR description
It can happen that _ref_vat has some lazy translate object. Without the self.env._ the translation would be ignored. (no translation language detected, skipping translation) runbot-941504 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275561
Features or functions removed from Odoo
Description of the issue/feature this PR addresses: Removed obsolete code checking "this.config.self_ordering_mode !== 'qr_code'". Since "qr_code" is not a valid value of the "self_ordering_mode" selection field. The condition is always true. Forward-Port-Of: odoo/odoo#276321 Forward-Port-Of: odoo/odoo#273245
Original PR description
Description of the issue/feature this PR addresses: Removed obsolete code checking "this.config.self_ordering_mode !== 'qr_code'". Since "qr_code" is not a valid value of the "self_ordering_mode" selection field. The condition is always true. Forward-Port-Of: odoo/odoo#276321 Forward-Port-Of: odoo/odoo#273245
2 changes
Resolved issues and error corrections
**Issue 1:** Steps to reproduce: - Install the `l10n_ar` module. - Go to Customers and create a new customer with the country set to Argentina. - Set `Identification Type` to `CUIL` and `Identification Number` to `1234567890a`. **Error:** `ValueError: invalid literal for int() with base 10: '1234567890a'` **Issue 2:** - Set `Identification Type` to any type other than `CUIT`, `DNI`, or `CUIL`. - Set `Identification Number` to `1234567890a`. **Observation:** All non-digit chara
Original PR description
**Issue 1:** Steps to reproduce: - Install the `l10n_ar` module. - Go to Customers and create a new customer with the country set to Argentina. - Set `Identification Type` to `CUIL` and…
**Issue 1:** Steps to reproduce: - Install the `l10n_ar` module. - Go to Customers and create a new customer with the country set to Argentina. - Set `Identification Type` to `CUIL` and `Identification Number` to `1234567890a`. **Error:** `ValueError: invalid literal for int() with base 10: '1234567890a'` **Issue 2:** - Set `Identification Type` to any type other than `CUIT`, `DNI`, or `CUIL`. - Set `Identification Number` to `1234567890a`. **Observation:** All non-digit characters are stripped, and the identification number is silently changed to `1234567890`. **Expected behaviour:** Any Identification Type other than CUIT (80), CUIL (86), and DNI (96) should be kept unchanged without stripping alphabetic characters. **Root Cause:** At [1], `_get_id_number_sanitize` sanitizes identification numbers based on the selected Identification Type. - For `CUIT` and `CUIL`, `stdnum.ar.cuit.compact()` only removes separators (e.g., spaces and dashes). If the identification number contains alphabetic characters, they are preserved and called `int()` on the resulting value, raising a `ValueError`. - For all other identification types, valid alphanumeric values are unintentionally modified by stripping non-digit characters. **Fix:** This commit validates identification numbers before sanitization for `CUIT` (80), `CUIL` (86), and `DNI` (96), ensuring only valid numeric identification numbers are converted. For all other identification types, it preserves alphanumeric characters by removing only non-alphanumeric separators. [1]: https://github.com/odoo/odoo/blob/08b75d753c638e9d2d7418b55e9107bda471cb31/addons/l10n_ar/models/res_partner.py#L124-L136 Related enterrpise PR: https://github.com/odoo/enterprise/pull/123729 opw-6333998
### Issue: The 'Schedule an appointment' and 'Next Events' CTA buttons were not updated even when their conditions were satisfied. ### Steps to reproduce: - Install only Website. - In the configurator, choose 'Schedule Appointments' as the main objective. - Complete the setup and create the website. - The CTA button remains 'Contact Us' instead of 'Schedule an appointment'. ### Reason: The `get_cta_data()` method is overridden in specific modules to update the CTA button base
Original PR description
### Issue: The 'Schedule an appointment' and 'Next Events' CTA buttons were not updated even when their conditions were satisfied. ### Steps to reproduce: - Install only Website. - In the configurator, choose 'Schedule Appointments' as the main objective. - Complete the setup and create the website. - The CTA button remains 'Contact Us' instead of 'Schedule an appointment'. ### Reason: The `get_cta_data()` method is overridden in specific modules to update the CTA button based on conditions. However, it is called before those modules are installed, so the overridden logic is never executed. ### Fix: Ensure that `get_cta_data()` is called and the CTA button is updated after the required modules are installed. task-[6383681](https://www.odoo.com/odoo/project/974/tasks/6383681) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261781
21 changes
Security fixes and vulnerability patches
This change prevents database API keys from being exposed through regular application access or accidentally shown in the user interface. It reduces the risk of sensitive credentials being leaked during normal use, including screen sharing or streaming.
Original PR description
The aim of this commit is to harden the security of the `database_api_key` field. Before this commit: The field could be retrieved through the orm and could be leaked if the access rights were bypassed. A streamer pasting the key in the field could also leak his api key by mistake. After this commit: The only way to access the field is through direct SQL access. The api key isn't shown anymore in the UI: - The UI doesn't receive the key from the backend: it receives dummy **** - The field in the form view display dots instead of any char to prevent leaking the key by mistake. Task-id: None Forward-Port-Of: odoo/enterprise#124277 Forward-Port-Of: odoo/enterprise#122163
Enhancements to existing features
Saudi Arabian currency rate updates now use the Saudi Central Bank as the dedicated source instead of the default xe.com provider. This improves alignment with official SAR exchange rates and avoids duplicate rate entries when several days of data are returned.
Original PR description
Added a new exchange rate provider for the Saudi Central Bank (SAMA) to fetch official SAR exchange rates. Saudi Arabia is removed from the xe.com default and mapped to this dedicated provider instead. Since the API response includes multiple days of data, duplicate currency entries are deduplicated by keeping the first (most recent) occurrence of each currency code. task-4422561
Customer notes now appear as warnings on billable helpdesk tickets and field service shift forms. This helps service teams see important sales or customer information before working on a ticket or scheduled visit.
Original PR description
- When there is a note on a customer, display it as a warning: - in the ticket form view, if the team is billable - shift form view - move `use_helpdesk_sale_timesheet` from `helpdesk_sale_timesheet` into `helpdesk_sale` --- Task-4910696
This improvement creates redirects from old product links to their new Odoo product pages when moving from another ecommerce platform. It helps businesses retain SEO value and avoid broken product links after transferring an old domain.
Original PR description
When switching from an ecommerce platform to another, a major issue is that all the links to your products change and so all of the SEO linked to those product links are lost. One way to mitigate this issue is to create redirects for each products. Once the old domain is transfered, the old product links are restored and redirect to the corresponding odoo products.
Obox remote debugging can now be enabled directly from the Obox form instead of asking customers to visit a special device URL. This makes support sessions easier to start by letting users provide the required Tailscale token in Odoo.
Original PR description
Before this commit, enabling remote debug for an Obox required accessing a specific URL on the Obox, which might be difficult to instruct clients to do. After this commit, there is a Remote Debug toggle in the Obox form view, just like the IoT box. A user simply needs to provide the Tailscale token to enable remote debug. task-6392868
The paid appointments module no longer creates a default booking fee product during installation, keeping databases cleaner for businesses that do not use paid appointments. A booking product is now created only when needed for paid appointment types, and unused unsold booking products can be removed.
Original PR description
# Purpose Installing the module "appointment_account_payment" creates a default product called "booking fees" used in paid appointment type. This auto-creation pollutes the DB of users that never uses such appointment types. Furthermore, the product couldn't be deleted once created. # Specs - Removed the creation of a default booking product upon module installation. - On the creation of a paid appointment type, will create a default product ready for edition by the user. - On manual checkbox activation, a product with a default price can be created through the dropdown menu. - Unused booking product that haven't been sold can be deleted. Task-6167887
Users can now apply common reconciliation actions to multiple selected bank statement lines at once. This reduces repetitive work by letting teams use the main action, assign partners, or set account numbers across several records in one step.
Original PR description
Added actions for multi select of bank statement lines in the list view to: - Use the primary action of all of the selected records - Set the partner for all of the selected records - Set the account number for all of the selected records task-6102308
Deleting an attachment linked to a document now moves the document to the Trash instead of removing it permanently. This protects business documents from being lost when attachments are deleted from related records such as vendor bills or chatter messages.
Original PR description
We replace the `documents.unlink.mixin`, which was previously applied only to specific models, with a generic mechanism that works regardless of the involved models. This new mechanism archives the…
We replace the `documents.unlink.mixin`, which was previously applied only to specific models, with a generic mechanism that works regardless of the involved models. This new mechanism archives the documents when their attachments are deleted, preventing their deletion. It does a little more than the mixin as the mixin was preveting the deletion of the document only when a record sharing a common attachment was deleted. Here, we also preserve the document if the attachment is deleted directly (for example from the chatter of a record). In that case, we also preserve the link between the document and the record (through the res_model and res_id of the document record). This change is motivated by use-cases similar to the following: - In document, click on the action "Create Vendor Bill" - On the chatter of the account.move, delete the attachment - Return to Documents Before, the document was deleted. Now, it has been moved in the Trash. To implement that feature, we remove the "ondelete cascade" on the attachment_id field of document and implement a custom version of it that move the associated documents (if any) in the Trash. Thanks to the api.ondelete decorator, we intercept all attachment deletion and if some of them are linked to a document we copy them and associate their copy with the documents before they are deleted. Note that the copy is cheap as odoo implements a deduplication of the store (see IrAttachment._file_write). Notes that we first have tried to preserve the attachment instead of duplicating it. But it was breaking other flow as they were expecting the attachment to be deleted. For example, when deleting a message with an attachment in the chatter, as the attachment was preserved it was still linked to the message even if it was not anymore directly linked to the model (ex.: lead) through res_model, res_id which caused the attachment to still appear in the chatter. Co-authored-by: Florian Charlier <flch@odoo.com> Task-5155496
Resolved issues and error corrections
Employees can now access and sign signature requests sent to their private email address. The request remains linked to the employee’s existing contact record, avoiding access problems while still delivering the email to the private address.
Original PR description
Before, when a signature request was sent to an employee's private email address, a new partner was created with the private email address and the signature request was linked to that new partner. Since there is a security rule where an employee cannot access a sign request item unless the partner on it matches partner for that employee, the employee is not able to see the sign request as the linked partner to the sign request item is an entirely new partner that is not linked to the employee. To fix the issue, the sign request is now linked to the employee's partner but the email itself is sent to the employee's private email. Task-5358107
Fixes translation-related issues in accounting screens so users see consistent guidance and correctly ordered labels in their chosen language. Bank Matching now keeps the same empty-state help after reloads or language changes, and the fiscal year wizard can use natural wording in languages such as French.
Original PR description
The empty-state message in Bank Matching differs depending on how the view was reloaded. In particular, after changing language from inside the view, the message loses the sentence explaining that users can create or import bank transactions. Ensure the Bank Matching empty-state help remains consistent across all reload flows. --- The fiscal year setup wizard was building the tax periodicity label from two separate translated parts. This produces an incorrect word order in some languages, such as "TVA Périodicité" in French which is supposed to be "Périodicité TVA". Use a single translatable label instead, so translations can place the tax label where it belongs in the sentence. task-6265141
This fix ensures the Avalara tax connection is disabled when a database is neutralized, such as in test or copied environments. It helps prevent those environments from accidentally connecting to the live tax proxy service.
Original PR description
Community: https://github.com/odoo/odoo/pull/272495
This change removes unused template markers from Helpdesk knowledge base search results and eCommerce subscription product pages. It prevents harmless backend warning messages during page rendering, keeping system logs cleaner without changing the customer-facing experience.
Original PR description
When rendering specific server-side pages (Knowledge Base search results and the eCommerce subscription product page), the Python QWeb engine logs the following warning:
"Unknown directives or unused attributes: {'t-key'} from..."
The `t-key` attribute is an OWL-specific directive required for client-side `t-foreach` loops. It is not recognized by the backend Python QWeb engine and serves no purpose in server-rendered templates.
This commit removes the inert `t-key` attributes from these Python-rendered templates.
task-6385543Automatic bank reconciliation now retries failed statement lines once before discarding them. This helps avoid losing reconciliation work when temporary system issues, such as database conflicts, cause a failure.
Original PR description
The auto reconcile cron drops the lines whenever they raise an error which is an issue for things like serialization errors. Now the code retries failed lines once before dropping them to make sure it's an issue with the lines. task-6273202 Forward-Port-Of: odoo/enterprise#119383
This fix ensures Belgian payroll eco vouchers are calculated using the correct start and end date boundaries. It helps avoid incorrect voucher amounts for employees whose eligibility depends on precise payroll period dates.
Original PR description
Forward-Port-Of: odoo/enterprise#124073 Forward-Port-Of: odoo/enterprise#120166
This fix makes map pin popovers open reliably after selecting a record from the pin list. It removes a timing issue that could cause the popover to disappear unexpectedly during automated mobile testing, improving stability without changing user-facing behavior.
Original PR description
Clicking a record in the "PinList" opens a marker popover. Until now this was handled by `centerAndOpenPin`, which closed the pin list popover and then, after two `delay(0)`, centered the map and…
Clicking a record in the "PinList" opens a marker popover. Until now this was handled by `centerAndOpenPin`, which closed the pin list popover and then, after two `delay(0)`, centered the map and opened the marker popover. This was racy. Closing `pinListPopover` triggers a re-render of the view, during which all markers are removed and re-added. If that re-render happened after the popover was opened, the marker element the popover was anchored to no longer existed, and the popover closed itself through `Popover.onTargetMutate()` (which closes the popover when its target element leaves the DOM). Depending on timing, the popover would sometimes be destroyed right after being opened, making the test flaky and leaving no popover open in the browser. To fix this, `centerAndOpenPin` is split in two parts: * it now only closes `pinListPopover` and raises a `shouldOpenMarkerPopover` flag; * on the next `onPatched`, once the markers have been re-rendered, the new `centerAndOpenPinOnPatched` method centers the map on the marker and opens the popover. Opening the popover after the re-render guarantees the marker element is present, removing the race condition. runbot-error-944199
This fixes an issue where opening a Belgian Dimona declaration could fail if an employee's private street information was missing. The change ensures payroll users can continue the declaration process without an unexpected error.
Original PR description
action_open_dimona guards on `self.employee_id.private_street` but then runs re.findall on `self.private_street` Forward-Port-Of: odoo/enterprise#124029
New planning slots now use the company’s working hours in the company timezone, so default start and end times appear correctly. This prevents schedule entries from being shifted by timezone differences when no resource is selected.
Original PR description
Issue: ---------------------------------------- When creating a new slot, no resrouces are set so we use the calendar of the company but the hours are offset because of the timezone. Steps to reproduce: ---------------------------------------- - Have planning Installed - Have an hour based calendar, from 8 to 16 each day for example - Have the company timezone in UTC+2, same for you the user - Go in Planning "Schedule By Resource" view - Click "New" - The default start and end time are 10am and 6pm (2h offset) Cause: ---------------------------------------- `default_get()` calls `_company_working_hours()` to get the company calendar hours. But they are returned in UTC, so when displaying them they are converted to the user timezone and are offsetted. Solution: ---------------------------------------- `_company_working_hours()` should return the compny hours in the company timezone. opw-6333993 Forward-Port-Of: odoo/enterprise#123033
Code cleanup and technical improvements
The grid view was updated to use the newer interface expected by the latest Odoo web framework. This keeps keyboard navigation and time entry behavior working reliably while reducing reliance on outdated internal code.
Original PR description
Replaced `useLayoutEffect` with `signal.ref` + `useEffect` && `onMounted()` + `onPatched()` && `useListener` because `useLayoutEffect` is deprecated in OWL3. The useLayoutEffect refactored in this PR had test coverage — below are some tests that failed when the effect was commented out, and are now passing: - @web_grid/grid_view/grid_view_desktop/Edition navigate with tab/shift+tab and enter key - `@web_grid/grid_view/grid_view_desktop/Edition navigate with tab/shift+tab and enter key` - `@web_grid/grid_cells/float_time_grid_cell/FloatTimeGridCell in grid view` see commented-out runbot build: https://runbot.odoo.com/runbot/batch/2624598/build/116553722 see commented-out runbot build: https://runbot.odoo.com/runbot/batch/2624595/build/116553684
This update simplifies internal test setups for sales and rental flows, making them easier to maintain. It also starts aligning some tests with standard salesperson permissions, helping ensure checks better reflect typical day-to-day usage.
Original PR description
Simplify specs, and start converting some tests to run with standard salesmen rights.
Obox report printing now uses Odoo's shared printer setup for report output, aligning it with other printer types such as ePOS, Zebra, and IoT. This should make printer management more consistent and reduce duplicate Obox-specific printing logic over time.
Original PR description
This commit adapts the Obox report printing to use the new report printing system, the common printer model for ePOS/Zebra/IoT. The Obox is added as a printer type, and the old Obox report logic removed. task-6328971 Community PR: https://github.com/odoo/odoo/pull/272451
This change updates several Odoo Enterprise screens and components to use the supported OWL3 lifecycle approach instead of a deprecated method. It helps keep the platform maintainable and compatible with newer frontend framework versions while preserving existing behavior when screens open and close.
Original PR description
useLayoutEffect is deprecated in OWL3, so replace the calls that used an empty dependency array (run-once-on-mount) with the native OWL3 lifecycle hooks onMounted and onWillUnmount. Effects that returned a cleanup function have their teardown moved into onWillUnmount so the unmount behaviour is preserved. Community PR: https://github.com/odoo/odoo/pull/276619
13 changes
New functionality added to Odoo
A new Elster integration lets German companies submit tax returns directly from Odoo instead of using a separate portal. This streamlines compliance work and reduces manual handling when preparing official tax filings.
Original PR description
This module enables users to submit their tax returns to Elster directly from Odoo. see IAP: https://github.com/odoo/iap-apps/pull/1513 task-5193637
Enhancements to existing features
Audit check statuses now update automatically based on the status of their related accounts, reducing manual work and improving consistency. The interface also uses clearer wording, including "Last Comment" and past-tense status labels across working files and tax returns.
Original PR description
Before this commit, the status of an Audit Check (e.g., Fixed Assets) did not automatically reflect the status of its underlying accounts, forcing users to update it manually. Additionally, status labels used inconsistent tenses. This commit automates the Check status update based on the underlying account statuses: - If any account is To Review or Empty or Anomaly -> Check becomes 'To Review'. - If all accounts are Reviewed -> Check becomes 'Reviewed'. - If all accounts are Supervised -> Check becomes 'Supervised'. - If accounts are mixed (Reviewed + Supervised) -> Check becomes 'Supervised'. This commit also standardizes UI terminology by renaming the "Last Message" column to "Last Comment" and updating status labels to past tense (e.g., "Reviewed", "Submitted") across Working Files and Tax Returns. task-5388699
Peruvian e-invoicing now includes the product classification codes required by SUNAT's upcoming validation rules. This helps businesses avoid invoice rejections for affected goods when the new requirements take effect in August 2026.
Original PR description
SUNAT is updating its validation rules 2026-08-01, adding three mandatory annexes (25.1, 25.2, 25.3) to Product Catalog N25. E-invoices for these goods are rejected when the required UNSPSC code is not available in the database. Most of the required codes already exist and are active. The rest are handled here: two missing UNSPSC codes were added to the shared catalog, while the fourteen codes that exist but are inactive and the SUNAT-only code 11111111 (which is not part of the UNSPSC standard) are activated from the Peru localization instead. Doing the Peru-specific part in the l10n_pe_edi install hook and upgrade script, the way l10n_mx_edi and l10n_ke_edi_oscu do for their own codes, keeps these activations out of databases that do not use the Peruvian localization. Task-6366907 Forward-Port-Of: odoo/enterprise#124200 Forward-Port-Of: odoo/enterprise#123577
Resolved issues and error corrections
The salary contract flow now uses the right update template, taking it from the current contract version when available or from the offer's contract template otherwise. This helps ensure contract updates generated from offers follow the intended template and reduces manual corrections.
Original PR description
contract update template should come from current version if any or from the offer's contract template. Task-6094733 Forward-Port-Of: odoo/enterprise#123450
This fix prevents an intermittent error when the signing document preview closes or reloads at just the wrong moment. It helps keep automated checks stable and reduces the chance of unexpected signing interface errors.
Original PR description
Due to a race condition, in the PDFIframe sometimes the Iframe gets detached before we access it and we therefore have this.root.defaultView = null. Since when the Iframe is detached we don't really care about defining the eventBus, we can fix the problem related to its assignation by first checking the value of this.root.defaultView and only continuing in case it has one. This PR fixes a runbot error. Runbot Error: 233524
The barcode app now correctly finds manufacturing orders that were split into multiple related orders. This prevents users from seeing a false “not found” error when scanning the original manufacturing order name, keeping shop floor workflows moving smoothly.
Original PR description
### Steps to reproduce: - Create a product FP with a BOM: 1 X COMP (enough units in stock) - Create and confirm an MO for 3 units - Click on the cog wheel icon > Split the MO in 3 - On the barcode app > Operations > Manufacturing - Scan the name of your base MO #### > Error: No product or order found for barcode ... ### Expected behavior: Scanning an existing MO only adds its barcode as a `search_default_name`: https://github.com/odoo/enterprise/blob/598a8e335605fd68e3ceb5c1170864243426f994/stock_barcode_mrp/models/mrp_production.py#L162-L178 However, while this search is performed with an ilike, we only check the existence of an exact match before raising an error, which does not happen since our splitted MOs have a name: barcode-001, barcode-002, barcode-003,... opw-6376937
Invoices marked as excluded from follow-up are now consistently left out of follow-up email attachments and printed follow-up letters. This prevents customers from receiving documents for invoices the business has intentionally removed from follow-up actions.
Original PR description
Steps to reproduce: 1. Install Accounting and create an invoice for a customer which has a due date in the past 2. Make sure the payment term for the invoice is "Immediate Payment" and Send the…
Steps to reproduce: 1. Install Accounting and create an invoice for a customer which has a due date in the past 2. Make sure the payment term for the invoice is "Immediate Payment" and Send the invoice. 3. Open the contact form and click on the Customer Statement smart button 4. Exclude the invoice using the 'No Follow-Up' toggle 5. In the Accounting tab in the contact form, click on send 6. Open the internal link of the Content Template, go to the options tab and select 'Print Follow-up Letter' in Dynamic Reports 7. Save the configuration and send the email Issue: Excluded invoices still appeared as PDF attachments in the follow-up email and were merged into the printed follow-up letter PDF. Why this happens: Both `default_get` in `account_followup.manual_reminder` and `_get_invoices_to_print` in `res.partner` traversed `unreconciled_aml_ids` without filtering out lines where `no_followup = True`, so excluded invoices were included regardless. opw-6310602 Forward-Port-Of: odoo/enterprise#124541 Forward-Port-Of: odoo/enterprise#122249
This update adds automated test coverage to ensure currency translation adjustments use the correct exchange rates when the company currency changes during the year. It helps prevent incorrect financial reporting values in multi-currency scenarios, especially around average and historical exchange rates.
Original PR description
Following the fix made in community branch, this adds a test veryfing the expected behavior in case of a fluctuating rate for the domestic currency. Scenario 2: fluctuating domestic (USD) rate USD rate=1 from Jan 1 to Jun 30, USD rate=3 from Jul 1 to Dec 31 EUR rates unchanged: 2 from Jan 1, 4 from Jul 1 Correct conversion factors (= USD_rate / EUR_rate): Jan 1 – Jun 30 (182 days): 1/2 = 0.50 Jul 1 – Dec 31 (184 days): 3/4 = 0.75 Current rate at 2020-12-31: 3/4 = 0.75 Correct average rate: (0.50 * 182 + 0.75 * 184) / 366 = 229/366 ≈ 0.62568 Previsouly bugged average rate (USD fixed at current=3): (1.50 * 182 + 0.75 * 184) / 366 = 411/366 ≈ 1.12295 Historical equity rates (correct vs previously bugged): Mar 1 (USD=1, EUR=2): correct = 1/2 = 0.50; buggy = 3/2 = 1.50 → 40 * 0.50 = 20 vs 40 * 1.50 = 60 Oct 1 (USD=3, EUR=4): correct = 3/4 = 0.75; buggy = 3/4 = 0.75 → 60 * 0.75 = 45 (same by coincidence) task-5953104
Odoo Studio no longer fails when users rename fields with Arabic or other non-Latin labels. This prevents an unnecessary validation error and makes field labeling more reliable for multilingual users.
Original PR description
Steps: - Install web_studio - Add any field (example char field) to any view - Rename it in arabic, example `السَّلَامُ عَلَيْكُمْ` - Error Custom field names cannot contain double underscores Webclient (view_editor_model) escape every non-alphabetic chars, so new label value contains nothing but a space which will be replaced by a _ this new label value will be concatenated to `x_studio_`. Resulting to the string `x_studio__`. A solution should be to prevent changing the technical name if the new label value (escaped) is empty. opw-6311027 Forward-Port-Of: odoo/enterprise#122094 Forward-Port-Of: odoo/enterprise#121343
French VAT declarations now handle SIRET numbers even when users enter spaces, reducing failed submissions. The update also checks bank account number formatting and warns users before incorrect details cause issues.
Original PR description
This commit resolves an issue where VAT declarations failed when the provided SIRET number included spaces. Since check_siret verifies the format, we now strip all spaces from the input. Additionally, this commit introduces a validation for bank account numbers, ensuring that we warn the user if the account number is wrongly formatted. task-6253745 Forward-Port-Of: odoo/enterprise#124448 Forward-Port-Of: odoo/enterprise#120689
Fixed an issue where emailing the Partner Ledger could fail for companies using different currencies. The email wizard now opens reliably in multi-currency setups, while single-currency setups are unchanged.
Original PR description
### Description of the issue/feature this PR addresses Sending the **Partner Ledger** report by email in a multi-currency setup (several companies using different currencies) crashes the send wizard…
### Description of the issue/feature this PR addresses Sending the **Partner Ledger** report by email in a multi-currency setup (several companies using different currencies) crashes the send wizard on opening with: ``` psycopg2.errors.UndefinedTable: relation "account_currency_table" does not exist ``` ### Current behavior before PR To compute the recipients, `AccountPartnerLedgerReportHandler._get_report_send_recipients` runs `_get_query_sums`, whose SQL joins the currency table. In a multi-currency setup that table is a **temporary** table that must be created beforehand by `AccountReport._init_currency_table`. Every regular rendering entry point calls `_init_currency_table` before running currency-table queries, but the report-sending path does not, so the query fails on a missing `account_currency_table` relation. ### Desired behavior after PR is merged `_init_currency_table(options)` is called before running the query, so the temporary table exists. It is a no-op in mono-currency setups (early return in `_init_currency_table`), so mono-currency behavior is unchanged. ### Steps to reproduce 1. Have several companies using different currencies. 2. Select more than one of them in the company switcher. 3. Open **Accounting > Reporting > Partner Ledger**. 4. Click **Send by email** → the wizard crashes on opening. Video: https://drive.google.com/file/d/1skpg7YDtxcY1PCtURyzk5PdFPi7ZPreG/view A regression test covering the multi-currency send-recipients path is included in `test_partner_ledger_report.py`. I've created the task #6362131 for this issue
This fix ensures Manufacturing Planning uses the product's Bill of Materials batch size even when no specific BOM is selected while adding the product. This helps planners get correct replenishment quantities and avoid under-planning production.
Original PR description
In MPS, if a product’s Bill of Materials (BOM) is not specified at the time of addition, the system will not correctly account for batch size. Steps to reproduce: ------------------- * Create a…
In MPS, if a product’s Bill of Materials (BOM) is not specified at the time of addition, the system will not correctly account for batch size. Steps to reproduce: ------------------- * Create a product with a bom that has a batch size of 2 * Open MPS * Add the product - without specifying the bom - Route Manufacture * Add 1 in the Forcast Demand -> the batch size from the bom it's not taken into account. Observation: ------------- When updating mps, it will call get_production_schedule_view_state: https://github.com/odoo/enterprise/blob/7092dd2cc3578c3f22d1fbc82d958d57e2f93553/mrp_mps/models/mrp_mps.py#L424 this function when calculating the quantity to resplenish will call _get_resplenish_qty: https://github.com/odoo/enterprise/blob/7092dd2cc3578c3f22d1fbc82d958d57e2f93553/mrp_mps/models/mrp_mps.py#L534 to know the quantity to resplenish it will need the batch size, in mps they will only consider the batch size from the bom registered: https://github.com/odoo/enterprise/blob/7092dd2cc3578c3f22d1fbc82d958d57e2f93553/mrp_mps/models/mrp_mps.py#L863-L865 Since there is no default value for bom_id, If there is no bom selected, there is no batch size. opw-6259956
Envia shipping rate requests now send insurance information in the format expected by the carrier API. This ensures quoted delivery prices reflect configured insurance coverage, avoiding underquoted rates for insured shipments.
Original PR description
Issue ----- Insurance request is not reflected on the rating given by Envia. Steps to reproduce ----- - Create a MX company - Set up Envia - Fedex Nacional Economico (ground) - Create a MX client - Create a product (with some weight) - Create a SO - Add the product - Add envia delivery and get a rate - Update Envia delivery method - Set insurance to 50% - Go back to the SO - Add envia delivery and get a rate > The rate is the same both times Cause ----- We are passing the insurance value as a `insurance` field on the shipment, which is not what the API expects. We should instead pass it in `additionalServices` as shown in the example of https://docs.envia.com/docs/additional-services#how-to-add-services-to-a-shipment Follow up of 7258e4a ----- Ticket: opw-5254952
3 changes
Resolved issues and error corrections
### Issue: The 'Schedule an appointment' and 'Next Events' CTA buttons were not updated even when their conditions were satisfied. ### Steps to reproduce: - Install only Website. - In the configurator, choose 'Schedule Appointments' as the main objective. - Complete the setup and create the website. - The CTA button remains 'Contact Us' instead of 'Schedule an appointment'. ### Reason: The `get_cta_data()` method is overridden in specific modules to update the CTA button base
Original PR description
### Issue: The 'Schedule an appointment' and 'Next Events' CTA buttons were not updated even when their conditions were satisfied. ### Steps to reproduce: - Install only Website. - In the configurator, choose 'Schedule Appointments' as the main objective. - Complete the setup and create the website. - The CTA button remains 'Contact Us' instead of 'Schedule an appointment'. ### Reason: The `get_cta_data()` method is overridden in specific modules to update the CTA button based on conditions. However, it is called before those modules are installed, so the overridden logic is never executed. ### Fix: Ensure that `get_cta_data()` is called and the CTA button is updated after the required modules are installed. task-[6383681](https://www.odoo.com/odoo/project/974/tasks/6383681) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261781
Users cannot navigate to the next page in the message list view when hidden records cause the current page to appear incomplete. ### Steps to reproduce 1. Create many messages, ensuring some are hidden from a specific user via access rules. 2. Open the message list view as that user. 3. Pagination incorrectly shows a total matching the current page (e.g., "1-68 / 68") instead of the full count (e.g., "1-80 / 5000+"). 4. Because the system believes all records are displayed, the "Next" p
Original PR description
Users cannot navigate to the next page in the message list view when hidden records cause the current page to appear incomplete. ### Steps to reproduce 1. Create many messages, ensuring some are…
Users cannot navigate to the next page in the message list view when hidden records cause the current page to appear incomplete. ### Steps to reproduce 1. Create many messages, ensuring some are hidden from a specific user via access rules. 2. Open the message list view as that user. 3. Pagination incorrectly shows a total matching the current page (e.g., "1-68 / 68") instead of the full count (e.g., "1-80 / 5000+"). 4. Because the system believes all records are displayed, the "Next" page button is disabled, leaving the user stuck on the current page despite more records existing in the database. ### Cause The `mail.message` model filters records in Python after fetching them from the database to enforce complex access rules. 1. The system queries the database for a batch of records up to the view's limit. 2. The `_search` method removes inaccessible records from this batch. 3. The web client receives fewer records than the requested limit. 4. Interpreting this as the end of the dataset, the web client skips the count query and displays the current batch size as the total. ### Fix Add `'force_search_count': 1` to the action context. This forces the web client to execute a separate count query to determine the total number of records, regardless of the batch size returned. opw-5425361
## Short fix summary: Both Nilvera sync crons (`_l10n_tr_nilvera_get_submitted_document_status` and `_cron_nilvera_get_new_documents`) built their API client from the ambient `self.env.company` instead of each invoice's own `company_id`. In a multi-company setup, or whenever the cron's runtime user's default company differs from the invoice's, this silently used the wrong (or no) API key and the sync failed for those invoices. `_l10n_tr_nilvera_get_submitted_document_status` now groups invoice
Original PR description
## Short fix summary: Both Nilvera sync crons (`_l10n_tr_nilvera_get_submitted_document_status` and `_cron_nilvera_get_new_documents`) built their API client from the ambient `self.env.company` instead of each invoice's own `company_id`. In a multi-company setup, or whenever the cron's runtime user's default company differs from the invoice's, this silently used the wrong (or no) API key and the sync failed for those invoices. `_l10n_tr_nilvera_get_submitted_document_status` now groups invoices by `company_id` and opens one Nilvera client per company. `_cron_nilvera_get_new_documents` now goes through a new `_l10n_tr_nilvera_company_get_documents` helper that loops over the Turkish companies with an API key configured and switches into each one's context via `with_company()` before fetching. task-6328589 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#275537
1 change
Resolved issues and error corrections
`invoice_origin` is parsed to build the references passed to `_match_purchase_orders()`. Since odoo/odoo#223398, we split this field on commas so values like `"P00001, P00002"` correctly become `["P00001", "P00002"]`. That still leaves a bad case: blank or whitespace-only content still produces empty refs. For example, `","` becomes `['', '']`, and since https://github.com/odoo/odoo/pull/225294 on 18.4+ during foward port it's gotten even worse: " commission" becomes `['', 'commission']`
Original PR description
`invoice_origin` is parsed to build the references passed to `_match_purchase_orders()`. Since odoo/odoo#223398, we split this field on commas so values like `"P00001, P00002"` correctly become…
`invoice_origin` is parsed to build the references passed to `_match_purchase_orders()`. Since odoo/odoo#223398, we split this field on commas so values like `"P00001, P00002"` correctly become `["P00001", "P00002"]`. That still leaves a bad case: blank or whitespace-only content still produces empty refs. For example, `","` becomes `['', '']`, and since https://github.com/odoo/odoo/pull/225294 on 18.4+ during foward port it's gotten even worse: " commission" becomes `['', 'commission']` This problematic because `invoice_origin` does not always contain real PO refs. Since odoo/odoo#207037, XML imports can also fill it with concatenated line descriptions which contains arbitrary text. We recently hit this on odoo.com with a Peppol bill where this led to parsed refs including `''`. Once `['']` is passed to `_match_purchase_orders()`, POs with an empty `partner_ref` can enter the candidate set. From there, the normal amount or line matching can link the bill to a wrong PO (which will always happen with the number of POs and PO lines we have on prod)