Daily updates from Odoo
Friday, July 10, 2026
306 changes
29 changes
Resolved issues and error corrections
Fixes an issue where quotations created from a CRM opportunity could be hidden when viewing the opportunity's quotation list. This ensures sales teams can reliably see and follow up on non-rental quotations even when rental sales features are installed.
Original PR description
Steps to reproduce: 1. Install sale_crm and sale_renting_crm 2. Create an opportunity 3. On this opportunity, create two quotations from the `New quotation` button 4. From the opportunity's form…
Steps to reproduce:
1. Install sale_crm and sale_renting_crm
2. Create an opportunity
3. On this opportunity, create two quotations from the `New quotation` button
4. From the opportunity's form view, click on the `Quotation` smart button
Issue:
- The quotations are not visible in the list view
Why?
- In module `sale_renting_crm`, we override the domain to exclude rental quotations.
https://github.com/odoo/enterprise/blob/fda037c62a6661665611fb061718c01aec39ac1b/sale_renting_crm/models/crm_lead.py#L33-L36 But from the saas-19.3 `is_rental_order` field is no longer stored in the DB, It is computed now and filtered through `_search_is_rental_order`.
https://github.com/odoo/enterprise/blob/fda037c62a6661665611fb061718c01aec39ac1b/sale_renting/models/sale_order.py#L223-L227 The search method did not properly handle the Boolean search shape used by the ORM, so the quotations were incorrectly filtered out. In our case, we gave the domain `("is_rental_order", "=", False)` but the operator is translated to `not in` and value to `Orderedset([True])` by the domain optimiser
Solution:
- Update `_search_is_rental_order()` to handle the ORM-normalized boolean search correctly for rental and non-rental quotations.
opw-6304696
Forward-Port-Of: odoo/enterprise#120869Bank reconciliation models that include taxes now correctly fill in the tax base amount on generated journal entries. This prevents tax lines from showing a misleading zero base amount and improves accounting accuracy without requiring users to reset entries to draft.
Original PR description
### Steps to reproduce the issue: 1. Download Accounting 2. Go to Journal entries and create a new one 3. Click Toggle Studio button and go to the view to add the tax_base_amount field to the list of…
### Steps to reproduce the issue: 1. Download Accounting 2. Go to Journal entries and create a new one 3. Click Toggle Studio button and go to the view to add the tax_base_amount field to the list of existing fields 4. Add 2 lines (example): 1. account Product Sales with 1000 dollars credit and 15% tax under Tax column 2. account Bank with 1000 dollars debit 5. Go to Dashboard > Bank > Click the 3 dots of one random bank matching line and click on Manage Models 6. Go to bank fees and add the 15% tax 7. Go back to bank reconciliation and create a new one of 2000 dollars with label bank fees (it will associate the tax automatically) 8. Go back to Journal Entries, group by Journal and search for the transaction of 2000 sollars for account Bank 9. Problem: see that the Base Amount for the 15% bank fees lines (251000 Tax Received account) is 0. Clicking on Reset to draft button the base amount column is automatically updated but this should happen automatically ### Cause of the issue: This occurs because the _lines_prepare_tax_line method in account.bank.statement.line fails to map this field in its return dictionary. ### Reason to introduce the fix: Currently, when applying a reconciliation model with taxes the generated tax lines incorrectly record a tax_base_amount of $0.00. Instead, it should be displayed and calculated. opw-6220948 Forward-Port-Of: odoo/enterprise#123603 Forward-Port-Of: odoo/enterprise#122139
This change restores payroll salary attachment refund handling and beneficiary bank details that were previously removed. It keeps existing payment and reporting flows working while the team revisits the best way to redesign refund-related attachments later.
Original PR description
In this previous PR (https://github.com/odoo/enterprise/pull/114188) we removed the is_refund flag and, together with it, also the fields related to the beneficiary. This is because there is an onchange method on is_refund that sets the beneficiary bank account for any attachment that is not a refund to False. However, while the removal of is_refund is still in the plans, we want to take back the beneficiary fields and use them even in the case of non-refund attachments. We need to think better about how to remove the is_refund field and structure negative attachments around it, so for now we revert the previous PR. Task: 6376383
Shop floor operators can now see their own and other operators' profile photos instead of generic placeholder images. This makes it easier for manufacturing teams to identify the right operator when viewing or changing assignments.
Original PR description
Currently when a shopfloor operator modifies the operator, operator images are not visible and only place holder images are visible. ## Steps to produce: - Install Manufacturing with demo data -…
Currently when a shopfloor operator modifies the operator, operator images are not visible and only place holder images are visible. ## Steps to produce: - Install Manufacturing with demo data - Login as Marc Demo - Open shopfloor ## Observed Behavior: Operator is unable to see their own profile picture and when you press the Edit Operator the operator is not able to see their as well as other operators images as well. ## Root cause: This issue occurs because by default an operator's user does not have access right for `Employees` in Human Resources section as they are not an HR officer nor an administrator. So when the user tries to access the image url that is meant for users with those access rights (HR officer / Administrator) at [1] and at [2]. The system returns a placeholder image instead of the employee image since the operator does not have access to hr employee model but does have access to hr employee public as per this [commit](https://github.com/odoo/odoo/commit/c9ca3761464413327d2beb697553a3ccd7eef4d1) [1]- https://github.com/odoo/enterprise/blob/5fe2fb44f4c8a938390343f7cdc90674cbf09391/mrp_workorder/static/src/mrp_display/dialog/mrp_employee_dialog.js#L16 [2]- https://github.com/odoo/enterprise/blob/5fe2fb44f4c8a938390343f7cdc90674cbf09391/mrp_workorder/static/src/mrp_display/employees_panel.xml#L9-L10 ## Solution: Allowing operators to see images can be done by modifying the links to use the public model instead of the private model. This will allow operators see other operators based on images and should improve user experience. | Before | |--------| | <img width="1865" height="844" alt="image" src="https://github.com/user-attachments/assets/c28f4209-0a60-486a-bfec-2a4db39cd946" /> | | <img width="995" height="899" alt="image" src="https://github.com/user-attachments/assets/7541edd9-6cc9-42d1-b5c5-39e0740d9a93" /> | | After | |--------| | <img width="1881" height="903" alt="image" src="https://github.com/user-attachments/assets/df3f8357-5cc2-4688-83dd-9a009fd56957" /> | | <img width="1221" height="862" alt="image" src="https://github.com/user-attachments/assets/c9d72b07-e1ad-43e4-85f5-00d8f1db9095" /> | opw-6321989 Forward-Port-Of: odoo/enterprise#123361 Forward-Port-Of: odoo/enterprise#121751
The Peruvian electronic invoicing POS refund check was adjusted so it no longer depends on an item price that can vary with currency settings. This prevents a false test failure and helps keep validation reliable after currency configuration changes.
Original PR description
Before this commit, the tour was checking the price of an article which was not the good one since the currency of the config was not the same as the company one. This commit removes the check of the price which is not even relevant for the tour. Forward-Port-Of: odoo/enterprise#121503
Users can now create expenses from documents even if their account is not linked to an employee. They still need the proper permission to create an expense on behalf of another employee, reducing unnecessary blockers while preserving access control.
Original PR description
Removes the constraint saying a user has to be linked to an employee to create an expense from a document. In this case, the user still needs the rights to create an expense for another employee. task-6237021 Forward-Port-Of: odoo/enterprise#123635 Forward-Port-Of: odoo/enterprise#118955
The barcode app now correctly respects operation settings that block adding extra products. This prevents users from scanning and adding unreserved items after all reserved products have been processed, helping keep inventory transfers aligned with planned quantities.
Original PR description
# How to reproduce - Go to Inventory > Settings > Operation Types - Pick any Operation and disable "Allow extra product" - Create a picking for that operation type with atleast one product and click…
# How to reproduce - Go to Inventory > Settings > Operation Types - Pick any Operation and disable "Allow extra product" - Create a picking for that operation type with atleast one product and click on "Mark as Todo" - Go to the Barcode app and find the created picking - Scan all the reserved products - Exit the picking and re-enter # The problem The "Add Product" button is displayed and you can scan unreserved products even tough you sould not be allowed to # Cause of the issue The problem stems from the fact that even with "Allow extra product" disabled, we still allow to add unreserved products for immediate transfers (created directly in the barcode app). The issue is that we don't really have a way to distinguish immediate transfers from plannified ones made in the Inventory app. So we try to guess using the `_useReservation` attribute (If it is false, we allow additional products). `_useReservation` is computed as follows : if any move lines from the inital state is not yet picked, set it to true : https://github.com/odoo/enterprise/blob/ca4b369e4fc9f4655574cf1ca71c81faaadc3e88/stock_barcode/static/src/models/barcode_picking_model.js#L43 So in our case, once all the reserved products are scanned, all the initial move lines are picked and our guessing fails. # Proposed Solution Since immediate transfers are never validated and stays in draft mode, guess using the state of the current picking in addition to `useReservation` opw-6231238 Forward-Port-Of: odoo/enterprise#118378
Fixed an issue that could prevent users from opening access rights for Sign templates when template access management was enabled. The dialog now avoids requesting unsupported data, so administrators can manage template permissions without encountering an error.
Original PR description
Version: - saas-19.4 Steps To Reproduce: - Go to Configuration -> Settings. - Enable 'Manage Template Access' option. - Open any Sign template. - Click the gear icon and then click on 'Access Rights'. Issue: - Opening the template access rights dialog caused an RPC error. Cause: - The Many2Many tags configuration added the `color` field for all related models, including `res.groups`, which does not have 'color' field. Solution: - Skip adding the `color` field for the `group_ids` relation so only supported models request it. task-6348673
This fix ensures Belgian payroll warnings are correctly limited to the relevant Belgian payroll scope. It prevents users from seeing access errors triggered by warnings that should not apply to their situation, making payroll workflows smoother and less disruptive.
Original PR description
Some payroll warnings in BE were missing correct filtering to avoid access errors on things outside of the BE scope. Forward-Port-Of: odoo/enterprise#123554
Foreign EU customer invoices above the threshold are now placed in the correct VAT control statement section instead of being grouped with domestic VAT transactions. This helps Czech companies produce more accurate tax reports and avoid incorrect filing classifications.
Original PR description
With l10n_cz company: - Create an invoice for a partner with a foreign vat (EU) with an amount greater than 10000 CZ and a 21% tax. In the vat control statement of the tax report, the move is classified under A4. But the section A4 should only contain move with domestic vat opw-6268506 Forward-Port-Of: odoo/enterprise#120002
This update prevents an error when generating Belgian tax returns involving sales checks for customers in Northern Ireland. It helps accounting teams complete tax return setup reliably without being blocked by an unexpected traceback.
Original PR description
…mers Steps to reproduce: - Setup a Belgian company - Make a sale to a French customer in June for example - Setup the tax returns (so that June returns are generated) -> Traceback raised from the check on sales done to customers from North Ireland. Forward-Port-Of: odoo/enterprise#123556
Fixes an issue where expanding a Knowledge article in the sidebar could show only favorited child articles while hiding the others. This ensures users see the complete article structure immediately, reducing confusion and avoiding the need to reload the page.
Original PR description
The sidebar always loads the user's favorite articles along with the visible ones, so a favorited article is shown as a root of the favorite tree. When that favorite is also a child of a folded…
The sidebar always loads the user's favorite articles along with the visible ones, so a favorited article is shown as a root of the favorite tree. When that favorite is also a child of a folded article, it gets added to its parent's child_ids in the main tree, even though the parent's other children were not fetched. A folded article only gets its favorited children back from get_sidebar_articles, not its whole child set. When the parent is then unfolded, unfold() only read the children from the database when child_ids was empty. The favorited child already filled child_ids, so the call was skipped and the remaining children stayed hidden until the next reload. unfold() now uses a new children_loaded flag instead of the length of child_ids to decide whether to fetch the children. The flag is set once an article's whole child set is loaded: in loadChildren(), and in loadArticles() for the articles that were unfolded, since those come back with all their children. loadChildren() also rebuilds child_ids from the search result so a favorite already loaded is not added twice. The fix lives in the sidebar component because the partial child_ids only exists on the frontend, get_sidebar_articles already returns the right records. Steps to reproduce: 1. Open the Knowledge app 2. Create an article with two child articles 3. Add one of the two children to your favorites with the star icon 4. Open another article that is not under that parent 5. Fold the parent article in the sidebar, then refresh the page 6. Expand the parent article => only the favorited child is shown under the parent, the other child is missing Ticket [link](https://www.odoo.com/odoo/project.task/6186466) opw-6186466 Forward-Port-Of: odoo/enterprise#118804
This update corrects several small issues in accounting reports, including when currency warnings appear, how warnings can be dismissed, and how editable budget values are presented. It also removes an irrelevant setup field for composite reports and improves the appearance of working file cards, making the reporting experience clearer and more stable for users.
Original PR description
**Commit 1: [FIX] account_reports: warning for CTA visibility** Steps to reproduce: - Open the balance sheet -> The warning for CTA is displayed even when a single company is selected. It should only…
**Commit 1: [FIX] account_reports: warning for CTA visibility**
Steps to reproduce:
- Open the balance sheet
-> The warning for CTA is displayed even when a single company is selected.
It should only be the case if multiple companies having different currencies
are involved in the computation of the report.
**Commit 2: [FIX] account_reports: hide groupby field on form view for composite report**
this field is useless for composite reports.
**Commit 3: [FIX] account_reports: differentiate UX for auditable external values.**
When creating a budget in the P&L, the external value cells should not be
auditable. The data was properly set but not the templates.
**Commit 4: [FIX] account_reports: avoid traceback on double-click on warning**
Steps to reproduce:
- Open an accounting report with any warning banner ("draft entries" for example)
- Quickly double-click the delete cross button
-> traceback stating that it cannot read properties of null (reading 'remove').
**Commit 5: [FIX] account_reports: working file card style adjustments**
<img width="401" height="317" alt="image" src="https://github.com/user-attachments/assets/76f636f0-09d8-44e5-8c7c-37561dc00b10" />
task-6361495Fixes an error that could block Kenyan POS refund validation and also affect batches of offline orders syncing back online. Refunds and synced orders are now processed individually so eTIMS reporting and receipt generation can complete reliably.
Original PR description
Steps to reproduce: 1. Install `l10n_ke_edi_oscu_pos`, set company to Kenya. 2. Sell and validate an order. 3. Refund it from the POS and validate the refund order. Issue: - A traceback is raised…
Steps to reproduce: 1. Install `l10n_ke_edi_oscu_pos`, set company to Kenya. 2. Sell and validate an order. 3. Refund it from the POS and validate the refund order. Issue: - A traceback is raised when validating the refund: `ValueError: Expected singleton: pos.order(<refund>, <original>)` raised in `get_l10n_ke_edi_oscu_pos_data`. Cause: - When syncing a refund, `sync_from_ui` returns both the new refund order and the original refunded order. `waitForPushOrder` forces post-processing for every Kenyan order in that list, so `beforePostPushOrderResolve` receives both ids in `order_server_ids` and forwards them as-is to `action_post_order` and `get_l10n_ke_edi_oscu_pos_data`, both of which expect a single record. `action_post_order` fails the same way, but its error was silently swallowed by the surrounding try/catch, letting the traceback surface only on the second call. - The same multi-id list is also produced whenever several orders created offline get synced together once back online. Solution: - `get_l10n_ke_edi_oscu_pos_data` is only needed for the receipt of the order being validated, so call it with `order.id` instead of the full `order_server_ids` list. - Replace the `action_post_order` call with `action_post_selected_orders`, which posts each order individually and skips ones already sent to eTIMS, correctly handling both the refund case (original order is already `sent`) and the offline multi-order sync case. opw-6364221 Forward-Port-Of: odoo/enterprise#123043
This fixes an issue where managers could not request an employee appraisal if the scheduled appraisal date had already passed. The change removes an unnecessary date update during appraisal creation, so users no longer need extra permissions or workarounds to proceed.
Original PR description
# How to reproduce You need to simulate the fact that you are creating an appraisal late so either : A) Directly edit the `next_appraisal_date` in SQL B) Go to Employee App > any Employee > Settings,…
# How to reproduce You need to simulate the fact that you are creating an appraisal late so either : A) Directly edit the `next_appraisal_date` in SQL B) Go to Employee App > any Employee > Settings, set Next Appraisal Date to tomorrow and wait for 2 days Then : - Click on Request Appraisal - Save # The problem An error is shown saying "You cannot set 'Next Appraisal Date' in the past.". You can workaround this by changing the Next Appraisal Date to a date in the future, but the problem is not every user has the right to do this. # Cause `next_appraisal_date` is also defined in hr.appraisal as a relate field of hr.employee : https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_appraisal/models/hr_appraisal.py#L56-L57 When creating an hr.appraisal, `next_appraisal_date` is present in `vals_list` because it is defined in the view since : https://github.com/odoo/enterprise/commit/58fba3098f33db82dfbccca2db229550402ed3ab https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_appraisal/views/hr_appraisal_views.xml#L92 This triggers a write on `next_appraisal_date` of hr.employee which triggers a constraint : https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_appraisal/models/hr_employee.py#L81-L85 opw-6147865 Forward-Port-Of: odoo/enterprise#122440 Forward-Port-Of: odoo/enterprise#114876
This fix ensures planning calendar popovers have the user information they need to open correctly. It prevents an error that could interrupt users viewing field service planning slots.
Original PR description
add the user_ids field to the calendar view because its needed in a popover task: 6358644
This change restores fields used to identify beneficiaries on payroll salary attachments after they were removed in an earlier update. It keeps existing refund handling in place while allowing beneficiary bank details to be used again for regular, non-refund attachments, reducing disruption to payroll payment workflows.
Original PR description
In this previous PR (https://github.com/odoo/enterprise/pull/114188) we removed the is_refund flag and, together with it, also the fields related to the beneficiary. This is because there is an onchange method on is_refund that sets the beneficiary bank account for any attachment that is not a refund to False. However, while the removal of is_refund is still in the plans, we want to take back the beneficiary fields and use them even in the case of non-refund attachments. We need to think better about how to remove the is_refund field and structure negative attachments around it, so for now we revert the previous PR. Task: 6376383
Donation products in Website Sale Subscription are now explicitly set up without sales tax. This prevents donors from being incorrectly charged tax when making a donation, aligning the checkout experience with the intended tax responsibility.
Original PR description
**Steps to reproduce:** 1. Install `website_sale_subscription` 2. Open the Products page, search for Donation and open the products **Issue:** A default Sales Tax is applied on the donation products. If a visitor donates money, they will be charged the sales tax. **Expected behavior:** Donation products should not include tax when web visitors donate money. Tax responsibility does not fall on the donors. **Why this happens:** When a `product.template`record is created without an explicit `taxes_id`, the field falls back to the default, which resolves to `company.account_sale_tax_id`. opw-6367188
The warning shown when a single employee or resource does not match a shift's required role now uses the correct wording. This small fix makes the Planning app message clearer and more professional for users.
Original PR description
Currently, when a (or multiple) resource(s) do not have the role for a particular shift, a warning is displayed. However, in the case where only one resource does not have the correct role, the following warning was displayed, "resource_name don't have the required role for this shift", instead of "doesn't". task-6153932 Forward-Port-Of: odoo/enterprise#120899
Order fetching for UrbanPiper point-of-sale integrations now combines related order requests into a single server call. This reduces waiting time and server load when retrieving orders, making order synchronization more efficient without changing user workflows.
Original PR description
Issue: pos_urban_piper overrode getServerOrders() to add a separate loadServerOrders() call for it's own orders before delegating to super, resulting in up to an additional sequential RPCs on every order fetch. Fix: Extract the base query domain into a new overridable getServerOrdersDomain() method. Each module overrides it to OR in its own domain via Domain.or([super.getServerOrdersDomain(), extraDomain]), so all orders are fetched in a single RPC call instead of three. Task-6284860 Forward-Port-Of: odoo/enterprise#123679 Forward-Port-Of: odoo/enterprise#120001
This fix prevents Belgian payroll processing from crashing when seniority is calculated for multiple employee contract versions at once. It helps payroll teams complete CP200 seniority calculations reliably without manual interruption.
Original PR description
Before this commit, _compute_l10n_be_computed_seniority looped over cp200_versions but still read self.employee_id and self.l10n_be_scale_seniority, so when Odoo batched multiple CP200 versions…
Before this commit, _compute_l10n_be_computed_seniority looped over cp200_versions but still read self.employee_id and self.l10n_be_scale_seniority, so when Odoo batched multiple CP200 versions together, the whole recordset was passed to _get_first_version_date(), crashing with a singleton error.
After this commit, the loop correctly uses version.employee_id and version.l10n_be_scale_seniority instead.
Traceback (important part):
```py
File "/home/odoo/src/enterprise/l10n_be_hr_payroll/models/hr_version.py", line 1508,
in _compute_l10n_be_computed_seniority
company_seniority = relativedelta(fields.Date.today(),
self.employee_id._get_first_version_date()).years
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/addons/hr/models/hr_employee.py", line 621, in
_get_first_version_date
versions = self._get_last_consecutive_versions(date_limit)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/addons/hr/models/hr_employee.py", line 595, in
_get_last_consecutive_versions
self.ensure_one()
File "/home/odoo/src/odoo/odoo/orm/models.py", line 5406, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: hr.employee(30, 1)
```
task-6377630Removing an icon from a Knowledge article header no longer triggers an error. This keeps article editing smooth and prevents users from being interrupted by a traceback during a common customization action.
Original PR description
Steps to reproduce: ------------------------------------ 1. Install the Knowledge module. 2. Open any article. 3. Click the header icon. If no icon is present, add one from the Actions menu. 4. Click…
Steps to reproduce: ------------------------------------ 1. Install the Knowledge module. 2. Open any article. 3. Click the header icon. If no icon is present, add one from the Actions menu. 4. Click the header icon again. 5. Click Remove icon from the emoji picker. Observation: ------------------------------------ A traceback is raised when removing the header icon. ``` TypeError: Cannot set properties of undefined (setting 'scrollTop') ``` Issue: ------------------------------------ The emoji picker component updates its scroll position through a grid reference. After this PR - https://github.com/odoo/odoo/pull/269588, the emoji picker was migrated to Owl 3, which changed the way component references are handled. The header icon removal flow still uses the previous ref access pattern, causing the grid reference to be `undefined` when attempting to update `scrollTop`, resulting in a traceback. Solution: ------------------------------------ Update the syntax for accessing the ref signal.
Instagram posts with images no longer crash the server when Instagram takes too long to fetch or process the image. Instead, the post is marked as failed with a clearer message, helping users understand the issue and try a smaller image.
Original PR description
Making an Instagram containing an image can crash the server with an unhandled `ReadTimeout` instead of marking the post as failed. ### Cause When creating a media container, Odoo passes a URL pointing to its own server and Instagram fetches the image from it server-side before responding. The timeout therefore covers network latency, Instagram's download speed from the Odoo server, and image processing time, making it prone to being exceeded. When it is, `requests` raises a `ReadTimeout` which is unhandled, leading to a raw RPC error instead of a clean `state='failed'`. ### Fix Catch the network errors and mark the post as failed instead of letting them crash the request. Timeouts get a message suggesting a smaller image, since they are usually caused by Instagram fetching and processing a large image server-side. Any other request error falls back to a generic message. opw-6015997 Forward-Port-Of: odoo/enterprise#122406 Forward-Port-Of: odoo/enterprise#112573
The Argentine VAT Book ZIP export no longer fails when invoices involve foreign partners marked as overseas providers. This helps accounting teams complete required tax reporting without manual workarounds or blocked exports.
Original PR description
Steps to reproduce: - Create a partner with: - State: Ireland - Identification Number: Foreign ID 55000004153 - ARCA Responsibility Type: Proveedor del Exterior - Create an invoice for the partner - Accounting > Reporting > Tax report - Select Report: VAT Book (AR), Tax Type: Sales - Click on gear icon > VAT Book (ZIP) Issue: Action will be blocked with error "No VAT configured for partner [58] <partner>" Analysis: Partners with ARCA responsibility type 'Proveedor del Exterior' (code 8) and a ForeignID identification type, causes a UserError when exporting the VAT Book (ZIP). Code 8 (foreign provider) is the purchase-side counterpart of code 9 (foreign customer), which already fell back to the country-level VAT. Extend the existing fallback branch to cover both codes. opw-6316008 Forward-Port-Of: odoo/enterprise#123506
Rental planning now handles company-wide time off more accurately by applying it only to resources on the matching working schedule, unless the time off is truly global. The change also strengthens rental planning website and backend tests, reducing the risk of incorrect availability or booking behavior.
Original PR description
## [FIX] sale_renting_planning: check global leaves working schedule Before this commit: any `resource.calendar.leaves` with no `resource_id` created would prevent all resources from being allocated…
## [FIX] sale_renting_planning: check global leaves working schedule
Before this commit: any `resource.calendar.leaves` with no `resource_id` created would prevent all resources from being allocated during the leave date.
After this commit: any `resource.calendar.leaves` with `no resource_id` would be applied only to resources with the same `calendar_id` as the leave.
if the leave has no `calendar_id` then the leave applies to all `resource.calendars`
if a resource has no `calendar_id` then leaves with no `calendar_id` apply to it as well
## [IMP] {website_}sale_renting_planning: move tests from industry and fix existing ones
This commit moves the tests from [odoo/industry#1980](vscode-file://vscode-app/snap/code/237/usr/share/code/resources/app/out/vs/code/electron-browser/workbench/workbench.html) to their respective standard modules.
It also fixes the logic behind some tests as they weren't testing a `planning.role` with `sync_shift_rental` enabled.
task-6179505
Forward-Port-Of: odoo/enterprise#120983
Forward-Port-Of: odoo/enterprise#116430This fixes an automated test issue that could fail when tax return validation triggered PDF generation at the same time as browser activity. The change avoids running the real PDF rendering step during the test, improving test reliability without changing the user-facing tax return workflow.
Original PR description
Validating a return renders the report to a PDF via wkhtmltopdf inside the `action_validate` request. During the render, the HttpCase test cursor is reserved for wkhtmltopdf, so any browser RPC that overlaps the render window is rejected, resulting in ConnectionLostError. Patching the `_run_wkhtmltopdf` so no real rendering runs during the tour. runbot-243444 Forward-Port-Of: odoo/enterprise#123809 Forward-Port-Of: odoo/enterprise#123720
This update fixes an automated Knowledge app tour that was failing after a property type selector changed from a dropdown button to a select menu. It also makes the tour more reliable by addressing timing issues, helping prevent false test failures during quality checks.
Original PR description
The dropdown for property definition type was replaced with a select menu, leading to an error in the tour as it tried to search for the previous implementation which contained a button. There are also changes to fix the race conditions that exist in the tour which were not evident due to the original issue Related pr: https://github.com/odoo/odoo/pull/234484 runbot-238409 Forward-Port-Of: odoo/enterprise#121958
Appointment picture and list layouts now use the website's configured tax display setting when showing product prices. This prevents customers from seeing tax-excluded prices on websites configured to display tax-included pricing, improving consistency and avoiding confusion.
Original PR description
When the `appointments_template_picture` and `appointments_template_list` templates were added to `website_appointment_account_payment` in 19.0+, the corresponding overrides in `website_appointment_sale` were not added. This caused the picture and list appointment blocks to display prices using `product_lst_price` (always tax-excluded), ignoring the website's tax display setting (`show_line_subtotals_tax_selection`). The cards template already had a proper override using `_get_combination_info()`, which correctly handles everything. Steps to reproduce: 1. Go to Website > Configuration > Settings > enable "Tax Included" 2. Create an appointment type with a product that has taxes 3. Edit website page > add "Appointments" snippet > select "Picture" or "List" layout => price shown is tax-excluded Ticket [link](https://www.odoo.com/odoo/project.task/5799252) opw-5799252 Forward-Port-Of: odoo/enterprise#123448 Forward-Port-Of: odoo/enterprise#106643
Fixed a display issue in Planning where material resource rows could have the wrong height after a field type change. This keeps planning lists easier to read and prevents visual misalignment when resources are shown with avatars.
Original PR description
commit - https://github.com/odoo/enterprise/pull/106700/changes/3f27d96bda7c0b20683adb3fc1d38b5c3279c4a4 When the resource field was converted from m2o to m2m, the corresponding SCSS selector in the planning list was not updated. so the row height was not adjusted correctly for material resources using the m2m avatar widget. Forward-Port-Of: odoo/enterprise#123894
19 changes
Resolved issues and error corrections
Bank reconciliation entries using tax-based models now show the correct tax base amount immediately. This prevents accounting reports and journal entry reviews from displaying misleading zero base amounts until a manual reset is performed.
Original PR description
### Steps to reproduce the issue: 1. Download Accounting 2. Go to Journal entries and create a new one 3. Click Toggle Studio button and go to the view to add the tax_base_amount field to the list of…
### Steps to reproduce the issue: 1. Download Accounting 2. Go to Journal entries and create a new one 3. Click Toggle Studio button and go to the view to add the tax_base_amount field to the list of existing fields 4. Add 2 lines (example): 1. account Product Sales with 1000 dollars credit and 15% tax under Tax column 2. account Bank with 1000 dollars debit 5. Go to Dashboard > Bank > Click the 3 dots of one random bank matching line and click on Manage Models 6. Go to bank fees and add the 15% tax 7. Go back to bank reconciliation and create a new one of 2000 dollars with label bank fees (it will associate the tax automatically) 8. Go back to Journal Entries, group by Journal and search for the transaction of 2000 sollars for account Bank 9. Problem: see that the Base Amount for the 15% bank fees lines (251000 Tax Received account) is 0. Clicking on Reset to draft button the base amount column is automatically updated but this should happen automatically ### Cause of the issue: This occurs because the _lines_prepare_tax_line method in account.bank.statement.line fails to map this field in its return dictionary. ### Reason to introduce the fix: Currently, when applying a reconciliation model with taxes the generated tax lines incorrectly record a tax_base_amount of $0.00. Instead, it should be displayed and calculated. opw-6220948 Forward-Port-Of: odoo/enterprise#123603 Forward-Port-Of: odoo/enterprise#122139
This change corrects outdated internal field references in the POS pricer module after a previous rename. It prevents installation failures when demo data is loaded, helping ensure smoother setup and testing of the module.
Original PR description
The field `pricer_product_to_create_or_update` was renamed to `needs_pricer_update` in the following upgrade commit: https://github.com/odoo/upgrade/commit/bda95f88a6e644bb18b5669ef1a23d49a0111f00 However, two instances were missed in `account_tax.py` and `product_supplierinfo.py`. This caused tracebacks during module installation when loading demo data. Task [link](https://www.odoo.com/odoo/project.task/6373263) task-6373263 Forward-Port-Of: odoo/enterprise#123698
Expense creation from documents now works for authorized users even when their account is not linked to an employee profile. This removes an unnecessary blocker while still requiring the proper permissions to create expenses for other employees.
Original PR description
Removes the constraint saying a user has to be linked to an employee to create an expense from a document. In this case, the user still needs the rights to create an expense for another employee. task-6237021 Forward-Port-Of: odoo/enterprise#123635 Forward-Port-Of: odoo/enterprise#118955
The Barcode app now respects operation settings that block extra products, even after all reserved items have been scanned and the transfer is reopened. This prevents warehouse users from accidentally adding unplanned products to restricted transfers, improving inventory accuracy.
Original PR description
# How to reproduce - Go to Inventory > Settings > Operation Types - Pick any Operation and disable "Allow extra product" - Create a picking for that operation type with atleast one product and click…
# How to reproduce - Go to Inventory > Settings > Operation Types - Pick any Operation and disable "Allow extra product" - Create a picking for that operation type with atleast one product and click on "Mark as Todo" - Go to the Barcode app and find the created picking - Scan all the reserved products - Exit the picking and re-enter # The problem The "Add Product" button is displayed and you can scan unreserved products even tough you sould not be allowed to # Cause of the issue The problem stems from the fact that even with "Allow extra product" disabled, we still allow to add unreserved products for immediate transfers (created directly in the barcode app). The issue is that we don't really have a way to distinguish immediate transfers from plannified ones made in the Inventory app. So we try to guess using the `_useReservation` attribute (If it is false, we allow additional products). `_useReservation` is computed as follows : if any move lines from the inital state is not yet picked, set it to true : https://github.com/odoo/enterprise/blob/ca4b369e4fc9f4655574cf1ca71c81faaadc3e88/stock_barcode/static/src/models/barcode_picking_model.js#L43 So in our case, once all the reserved products are scanned, all the initial move lines are picked and our guessing fails. # Proposed Solution Since immediate transfers are never validated and stays in draft mode, guess using the state of the current picking in addition to `useReservation` opw-6231238 Forward-Port-Of: odoo/enterprise#118378
Czech VAT control statements now place invoices for customers with foreign VAT numbers in the correct section. This prevents non-domestic transactions over 10,000 CZK from being reported as domestic, improving tax report accuracy and compliance.
Original PR description
With l10n_cz company: - Create an invoice for a partner with a foreign vat (EU) with an amount greater than 10000 CZ and a 21% tax. In the vat control statement of the tax report, the move is classified under A4. But the section A4 should only contain move with domestic vat opw-6268506 Forward-Port-Of: odoo/enterprise#120002
Instagram image posts are now handled more reliably when Instagram takes too long or hits a network problem while fetching the image. Instead of causing a server error, the post is marked as failed with a clearer message, helping users understand what went wrong and what to try next.
Original PR description
Making an Instagram containing an image can crash the server with an unhandled `ReadTimeout` instead of marking the post as failed. ### Cause When creating a media container, Odoo passes a URL pointing to its own server and Instagram fetches the image from it server-side before responding. The timeout therefore covers network latency, Instagram's download speed from the Odoo server, and image processing time, making it prone to being exceeded. When it is, `requests` raises a `ReadTimeout` which is unhandled, leading to a raw RPC error instead of a clean `state='failed'`. ### Fix Catch the network errors and mark the post as failed instead of letting them crash the request. Timeouts get a message suggesting a smaller image, since they are usually caused by Instagram fetching and processing a large image server-side. Any other request error falls back to a generic message. opw-6015997 Forward-Port-Of: odoo/enterprise#112573
Employees and managers can now request an appraisal even when the next appraisal date has already passed. This removes an unnecessary error that blocked users who could not manually change appraisal dates, making delayed appraisal workflows smoother.
Original PR description
# How to reproduce You need to simulate the fact that you are creating an appraisal late so either : A) Directly edit the `next_appraisal_date` in SQL B) Go to Employee App > any Employee > Settings,…
# How to reproduce You need to simulate the fact that you are creating an appraisal late so either : A) Directly edit the `next_appraisal_date` in SQL B) Go to Employee App > any Employee > Settings, set Next Appraisal Date to tomorrow and wait for 2 days Then : - Click on Request Appraisal - Save # The problem An error is shown saying "You cannot set 'Next Appraisal Date' in the past.". You can workaround this by changing the Next Appraisal Date to a date in the future, but the problem is not every user has the right to do this. # Cause `next_appraisal_date` is also defined in hr.appraisal as a relate field of hr.employee : https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_appraisal/models/hr_appraisal.py#L56-L57 When creating an hr.appraisal, `next_appraisal_date` is present in `vals_list` because it is defined in the view since : https://github.com/odoo/enterprise/commit/58fba3098f33db82dfbccca2db229550402ed3ab https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_appraisal/views/hr_appraisal_views.xml#L92 This triggers a write on `next_appraisal_date` of hr.employee which triggers a constraint : https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_appraisal/models/hr_employee.py#L81-L85 opw-6147865 Forward-Port-Of: odoo/enterprise#122440 Forward-Port-Of: odoo/enterprise#114876
Fixed an issue where expanding a folded Knowledge article could show only favorited child articles while hiding other children. Users can now reliably see the full article hierarchy in the sidebar without needing to reload.
Original PR description
The sidebar always loads the user's favorite articles along with the visible ones, so a favorited article is shown as a root of the favorite tree. When that favorite is also a child of a folded…
The sidebar always loads the user's favorite articles along with the visible ones, so a favorited article is shown as a root of the favorite tree. When that favorite is also a child of a folded article, it gets added to its parent's child_ids in the main tree, even though the parent's other children were not fetched. A folded article only gets its favorited children back from get_sidebar_articles, not its whole child set. When the parent is then unfolded, unfold() only read the children from the database when child_ids was empty. The favorited child already filled child_ids, so the call was skipped and the remaining children stayed hidden until the next reload. unfold() now uses a new children_loaded flag instead of the length of child_ids to decide whether to fetch the children. The flag is set once an article's whole child set is loaded: in loadChildren(), and in loadArticles() for the articles that were unfolded, since those come back with all their children. loadChildren() also rebuilds child_ids from the search result so a favorite already loaded is not added twice. The fix lives in the sidebar component because the partial child_ids only exists on the frontend, get_sidebar_articles already returns the right records. Steps to reproduce: 1. Open the Knowledge app 2. Create an article with two child articles 3. Add one of the two children to your favorites with the star icon 4. Open another article that is not under that parent 5. Fold the parent article in the sidebar, then refresh the page 6. Expand the parent article => only the favorited child is shown under the parent, the other child is missing Ticket [link](https://www.odoo.com/odoo/project.task/6186466) opw-6186466 Forward-Port-Of: odoo/enterprise#118804
The tax return validation test was adjusted to avoid running the real PDF rendering step during automated browser testing. This prevents intermittent connection errors in test runs, helping keep release validation reliable without changing the user-facing tax return workflow.
Original PR description
Validating a return renders the report to a PDF via wkhtmltopdf inside the `action_validate` request. During the render, the HttpCase test cursor is reserved for wkhtmltopdf, so any browser RPC that overlaps the render window is rejected, resulting in ConnectionLostError. Patching the `_run_wkhtmltopdf` so no real rendering runs during the tour. runbot-243444 Forward-Port-Of: odoo/enterprise#123720
This fix adjusts internal tests so the timesheet assistant is set up only after its required test data handlers are ready. It helps prevent false test failures and supports more reliable delivery of timesheet-related updates.
Original PR description
Before this commit, the component was mounted in the `beforeEach` block before its `onRpc` mocks were registered. This caused the initial data fetch to fail because the mocks were not yet available during initialization. This commit fixes the test by moving the component mount (`doAction`) inside the test block, strictly after the mocks are defined. Forward-Port-Of: odoo/enterprise#123683
Belgian certified POS receipts now show the required fiscal device and POS software version information again. This helps businesses using the blackbox setup keep receipts and POS identification aligned with compliance expectations.
Original PR description
- store the FDM software version on the order and print both `fdmSwVersion` and `posSwVersion` on the receipt - show POS ID and POS software version in the navbar burger menu - assert the restored fields in the blackbox oracle tour FW of https://github.com/odoo/enterprise/pull/123839 Task-id: 5864870
The planning app now shows the correct wording when a single resource lacks the required role for a shift. This avoids an unprofessional typo in a user-facing warning and makes the message clearer for planners.
Original PR description
Currently, when a (or multiple) resource(s) do not have the role for a particular shift, a warning is displayed. However, in the case where only one resource does not have the correct role, the following warning was displayed, "resource_name don't have the required role for this shift", instead of "doesn't". task-6153932
This fix prevents an error when validating refunded point-of-sale orders for Kenyan companies using eTIMS/OSCU. Refunds and batches of offline orders can now be processed correctly, reducing checkout disruption and manual follow-up.
Original PR description
Steps to reproduce: 1. Install `l10n_ke_edi_oscu_pos`, set company to Kenya. 2. Sell and validate an order. 3. Refund it from the POS and validate the refund order. Issue: - A traceback is raised…
Steps to reproduce: 1. Install `l10n_ke_edi_oscu_pos`, set company to Kenya. 2. Sell and validate an order. 3. Refund it from the POS and validate the refund order. Issue: - A traceback is raised when validating the refund: `ValueError: Expected singleton: pos.order(<refund>, <original>)` raised in `get_l10n_ke_edi_oscu_pos_data`. Cause: - When syncing a refund, `sync_from_ui` returns both the new refund order and the original refunded order. `waitForPushOrder` forces post-processing for every Kenyan order in that list, so `beforePostPushOrderResolve` receives both ids in `order_server_ids` and forwards them as-is to `action_post_order` and `get_l10n_ke_edi_oscu_pos_data`, both of which expect a single record. `action_post_order` fails the same way, but its error was silently swallowed by the surrounding try/catch, letting the traceback surface only on the second call. - The same multi-id list is also produced whenever several orders created offline get synced together once back online. Solution: - `get_l10n_ke_edi_oscu_pos_data` is only needed for the receipt of the order being validated, so call it with `order.id` instead of the full `order_server_ids` list. - Replace the `action_post_order` call with `action_post_selected_orders`, which posts each order individually and skips ones already sent to eTIMS, correctly handling both the refund case (original order is already `sent`) and the offline multi-order sync case. opw-6364221 Forward-Port-Of: odoo/enterprise#123043
This update fixes cases where the social feed action menu appeared empty, improves reliability when refreshing feeds by allowing longer batch requests, and resolves LinkedIn image upload failures. These changes help social media users manage posts and leads more smoothly with fewer interruptions.
Original PR description
Bug 1 === Since b75755ea8ac65ce5ce973412e3c4194fa1bd6fd3 , the menu on the stream post could be visible but empty. The reason is that we checked for `this.isConvertibleToLead` instead of `this.isConvertibleToLead()`. We take advantage of this bug fix to correctly overwrite the condition without replacing the entire button (which can break other module overwriting the same element). Bug 2 === Sometimes, when refreshing the feed view, an error occurs because the request timeout. To fix it, we increase the timeout when doing requests in batch. Bug 3 === When uploading an image in LinkedIn, an error happens. The reason is that `LocalBinaryFile` is now returned when reading Binary field, and in the requests API, the `data` arguments expect the bytes. (for other media, we upload the image with `file` argument). Task-6254983
Appointment blocks using picture or list layouts now show prices according to the website's tax display setting. This prevents customers from seeing tax-excluded prices when the site is configured to show tax-included prices.
Original PR description
When the `appointments_template_picture` and `appointments_template_list` templates were added to `website_appointment_account_payment` in 19.0+, the corresponding overrides in `website_appointment_sale` were not added. This caused the picture and list appointment blocks to display prices using `product_lst_price` (always tax-excluded), ignoring the website's tax display setting (`show_line_subtotals_tax_selection`). The cards template already had a proper override using `_get_combination_info()`, which correctly handles everything. Steps to reproduce: 1. Go to Website > Configuration > Settings > enable "Tax Included" 2. Create an appointment type with a product that has taxes 3. Edit website page > add "Appointments" snippet > select "Picture" or "List" layout => price shown is tax-excluded Ticket [link](https://www.odoo.com/odoo/project.task/5799252) opw-5799252 Forward-Port-Of: odoo/enterprise#106643
The Argentine VAT Book ZIP export now handles foreign provider partners correctly. This prevents exports from being blocked by a missing VAT error, helping accounting teams complete required tax reporting for transactions with foreign partners.
Original PR description
Steps to reproduce: - Create a partner with: - State: Ireland - Identification Number: Foreign ID 55000004153 - ARCA Responsibility Type: Proveedor del Exterior - Create an invoice for the partner - Accounting > Reporting > Tax report - Select Report: VAT Book (AR), Tax Type: Sales - Click on gear icon > VAT Book (ZIP) Issue: Action will be blocked with error "No VAT configured for partner [58] <partner>" Analysis: Partners with ARCA responsibility type 'Proveedor del Exterior' (code 8) and a ForeignID identification type, causes a UserError when exporting the VAT Book (ZIP). Code 8 (foreign provider) is the purchase-side counterpart of code 9 (foreign customer), which already fell back to the country-level VAT. Extend the existing fallback branch to cover both codes. opw-6316008 Forward-Port-Of: odoo/enterprise#123506
The timesheet assistant now shows the envelope icon again for existing email-based matching rules. This keeps older rules visually clear while preserving support for Gmail-related activities.
Original PR description
Issue: The email activity icon (fa-envelope) is not displayed for matched email rules. Cause: The email icon mapping was replaced with gmail_activity to support Gmail events. However, existing aw.rule records still use the email activity type, causing an icon key mismatch. Fix: Restore the email icon mapping while keeping the gmail_activity mapping so both activity types display the email icon. Task-6370391
The shop floor order list now places manufacturing orders with scheduled work ahead of unscheduled ones. This helps operators see planned work in the expected priority order and reduces confusion when managing work centers.
Original PR description
## Problem In shop floor, MOs with unplanned work orders get sorted before MOs that have planned operations, which contradicts the normal nulls last sorting for work orders. ## Solution We will…
## Problem In shop floor, MOs with unplanned work orders get sorted before MOs that have planned operations, which contradicts the normal nulls last sorting for work orders. ## Solution We will update the sorting logic in the MrpDisplay component to more gracefully handle falsy date_start values, sorting them to the end. ## Steps to reproduce (runbot 19) 1. Create 2 MOs with an operation (work order) involving a work center, we'll call them A and B. 2. Open Shop Floor and open the work center that the MOs' work orders belong to, and note they are ordered A, B (this is fine, neither are planned so the precedence falls back to id 3. Go back to MO B and plan it. This should give it precedence in Shop Floor 4. Under the work center in Shop Floor, note that the MOs are still ordered A, B, despite B's work order having a start date and A's work order not having one To further motivate this being unintended, you can go to Manufacturing > Operations > Work Orders, and you'll see MO B's work order sitting at the top of the list. opw-6303323 Forward-Port-Of: odoo/enterprise#121885 Forward-Port-Of: odoo/enterprise#121693
This fixes an automated Knowledge app test that was failing after a dropdown was changed to a select menu. It also makes the test more reliable by addressing timing issues, helping ensure future updates are validated consistently.
Original PR description
The dropdown for property definition type was replaced with a select menu, leading to an error in the tour as it tried to search for the previous implementation which contained a button. There are also changes to fix the race conditions that exist in the tour which were not evident due to the original issue Related pr: https://github.com/odoo/odoo/pull/234484 runbot-238409 Forward-Port-Of: odoo/enterprise#121958
15 changes
Resolved issues and error corrections
The project Gantt view now correctly shades unavailable periods when a user has employees in multiple selected companies. This keeps the visual schedule aligned with time-off warnings, helping planners avoid assigning work during approved absences.
Original PR description
Steps to reproduce: - Create one user linked to two companies. - Create one employee per company for that user. - Select one company and approve a time off for the employee. - Open Tasks > Gantt and…
Steps to reproduce: - Create one user linked to two companies. - Create one employee per company for that user. - Select one company and approve a time off for the employee. - Open Tasks > Gantt and create a task during the approved time-off period the warning is shown and the Gantt cell is grayed out. - Select both companies and create a task during the same time-off period in Tasks > Gantt. Issue: When multiple companies are selected, the time-off warning is still displayed but the corresponding Gantt cells are no longer grayed out, leading to an inconsistency between the warning logic and the Gantt rendering. Cause: In multi-company setups, a user can be linked to multiple resources. The Gantt unavailability logic assumed a one-to-one relationship between user and resource causing unavailability intervals from some resources to be overwritten. Solution: Aggregate unavailability intervals from all resources linked to the same user, limited to the selected companies, and merge them with the company calendar unavailability to ensure consistent Gantt gray rendering. Related PR: https://github.com/odoo/enterprise/pull/57028 task-5089385 Forward-Port-Of: odoo/enterprise#123659 Forward-Port-Of: odoo/enterprise#105288
Canadian check printing now hides check numbers on payment stubs when pre-numbered checks are used. This keeps the stub layout consistent with the check itself and avoids showing duplicate or misleading numbering.
Original PR description
The check itself respected the check_manual_sequencing field, but the stubs did not. Hide the numbers on stubs as well, exactly like on US checks. task-6343701 Forward-Port-Of: odoo/enterprise#122565
Users who are not linked to an employee can now create an expense from a document, provided they already have permission to create expenses for another employee. This removes an unnecessary blocker while keeping existing access controls in place.
Original PR description
Removes the constraint saying a user has to be linked to an employee to create an expense from a document. In this case, the user still needs the rights to create an expense for another employee. task-6237021 Forward-Port-Of: odoo/enterprise#123635 Forward-Port-Of: odoo/enterprise#118955
This fixes a Barcode app issue where users could scan additional unreserved products after completing the reserved items, even when the operation type disabled extra products. The change keeps inventory operations aligned with their configuration and helps avoid unintended stock movements.
Original PR description
# How to reproduce - Go to Inventory > Settings > Operation Types - Pick any Operation and disable "Allow extra product" - Create a picking for that operation type with atleast one product and click…
# How to reproduce - Go to Inventory > Settings > Operation Types - Pick any Operation and disable "Allow extra product" - Create a picking for that operation type with atleast one product and click on "Mark as Todo" - Go to the Barcode app and find the created picking - Scan all the reserved products - Exit the picking and re-enter # The problem The "Add Product" button is displayed and you can scan unreserved products even tough you sould not be allowed to # Cause of the issue The problem stems from the fact that even with "Allow extra product" disabled, we still allow to add unreserved products for immediate transfers (created directly in the barcode app). The issue is that we don't really have a way to distinguish immediate transfers from plannified ones made in the Inventory app. So we try to guess using the `_useReservation` attribute (If it is false, we allow additional products). `_useReservation` is computed as follows : if any move lines from the inital state is not yet picked, set it to true : https://github.com/odoo/enterprise/blob/ca4b369e4fc9f4655574cf1ca71c81faaadc3e88/stock_barcode/static/src/models/barcode_picking_model.js#L43 So in our case, once all the reserved products are scanned, all the initial move lines are picked and our guessing fails. # Proposed Solution Since immediate transfers are never validated and stays in draft mode, guess using the state of the current picking in addition to `useReservation` opw-6231238 Forward-Port-Of: odoo/enterprise#118378
The Knowledge automated tour was updated to match a recent interface change where a property type dropdown became a select menu. This prevents false test failures and improves reliability by addressing timing issues in the tour.
Original PR description
The dropdown for property definition type was replaced with a select menu, leading to an error in the tour as it tried to search for the previous implementation which contained a button. There are also changes to fix the race conditions that exist in the tour which were not evident due to the original issue Related pr: https://github.com/odoo/odoo/pull/234484 runbot-238409
Invoices from partners with foreign EU VAT numbers are now placed in the correct Czech VAT control statement section. This prevents qualifying non-domestic transactions from being incorrectly reported as domestic VAT entries, improving report accuracy and compliance.
Original PR description
With l10n_cz company: - Create an invoice for a partner with a foreign vat (EU) with an amount greater than 10000 CZ and a 21% tax. In the vat control statement of the tax report, the move is classified under A4. But the section A4 should only contain move with domestic vat opw-6268506 Forward-Port-Of: odoo/enterprise#120002
This fix prevents an error when users remove the start or end date from a field service planning shift. The change keeps shift editing stable by safely skipping break-time calculations when required dates are missing.
Original PR description
before: when removing the start and end date of a shift, a trace back happens in the `_onchange_break_time` cause: it depends on the start and end date values, so it breaks when they are falsy after: apply a guard to the `_onchange_break_time` function to check on those fields to avoid breaking it --- task-6361418
Fixed an issue where expanding a Knowledge article in the sidebar could show only favorited child articles while hiding the other children. This ensures users can reliably see the full article structure without needing to reload the page.
Original PR description
The sidebar always loads the user's favorite articles along with the visible ones, so a favorited article is shown as a root of the favorite tree. When that favorite is also a child of a folded…
The sidebar always loads the user's favorite articles along with the visible ones, so a favorited article is shown as a root of the favorite tree. When that favorite is also a child of a folded article, it gets added to its parent's child_ids in the main tree, even though the parent's other children were not fetched. A folded article only gets its favorited children back from get_sidebar_articles, not its whole child set. When the parent is then unfolded, unfold() only read the children from the database when child_ids was empty. The favorited child already filled child_ids, so the call was skipped and the remaining children stayed hidden until the next reload. unfold() now uses a new children_loaded flag instead of the length of child_ids to decide whether to fetch the children. The flag is set once an article's whole child set is loaded: in loadChildren(), and in loadArticles() for the articles that were unfolded, since those come back with all their children. loadChildren() also rebuilds child_ids from the search result so a favorite already loaded is not added twice. The fix lives in the sidebar component because the partial child_ids only exists on the frontend, get_sidebar_articles already returns the right records. Steps to reproduce: 1. Open the Knowledge app 2. Create an article with two child articles 3. Add one of the two children to your favorites with the star icon 4. Open another article that is not under that parent 5. Fold the parent article in the sidebar, then refresh the page 6. Expand the parent article => only the favorited child is shown under the parent, the other child is missing Ticket [link](https://www.odoo.com/odoo/project.task/6186466) opw-6186466 Forward-Port-Of: odoo/enterprise#118804
Kenyan point-of-sale refund validation no longer fails when the refund is synced together with the original sale. This keeps refund processing and eTIMS reporting working reliably, including when multiple offline orders are synced at once.
Original PR description
Steps to reproduce: 1. Install `l10n_ke_edi_oscu_pos`, set company to Kenya. 2. Sell and validate an order. 3. Refund it from the POS and validate the refund order. Issue: - A traceback is raised…
Steps to reproduce: 1. Install `l10n_ke_edi_oscu_pos`, set company to Kenya. 2. Sell and validate an order. 3. Refund it from the POS and validate the refund order. Issue: - A traceback is raised when validating the refund: `ValueError: Expected singleton: pos.order(<refund>, <original>)` raised in `get_l10n_ke_edi_oscu_pos_data`. Cause: - When syncing a refund, `sync_from_ui` returns both the new refund order and the original refunded order. `waitForPushOrder` forces post-processing for every Kenyan order in that list, so `beforePostPushOrderResolve` receives both ids in `order_server_ids` and forwards them as-is to `action_post_order` and `get_l10n_ke_edi_oscu_pos_data`, both of which expect a single record. `action_post_order` fails the same way, but its error was silently swallowed by the surrounding try/catch, letting the traceback surface only on the second call. - The same multi-id list is also produced whenever several orders created offline get synced together once back online. Solution: - `get_l10n_ke_edi_oscu_pos_data` is only needed for the receipt of the order being validated, so call it with `order.id` instead of the full `order_server_ids` list. - Replace the `action_post_order` call with `action_post_selected_orders`, which posts each order individually and skips ones already sent to eTIMS, correctly handling both the refund case (original order is already `sent`) and the offline multi-order sync case. opw-6364221 Forward-Port-Of: odoo/enterprise#123043
Appointment blocks using the picture or list layout now show prices according to the website's tax display setting. This prevents customers from seeing tax-excluded prices when the site is configured to show tax-included prices.
Original PR description
When the `appointments_template_picture` and `appointments_template_list` templates were added to `website_appointment_account_payment` in 19.0+, the corresponding overrides in `website_appointment_sale` were not added. This caused the picture and list appointment blocks to display prices using `product_lst_price` (always tax-excluded), ignoring the website's tax display setting (`show_line_subtotals_tax_selection`). The cards template already had a proper override using `_get_combination_info()`, which correctly handles everything. Steps to reproduce: 1. Go to Website > Configuration > Settings > enable "Tax Included" 2. Create an appointment type with a product that has taxes 3. Edit website page > add "Appointments" snippet > select "Picture" or "List" layout => price shown is tax-excluded Ticket [link](https://www.odoo.com/odoo/project.task/5799252) opw-5799252 Forward-Port-Of: odoo/enterprise#106643
The Argentine VAT Book ZIP export no longer fails for foreign partners marked as foreign providers. This helps businesses complete required tax reporting without manual workarounds when invoices involve overseas partners.
Original PR description
Steps to reproduce: - Create a partner with: - State: Ireland - Identification Number: Foreign ID 55000004153 - ARCA Responsibility Type: Proveedor del Exterior - Create an invoice for the partner - Accounting > Reporting > Tax report - Select Report: VAT Book (AR), Tax Type: Sales - Click on gear icon > VAT Book (ZIP) Issue: Action will be blocked with error "No VAT configured for partner [58] <partner>" Analysis: Partners with ARCA responsibility type 'Proveedor del Exterior' (code 8) and a ForeignID identification type, causes a UserError when exporting the VAT Book (ZIP). Code 8 (foreign provider) is the purchase-side counterpart of code 9 (foreign customer), which already fell back to the country-level VAT. Extend the existing fallback branch to cover both codes. opw-6316008 Forward-Port-Of: odoo/enterprise#123506
Fixed a display issue in the Planning list where rows for material resources could appear with the wrong height after the resource field was changed. This keeps the schedule easier to read and ensures resource avatars fit properly in the list view.
Original PR description
commit - https://github.com/odoo/enterprise/pull/106700/changes/3f27d96bda7c0b20683adb3fc1d38b5c3279c4a4 When the resource field was converted from m2o to m2m, the corresponding SCSS selector in the planning list was not updated. so the row height was not adjusted correctly for material resources using the m2m avatar widget.
This fixes the displayed total exemption amount in Belgian payroll 274 declarations. The correction helps payroll teams see accurate declaration totals, while the amount is used for display only and does not change payroll calculations.
Original PR description
The total exemption amount (only used for display) was wrongly computed.
Draft planning items in My Planning now use the expected hatched display instead of appearing like confirmed entries. This helps users quickly distinguish draft plans from regular calendar entries and avoid confusion when reviewing schedules.
Original PR description
Issue: Calendar entries appear plain even when they should appear hatched. (ex. while in draft status) Steps to reproduce: If you create any planning and set it to draft. Then go to Planning > Planning > My Planning, the newly created plan should be in hatched but it becomes plain. Cause: In the view planning.slot.my.calendar there was missing the element that causes the views to become hatched when in draft status. Solution: Added said element. opw-6260055
Payslip email activity now records a neutral sent-by-email note instead of incorrectly saying a payslip was re-sent the first time. When multiple employees are processed, each payslip receives only one chatter note, reducing confusion in payroll records.
Original PR description
**Issue:** Clicking Send By Email on a payslip opens the hr.payslip.send.mail wizard. Its action_send() always logs "The payslip has been re-send to the employee." in the payslip chatter, even when…
**Issue:** Clicking Send By Email on a payslip opens the hr.payslip.send.mail wizard. Its action_send() always logs "The payslip has been re-send to the employee." in the payslip chatter, even when the payslip is being sent for the first time. The log call also runs inside the loop over the employees and goes through all the payslips of the wizard on each pass, so when the wizard sends payslips of several employees every payslip gets the same note once per employee. This started with the rework of the wizard in https://github.com/odoo/enterprise/commit/39e0488a7e076ee648b47cc3d1cad41cadfd692e **Fix:** The wizard cannot tell a first send from a resend. There is no field on the payslip that keeps track of a previous send, and the chatter cannot be used for that either because the mail sent automatically on validation can be deleted after sending. The fix changes the log in action_send() to say the payslip has been sent by email, which is true in both cases, and moves it out of the employee loop so each payslip gets exactly one note. **Steps to reproduce:** 1. In Payroll > Configuration > Settings, set "Send payslips to employees" to When Paid and save 2. In Payroll > Payslips, create an off-cycle payslip for an employee, click Compute, then Validate 3. Go back to the settings and set "Send payslips to employees" to When Confirmed 4. On the payslip, click Pay, then Mark as Paid 5. Click Print so the payslip document is generated 6. Click Send By Email and send the mail 7. Check the payslip chatter => The chatter shows "The payslip has been re-send to the employee." while the payslip was never sent before Ticket [link](https://www.odoo.com/odoo/project.task/6324204) opw-6324204
10 changes
Resolved issues and error corrections
Subscription products that allow one-time purchases now correctly show the original price with a strikethrough next to the Buy Once price. This makes discounts or price comparisons clearer for shoppers and helps avoid confusion on product pages.
Original PR description
Version - saas-19.1 Steps to reproduce: - Enable 'Accept One Time Sale' on a subscription product - Open the product page on the website Issue: For subscription products with one time sale enabled, the original price was not shown as a strikethrough next to the Buy Once price. Fix: - Captured and exposed the original price to the template before it gets overwritten during subscription price processing - Added the missing strikethrough element to the Buy Once section of the product page Task ID - 6260207
This fixes an issue where status log messages for French reports could fail to display properly for accepted or rejected statuses. The correction ensures these messages render as intended, helping users understand report processing outcomes clearly.
Original PR description
A mismatch between error titles and status logs was introduced in 18.0. Markup wasn't added to the status logs, leading to a type mismatch (Markup + str) when displaying errors for 'accepted' or 'rejected' statuses. As a result, the logs were not interpreted as HTML. This commit ensures Markup is applied to each element to guarantee coherence and proper rendering. backport of 5113752 task-6053842 Forward-Port-Of: odoo/enterprise#123812 Forward-Port-Of: odoo/enterprise#123250
The barcode app now correctly respects operation settings that disable adding extra products. After all reserved items are scanned, users can no longer add or scan unreserved products on planned transfers where that option is turned off, helping maintain inventory process controls.
Original PR description
# How to reproduce - Go to Inventory > Settings > Operation Types - Pick any Operation and disable "Allow extra product" - Create a picking for that operation type with atleast one product and click…
# How to reproduce - Go to Inventory > Settings > Operation Types - Pick any Operation and disable "Allow extra product" - Create a picking for that operation type with atleast one product and click on "Mark as Todo" - Go to the Barcode app and find the created picking - Scan all the reserved products - Exit the picking and re-enter # The problem The "Add Product" button is displayed and you can scan unreserved products even tough you sould not be allowed to # Cause of the issue The problem stems from the fact that even with "Allow extra product" disabled, we still allow to add unreserved products for immediate transfers (created directly in the barcode app). The issue is that we don't really have a way to distinguish immediate transfers from plannified ones made in the Inventory app. So we try to guess using the `_useReservation` attribute (If it is false, we allow additional products). `_useReservation` is computed as follows : if any move lines from the inital state is not yet picked, set it to true : https://github.com/odoo/enterprise/blob/ca4b369e4fc9f4655574cf1ca71c81faaadc3e88/stock_barcode/static/src/models/barcode_picking_model.js#L43 So in our case, once all the reserved products are scanned, all the initial move lines are picked and our guessing fails. # Proposed Solution Since immediate transfers are never validated and stays in draft mode, guess using the state of the current picking in addition to `useReservation` opw-6231238 Forward-Port-Of: odoo/enterprise#118378
Invoices for partners with foreign EU VAT numbers are now placed in the correct Czech VAT control statement section. This prevents non-domestic transactions from being incorrectly grouped with domestic VAT entries, improving tax reporting accuracy.
Original PR description
With l10n_cz company: - Create an invoice for a partner with a foreign vat (EU) with an amount greater than 10000 CZ and a 21% tax. In the vat control statement of the tax report, the move is classified under A4. But the section A4 should only contain move with domestic vat opw-6268506 Forward-Port-Of: odoo/enterprise#120002
Audit reports now update the number of invalid records when a check is reviewed and no longer finds issues. This prevents users from seeing outdated anomaly counts after a check has been successfully cleared.
Original PR description
Problem: Sometimes after an audit check passes (gets reviewed successfully), the count of invalid records in the audit report is not updated. Steps to reproduce: 1. Add a check for an audit cycle 2. Make sure the check's domain is satisified by at least one record 3. Check the audit report and see the check you added 4. The check status should show an anomaly and the count of invalid records will be greater than 0 5. Now, edit the check so that the domain is not satisfied by any record 6. Check the audit report again and see the check you edited 7. The check status should show "Reviewed" but the count of invalid records will still be greater than 0, which is not correct Cause: When updating the status of an audit check, the count of invalid records is not updated, only the status gets updated. opw-6264177 Forward-Port-Of: odoo/enterprise#119227
Fixed an issue where expanding a Knowledge article in the sidebar could show only favorited child articles while hiding the rest. Users can now reliably see all child articles without needing to reload, improving navigation in Knowledge workspaces.
Original PR description
The sidebar always loads the user's favorite articles along with the visible ones, so a favorited article is shown as a root of the favorite tree. When that favorite is also a child of a folded…
The sidebar always loads the user's favorite articles along with the visible ones, so a favorited article is shown as a root of the favorite tree. When that favorite is also a child of a folded article, it gets added to its parent's child_ids in the main tree, even though the parent's other children were not fetched. A folded article only gets its favorited children back from get_sidebar_articles, not its whole child set. When the parent is then unfolded, unfold() only read the children from the database when child_ids was empty. The favorited child already filled child_ids, so the call was skipped and the remaining children stayed hidden until the next reload. unfold() now uses a new children_loaded flag instead of the length of child_ids to decide whether to fetch the children. The flag is set once an article's whole child set is loaded: in loadChildren(), and in loadArticles() for the articles that were unfolded, since those come back with all their children. loadChildren() also rebuilds child_ids from the search result so a favorite already loaded is not added twice. The fix lives in the sidebar component because the partial child_ids only exists on the frontend, get_sidebar_articles already returns the right records. Steps to reproduce: 1. Open the Knowledge app 2. Create an article with two child articles 3. Add one of the two children to your favorites with the star icon 4. Open another article that is not under that parent 5. Fold the parent article in the sidebar, then refresh the page 6. Expand the parent article => only the favorited child is shown under the parent, the other child is missing Ticket [link](https://www.odoo.com/odoo/project.task/6186466) opw-6186466 Forward-Port-Of: odoo/enterprise#118804
Fixes an issue that could block Kenyan POS refund validation with an error when the refund and original sale were processed together. Refunds and batches of offline orders are now handled correctly for eTIMS posting, helping cashiers complete refunds and sync orders smoothly.
Original PR description
Steps to reproduce: 1. Install `l10n_ke_edi_oscu_pos`, set company to Kenya. 2. Sell and validate an order. 3. Refund it from the POS and validate the refund order. Issue: - A traceback is raised…
Steps to reproduce: 1. Install `l10n_ke_edi_oscu_pos`, set company to Kenya. 2. Sell and validate an order. 3. Refund it from the POS and validate the refund order. Issue: - A traceback is raised when validating the refund: `ValueError: Expected singleton: pos.order(<refund>, <original>)` raised in `get_l10n_ke_edi_oscu_pos_data`. Cause: - When syncing a refund, `sync_from_ui` returns both the new refund order and the original refunded order. `waitForPushOrder` forces post-processing for every Kenyan order in that list, so `beforePostPushOrderResolve` receives both ids in `order_server_ids` and forwards them as-is to `action_post_order` and `get_l10n_ke_edi_oscu_pos_data`, both of which expect a single record. `action_post_order` fails the same way, but its error was silently swallowed by the surrounding try/catch, letting the traceback surface only on the second call. - The same multi-id list is also produced whenever several orders created offline get synced together once back online. Solution: - `get_l10n_ke_edi_oscu_pos_data` is only needed for the receipt of the order being validated, so call it with `order.id` instead of the full `order_server_ids` list. - Replace the `action_post_order` call with `action_post_selected_orders`, which posts each order individually and skips ones already sent to eTIMS, correctly handling both the refund case (original order is already `sent`) and the offline multi-order sync case. opw-6364221 Forward-Port-Of: odoo/enterprise#123043
Appointment blocks using the picture or list layout now show prices according to the website's tax display setting. This prevents customers from seeing tax-excluded prices when the website is configured to show tax-included pricing.
Original PR description
When the `appointments_template_picture` and `appointments_template_list` templates were added to `website_appointment_account_payment` in 19.0+, the corresponding overrides in `website_appointment_sale` were not added. This caused the picture and list appointment blocks to display prices using `product_lst_price` (always tax-excluded), ignoring the website's tax display setting (`show_line_subtotals_tax_selection`). The cards template already had a proper override using `_get_combination_info()`, which correctly handles everything. Steps to reproduce: 1. Go to Website > Configuration > Settings > enable "Tax Included" 2. Create an appointment type with a product that has taxes 3. Edit website page > add "Appointments" snippet > select "Picture" or "List" layout => price shown is tax-excluded Ticket [link](https://www.odoo.com/odoo/project.task/5799252) opw-5799252 Forward-Port-Of: odoo/enterprise#106643
Duplicating certain Sign templates with multiple documents, signers, and fields could fail because the system tried to reuse already-processed signer information incorrectly. This fix skips signer records that have already been handled, making template duplication reliable again.
Original PR description
Issue: This [loop](https://github.com/odoo-dev/enterprise/blob/55bb2cc570451361701d53583f019ed832a5e5d3/sign/models/sign_item.py#L59-L63) runs multiple times with the same approvers(sign.item.role), but doesn't take into account the already 'seen map' inside the base copy function for batching. If they are already seen they will return a non-iterable [None]. To replicate: 1) Sign -> Template -> upload PDF 2) Go into the template 3) Add 2 Documents, with 2 signers and multiple fields on both documents 4) Save -> gear Icon -> make into template 5) Go back to the list view of templates 6) Select the template -> Gear Icon -> Duplicate Fix: add an already seen check to skip if already seen. opw-6352408 Forward-Port-Of: odoo/enterprise#122667
The Argentine VAT Book ZIP export no longer fails when invoices involve foreign providers using a Foreign ID. This helps accounting teams generate the required VAT reports without manual workarounds or blocked exports.
Original PR description
Steps to reproduce: - Create a partner with: - State: Ireland - Identification Number: Foreign ID 55000004153 - ARCA Responsibility Type: Proveedor del Exterior - Create an invoice for the partner - Accounting > Reporting > Tax report - Select Report: VAT Book (AR), Tax Type: Sales - Click on gear icon > VAT Book (ZIP) Issue: Action will be blocked with error "No VAT configured for partner [58] <partner>" Analysis: Partners with ARCA responsibility type 'Proveedor del Exterior' (code 8) and a ForeignID identification type, causes a UserError when exporting the VAT Book (ZIP). Code 8 (foreign provider) is the purchase-side counterpart of code 9 (foreign customer), which already fell back to the country-level VAT. Extend the existing fallback branch to cover both codes. opw-6316008 Forward-Port-Of: odoo/enterprise#123506
6 changes
Resolved issues and error corrections
This corrects an internal test setup issue for Hong Kong payroll related to leave generation. It helps ensure payroll checks run reliably in newer versions, reducing the risk of unnoticed issues during upgrades.
Original PR description
Which was missed during fwp due to these test not running on Runbot before version 19. Forward-Port-Of: odoo/enterprise#123649
This fix ensures status logs in French reports are rendered consistently when export results are accepted or rejected. Users should now see the intended error and status details instead of broken or incorrectly displayed log content.
Original PR description
A mismatch between error titles and status logs was introduced in 18.0. Markup wasn't added to the status logs, leading to a type mismatch (Markup + str) when displaying errors for 'accepted' or 'rejected' statuses. As a result, the logs were not interpreted as HTML. This commit ensures Markup is applied to each element to guarantee coherence and proper rendering. backport of 5113752 task-6053842 Forward-Port-Of: odoo/enterprise#123250
Fixed an issue where expanding a Knowledge article in the sidebar could show only favorited child articles while hiding the others. Users can now reliably see the full set of child articles without needing to reload the page, improving navigation consistency.
Original PR description
The sidebar always loads the user's favorite articles along with the visible ones, so a favorited article is shown as a root of the favorite tree. When that favorite is also a child of a folded…
The sidebar always loads the user's favorite articles along with the visible ones, so a favorited article is shown as a root of the favorite tree. When that favorite is also a child of a folded article, it gets added to its parent's child_ids in the main tree, even though the parent's other children were not fetched. A folded article only gets its favorited children back from get_sidebar_articles, not its whole child set. When the parent is then unfolded, unfold() only read the children from the database when child_ids was empty. The favorited child already filled child_ids, so the call was skipped and the remaining children stayed hidden until the next reload. unfold() now uses a new children_loaded flag instead of the length of child_ids to decide whether to fetch the children. The flag is set once an article's whole child set is loaded: in loadChildren(), and in loadArticles() for the articles that were unfolded, since those come back with all their children. loadChildren() also rebuilds child_ids from the search result so a favorite already loaded is not added twice. The fix lives in the sidebar component because the partial child_ids only exists on the frontend, get_sidebar_articles already returns the right records. Steps to reproduce: 1. Open the Knowledge app 2. Create an article with two child articles 3. Add one of the two children to your favorites with the star icon 4. Open another article that is not under that parent 5. Fold the parent article in the sidebar, then refresh the page 6. Expand the parent article => only the favorited child is shown under the parent, the other child is missing Ticket [link](https://www.odoo.com/odoo/project.task/6186466) opw-6186466 Forward-Port-Of: odoo/enterprise#118804
Changing a project's visibility now ignores linked shortcut documents, preventing unnecessary access-rights warnings. This makes project settings updates smoother for users who organize project files with document shortcuts.
Original PR description
In 18.0 versions, when there is a shortcut document linked to a project, a warning appears as the access rights of a shortcut document is changed. This fix filters out the shortcut documents beforehand. To reproduce on runbot: 1. Go to a project with documents 2. Go to documents 3. Create shortcut of a document 4. Try to change visibility of project, warning occurs opw-6353516 Forward-Port-Of: odoo/enterprise#123184
This fixes an issue where invoice tax recalculations with Avatax could keep using an outdated pre-tax base amount while updating the tax amount. Invoice lines now consistently use the latest Avatax response, helping avoid incorrect invoice totals after tax recomputation.
Original PR description
Previously, when recomputing taxes via Avatax, `manual_tax_amounts` was cleared and repopulated from the fresh API response, but `manual_total_excluded_currency` was only set if it was None. This meant that after the first Avatax call, the pre-tax base amount was never refreshed from subsequent API responses, even though the tax amounts were. This inconsistency could cause stale pre-tax base amounts to persist on invoice lines across recomputations, even when Avatax returned a different base amount. By resetting `manual_total_excluded_currency` to `None` at the start of each recomputation, mirroring what is already done for `manual_tax_amounts`, we ensure that the pre-tax base is always taken from the current Avatax response rather than a previously cached value. opw-6235597
The Argentine VAT Book export no longer fails for partners marked as foreign providers with a foreign ID. This helps accounting teams generate the required VAT ZIP files without manual corrections or blocked reporting workflows.
Original PR description
Steps to reproduce: - Create a partner with: - State: Ireland - Identification Number: Foreign ID 55000004153 - ARCA Responsibility Type: Proveedor del Exterior - Create an invoice for the partner - Accounting > Reporting > Tax report - Select Report: VAT Book (AR), Tax Type: Sales - Click on gear icon > VAT Book (ZIP) Issue: Action will be blocked with error "No VAT configured for partner [58] <partner>" Analysis: Partners with ARCA responsibility type 'Proveedor del Exterior' (code 8) and a ForeignID identification type, causes a UserError when exporting the VAT Book (ZIP). Code 8 (foreign provider) is the purchase-side counterpart of code 9 (foreign customer), which already fell back to the country-level VAT. Extend the existing fallback branch to cover both codes. opw-6316008 Forward-Port-Of: odoo/enterprise#123506
6 changes
Resolved issues and error corrections
Canadian EFT export files now populate each payment's Item Trace Number with a real payment identifier instead of zeros. This helps ensure payment batches meet CPA-005 requirements and avoids bank rejections caused by invalid trace numbers.
Original PR description
Issue: The Item Trace Number according to CPA-005 standard should be a nonzero sequence that serves as unique reference ID for payments. Currently, Odoo sets the Item Trace Number of all payments as…
Issue: The Item Trace Number according to CPA-005 standard should be a nonzero sequence that serves as unique reference ID for payments. Currently, Odoo sets the Item Trace Number of all payments as a zero-filled sequence According to CPA-005 standards on the Item Trace Number: "The data elements (b), (c) and (d) each must be greater than zero or the TRANSACTION WILL BE REJECTED" (page 36). https://www.payments.ca/sites/default/files/standard005eng.pdf Steps to reproduce: 1. Install the module l10n_ca_payment_cpa005 2. Go into "CA Company" 3. In the configuration for "CA Company", add something to the fields "Short Name used in Canadian EFT" and "Company ID" i.e. "CCC" 4. Set all the fields in the "Canadian EFT/CPA Configuration" section of the bank journal 5. Set the bank record on the bank journal. Set the field "Financial Institution ID Number" field of the "Account Number" record of the bank journal to any numerical sequence 6. Create a bank account on "Azure Interior" and make sure to check the field to trust the bank account that you created (otherwise there will be an error) 7. Create two payments with the vendor of "Azure Interior" using the payment method of "Canadian EFT" 8. Create a batch payment for both payments created 9. Validate the batch payment and the export file should show up in the chatter 10. Note that in the export file, the Item Trace Number for each payment is set to be all zeros, whereas it should be a nonzero identification sequence Solution: Set the Item Trace Number to be the payment's id opw-6323432 Forward-Port-Of: odoo/enterprise#123633
This fix ensures status messages in French reporting exports display with the intended formatting when reports are accepted or rejected. It prevents confusing or unreadable error logs, helping users understand report outcomes more clearly.
Original PR description
A mismatch between error titles and status logs was introduced in 18.0. Markup wasn't added to the status logs, leading to a type mismatch (Markup + str) when displaying errors for 'accepted' or 'rejected' statuses. As a result, the logs were not interpreted as HTML. This commit ensures Markup is applied to each element to guarantee coherence and proper rendering. backport of 5113752 task-6053842 Forward-Port-Of: odoo/enterprise#123250
Fixed an issue where expanding a Knowledge article in the sidebar could show only a favorited child article and hide its other children. Users can now reliably see the complete article structure without needing to refresh or reload.
Original PR description
The sidebar always loads the user's favorite articles along with the visible ones, so a favorited article is shown as a root of the favorite tree. When that favorite is also a child of a folded…
The sidebar always loads the user's favorite articles along with the visible ones, so a favorited article is shown as a root of the favorite tree. When that favorite is also a child of a folded article, it gets added to its parent's child_ids in the main tree, even though the parent's other children were not fetched. A folded article only gets its favorited children back from get_sidebar_articles, not its whole child set. When the parent is then unfolded, unfold() only read the children from the database when child_ids was empty. The favorited child already filled child_ids, so the call was skipped and the remaining children stayed hidden until the next reload. unfold() now uses a new children_loaded flag instead of the length of child_ids to decide whether to fetch the children. The flag is set once an article's whole child set is loaded: in loadChildren(), and in loadArticles() for the articles that were unfolded, since those come back with all their children. loadChildren() also rebuilds child_ids from the search result so a favorite already loaded is not added twice. The fix lives in the sidebar component because the partial child_ids only exists on the frontend, get_sidebar_articles already returns the right records. Steps to reproduce: 1. Open the Knowledge app 2. Create an article with two child articles 3. Add one of the two children to your favorites with the star icon 4. Open another article that is not under that parent 5. Fold the parent article in the sidebar, then refresh the page 6. Expand the parent article => only the favorited child is shown under the parent, the other child is missing Ticket [link](https://www.odoo.com/odoo/project.task/6186466) opw-6186466 Forward-Port-Of: odoo/enterprise#118804
Changing a project's visibility now ignores linked document shortcuts, preventing an unnecessary warning from appearing. This helps users update project access settings smoothly when shortcuts exist in project documents.
Original PR description
In 18.0 versions, when there is a shortcut document linked to a project, a warning appears as the access rights of a shortcut document is changed. This fix filters out the shortcut documents beforehand. To reproduce on runbot: 1. Go to a project with documents 2. Go to documents 3. Create shortcut of a document 4. Try to change visibility of project, warning occurs opw-6353516 Forward-Port-Of: odoo/enterprise#123184
Fixed an issue in Documents where the Actions menu could stop opening after selecting more than one document. Users can now reliably perform bulk actions, while selection counts also stay accurate after uploads.
Original PR description
***Issue:*** Since https://github.com/odoo/enterprise/commit/8baaad621a1555680cd77ab514f626137b5b584d the div holding the selection box and the Actions menu carries t-key="targetRecords.length" in…
***Issue:*** Since https://github.com/odoo/enterprise/commit/8baaad621a1555680cd77ab514f626137b5b584d the div holding the selection box and the Actions menu carries t-key="targetRecords.length" in the documents list and kanban views, so every change of the selection count destroys and recreates everything inside it. Ticking a document checkbox updates both the selection and the focused record, and with these two updates the recreation goes wrong: the new ActionMenus component ends up destroyed while its button is still in the page. The dropdown click listeners are removed with the component, so clicking Actions does nothing until the selection changes again. That t-key was added because the selection box shows a stale count after a file upload. The real problem is that SelectionBox caches this.root once in setup. The upload flow reloads the model, which replaces the root record list, and the box keeps counting the selection of the old one. ***Fix:*** Remove the t-key from documents_list_controller.xml and documents_kanban_controller.xml and make DocumentsSelectionBox read the current props.root instead of the value cached by the parent setup. The count follows the new record list after an upload without remounting anything, and the Actions menu is not recreated so its dropdown keeps working. The upload scenario stays covered by the existing multi_view.test.js test, a new test checks that the Actions menu opens with two selected documents. ***Steps to reproduce:*** 1. Open the Documents app 2. Switch to the list view 3. Tick the checkboxes of two documents 4. Click the Actions button next to the "2 selected" box => the Actions dropdown does not open Ticket [link](https://www.odoo.com/odoo/project.task/6365618) opw-6365618
The Argentine VAT Book ZIP export no longer fails for foreign partners marked as foreign providers with a foreign identification number. This helps accounting teams generate required VAT reports without manual workarounds or blocked exports.
Original PR description
Steps to reproduce: - Create a partner with: - State: Ireland - Identification Number: Foreign ID 55000004153 - ARCA Responsibility Type: Proveedor del Exterior - Create an invoice for the partner - Accounting > Reporting > Tax report - Select Report: VAT Book (AR), Tax Type: Sales - Click on gear icon > VAT Book (ZIP) Issue: Action will be blocked with error "No VAT configured for partner [58] <partner>" Analysis: Partners with ARCA responsibility type 'Proveedor del Exterior' (code 8) and a ForeignID identification type, causes a UserError when exporting the VAT Book (ZIP). Code 8 (foreign provider) is the purchase-side counterpart of code 9 (foreign customer), which already fell back to the country-level VAT. Extend the existing fallback branch to cover both codes. opw-6316008 Forward-Port-Of: odoo/enterprise#123506
7 changes
Resolved issues and error corrections
Financial reports now handle “load more” results correctly when grouped by account and partner. This prevents duplicate Unknown entries, missing partners, and an error when opening the trial balance, helping users trust report results and avoid interruptions.
Original PR description
**Commit 1** [FIX] account_reports: sorting of lines on load more with unknown record Steps to reproduce: - Create a db with demo data - Open the balance sheet's configuration menu. - Set a groupby key of the "Bank and Cash" line to "account_id,partner_id" - Set a load_more limit to 2 for the report - Open the report and unfold the "Bank and Cash line", and load more multiple times. -> The "Unknown" line is displayed several times, while "LightsUp" partner is missing. This is because we removed one record from the sorting if the "load more" line was still necessary. However, it only needs to be the case if no "Unknown" partner is used since this one will always be the last. **Commit 2** [FIX] account_reports: fix load more on trial balance Steps to reproduce: - Set a load more limit on the trial balance and define a grouping key "account_id, partner_id" - Open the report -> Traceback, because the load more line has empty lists in the "columns" key.
Point of Sale receipts will no longer include the extra terminal receipt text from Worldline payments. This keeps customer receipts shorter, clearer, and avoids duplicate or unnecessary payment information.
Original PR description
This PR removes the terminal receipt from Worldline we are currently inserting in the Point Of Sale receipt We don't adapt the driver code to get the receipt as we cannot change C method prototypes task-6373975
Czech VAT control statements now place invoices from partners with non-domestic VAT numbers in section A5 instead of A4. This helps keep tax reports compliant by ensuring A4 is reserved for domestic VAT transactions only.
Original PR description
With l10n_cz company: - Create an invoice for a partner with a foreign vat (EU) with an amount greater than 10000 CZ and a 21% tax. In the vat control statement of the tax report, the move is classified under A4. But the section A4 should only contain move with domestic vat opw-6268506
Canadian check printing now hides check numbers on the attached stubs when pre-numbered checks are used. This keeps the printed check and its stubs consistent and avoids duplicate or confusing numbering on payment documents.
Original PR description
The check itself respected the check_manual_sequencing field, but the stubs did not. Hide the numbers on stubs as well, exactly like on US checks. task-6343701 Forward-Port-Of: odoo/enterprise#122565
The Colombian DIAN invoicing module now correctly hides the Reset to Draft option for credit notes that have already been accepted by DIAN. This helps prevent users from accidentally changing official documents after they have been validated by the tax authority.
Original PR description
Issue: The reset button would still appear for credit notes that were already accepted by the DIAN. Steps to reproduce: Create a credit note, confirm it and send it to DIAN. You will be able to select Reset to Draft even though it shouldn't be possible to convert to draft after accepted by DIAN. Cause: The function to compute if the reset button would appear or not was only taking into account Invoices. Solution: Added credit notes, to the function that verifies if the reset button should appear. opw-6219265
The Trial Balance report no longer breaks when a very low load limit is set. Accounts are now shown immediately instead of being split behind a “Load More” button, making the report more reliable and easier to review.
Original PR description
Steps to reproduce: - Install Accounting module - Accounting > Reporting > Trial Balance > Set `Load More Limit` to `1` - Try to open `Trial Balance` report Traceback: `KeyError: 'column_group_key'` The Trial Balance report was applying the report load more limit when expanding lines grouped by `account_id`. This caused accounts to be loaded in multiple batches and displayed a "Load more" button even though the number of accounts is typically small enough to be loaded at once. Align the behavior with the General Ledger report and with later versions by setting the load-more limit for this grouping to `False`. This ensures that all accounts are displayed immediately when the Trial Balance report is loaded, eliminating the need for a "Load More" button. opw-6255738
The AI website builder now shows the correct preview image for the AI live chat snippet when the related live chat app is not installed. This helps users understand what the snippet will look like before adding or enabling it.
Original PR description
Commit [1] removed the snippet preview since it mismatched the actual result, but it was overlooked that there's another use of this preview. This commit adds an updated image back. [1]: df05441e469157890253b5550b5f8735723b28fb task-6379796
6 changes
Resolved issues and error corrections
Canadian check printing now hides check numbers on the accompanying stubs when businesses use pre-numbered checks. This prevents duplicate or confusing numbering and keeps Canadian checks consistent with the existing U.S. check behavior.
Original PR description
The check itself respected the check_manual_sequencing field, but the stubs did not. Hide the numbers on stubs as well, exactly like on US checks. task-6343701 Forward-Port-Of: odoo/enterprise#122565
This change prevents Chilean companies from selecting more than four business activities for electronic invoicing. It helps avoid tax authority rejections caused by documents that exceed the allowed activity limit.
Original PR description
The Chilean XML schema supports maximum of 4 activities (l10n_cl_company_activity_ids), but we allow to add more than that. If this happens, it causes rejections since electronic documents are being sent with more than 4 options selected, and returning rejection errors. Adding constraint to limit l10n_cl_company_activity_ids task-id: 6329320
The POS now loads only the Kenya fiscal classification records that are actually used by products. This avoids unnecessary data loading, helping reduce startup overhead and improve performance without changing user workflows.
Original PR description
Before `product.unspsc.code` and `l10n_ke_edi_oscu.code` records were loaded without domain, which could lead to loading all records of these models in POS, which is not necessary. This commit adds a domain to the loading of these records, so that only the records that are actually used in the products are loaded in POS.
Signature certificates now show the applicant's actual email address when an offer is generated and signed from Recruitment. This prevents confusing placeholder emails from appearing in certificate logs and improves the reliability of signed recruitment documents.
Original PR description
similar to https://github.com/odoo/enterprise/pull/120566/changes/b5b6589c9c91980e41d025ae74082af63907debc When generating an offer from the recruitment application and signing it, the applicant's…
similar to https://github.com/odoo/enterprise/pull/120566/changes/b5b6589c9c91980e41d025ae74082af63907debc When generating an offer from the recruitment application and signing it, the applicant's email address is incorrectly displayed. ### **Steps to Reproduce:** 1) Install sign, recruitment, hr_contract_salary 2) Create an new application and add basic detail like name and email as (path and path@test.com) 3) Generate offer and sign with all the required signer. 4) Open the application form view and open the certificate. ### **Observed Behavior:** Email is not set correctly in the generated certificate (appearing as john@example.com). ### **Expected Behavior:** The email of the applicant should be correctly set(e.g as path@test.com) ### **Root Cause:** When the applicant signs the document, their email is explicitly set to `False` at [1]. This is done because the applicant is not linked to any user yet. Later, when generating the certificate, the system attempts to display the user's partner email at [2], which is `False`, causing the default fallback value (`john@example.com`) to be printed. [1]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/hr_contract_salary/controllers/main.py#L53-L54 [2]- https://github.com/odoo/enterprise/blob/49226f4109c7d7bb48340949951e70f4245d0e5b/sign/report/sign_log_reports.xml#L59 ### **Fix:** Use `signer_email` instead of the partner's email to ensure the correct email is displayed on the certificate every time. **opw-6280170**
The Argentine VAT Book export no longer fails when invoices involve foreign partners marked as external providers. This helps accounting teams generate required VAT ZIP reports without manual workarounds or blocked reporting flows.
Original PR description
Steps to reproduce: - Create a partner with: - State: Ireland - Identification Number: Foreign ID 55000004153 - ARCA Responsibility Type: Proveedor del Exterior - Create an invoice for the partner - Accounting > Reporting > Tax report - Select Report: VAT Book (AR), Tax Type: Sales - Click on gear icon > VAT Book (ZIP) Issue: Action will be blocked with error "No VAT configured for partner [58] <partner>" Analysis: Partners with ARCA responsibility type 'Proveedor del Exterior' (code 8) and a ForeignID identification type, causes a UserError when exporting the VAT Book (ZIP). Code 8 (foreign provider) is the purchase-side counterpart of code 9 (foreign customer), which already fell back to the country-level VAT. Extend the existing fallback branch to cover both codes. opw-6316008 Forward-Port-Of: odoo/enterprise#123506
Spanish VAT books now correctly show tax amounts for vendor bills that use taxes with negative components, such as certain EU tax setups. This prevents valid tax amounts from incorrectly appearing as zero, improving the accuracy of Spanish VAT reporting.
Original PR description
Problem: In the Spanish VAT books, taxes with negative component (like 21% EU G) always show their amounts as zero. Steps to reproduce: 1. Install the l10n_es_reports module and select the Spanish company 2. Create a vendor bill with a vendor from another EU country and add a product 3. Make sure the tax applied to the product has a negative component (like 21% EU G) 4. Confirm the bill 5. Go to Accounting > Reporting > Tax Return 6. Generate the VAT books from the action menu and check the tax amounts 7. Notice how the tax amount is zero, even though the tax was applied to the bill Cause: When calculating the tax amounts, the negative component cancels out the positive component, leading to the amount always showing as zero in the VAT books. opw-6169766
2 changes
Resolved issues and error corrections
Email buttons for appointments and event registrations now use the website tied to the booking or event, rather than a generic or recently visited website. This prevents customers in multi-website setups from being sent to the wrong site when managing appointments or registrations.
Original PR description
In Multiwebsite settings, when the public user interactions needs email generation (appointment or event flow), the email links are generated with a base url that does not corresponds to the one from…
In Multiwebsite settings, when the public user interactions needs email generation (appointment or event flow), the email links are generated with a base url that does not corresponds to the one from which the request started. Case 1: - Have website A and website B - Create an appointment page website A - Log in via website B - As public user, make an appointment in Website A - Check the generated email Issue: button links in the email will redirect to the wrong website, so users will encounter an issue when managing the appointment. This occurs because when an user log in, the system parameter 'web.base_url' is updated with the current url. This parameter is then used as fallback when we need to retrieve the base url without an active record Case 2: - Have website A and website B - Create an event and assign it to website B - As public user, access the event and register to it - Check the generated email Issue: button links in the email will redirect to the wrong website, so users will encounter an issue when managing the event. This occurs because the record `event.registration` has no website_id field and the base url is taken from the company default website (website A) Backport with improvements of 15bae202d8f1b5bf70bbc63b2d89025e9237e6cf opw-4146760 opw-4336369
The Knowledge card on the customer portal now uses the same layout as the other portal cards. This fixes a visual inconsistency where it appeared slightly wider, improving the page’s polish and consistency for users.
Original PR description
The knowledge portal card was injected directly into "o_portal_docs", causing it to render wider than other cards. This happened because other cards sit inside "o_portal_category" (row g-2 mt-3) divs, while, knowledge was a direct child of o_portal_docs, giving it a different grid context despite both using col-md-6. To fix the issue, we wrapped the portal_docs_entry in an "o_portal_category row g-2 mt-3" div to match the structure of all other portal cards. Steps to reproduce: 1. Go to the website. 2. Click on name drop down menu on the navbar like "Mitchell Admin" 3. Click on "My Accont" from the drop down menu 4. Once the page loads properly, you can see the knowledge card width is a little bit larger than other cards. opw-6251483