Tuesday, August 12, 2025
59 changes
15 changes
Resolved issues and error corrections
This update adds automated checks to protect a previous fix in the website editor. It helps ensure drag-and-drop editing does not incorrectly mark unrelated page elements as changed, reducing the risk of accidental save issues in future updates.
Original PR description
As a follow-up of commit [1] (then modified by [2]), which prevented the drag and drop to mark unwanted elements as dirty, this commit adds tests to make sure the fix is okay and to secure this behavior so nothing else can break it. [1]: 6fdf188fdf5cfdc11e5e1a8429d0a652054344de [2]: 42f14bf17042d6b53858e362eea7f06aacf49702 task-4367641
This fixes an issue where certain website elements, such as the shopping cart icon in the header, lost their media editing controls while editing a page. Users can now replace those media elements without accidentally making the icon text-editable.
Original PR description
Following this [commit], in some cases we need to have .o_editable_media class while the element is not editable itself. In order to do this, we shouldn't filter out elements again based on `force_not_editable_selector`s, but rather just not set element's contenteditable to true, when the element matches those selectors, then the .o_editable_media will be added successfully. To see the issue: - open website and start editing - inspect the cart icon in the header => It's missing the .o_editable_media class. Related to task-4367641 [commit]: https://github.com/odoo/odoo/commit/b455ea85853df
Website popup tests now wait for the actual show and hide events instead of relying on animation timing. This reduces false test failures and helps keep website changes safer to release.
Original PR description
The tests for showing and hiding popups were prone to failure as they relied on timing for the animation to complete. With this commit, we properly wait for the bootstrap event that is triggered when the popup is shown/hidden before continuing with the test task-4367641
Invoice PDFs sent by email now use the same customized file name as invoices printed manually. This avoids confusion for customers and keeps emailed documents consistent with the company’s report settings.
Original PR description
**Steps to reproduce**: - install the `accounting` module. - Go to `Settings -> Technical -> Actions -> Reports -> Invoice or Invoice without payment` - Change the printed report name - Try to print…
**Steps to reproduce**:
- install the `accounting` module.
- Go to `Settings -> Technical -> Actions -> Reports -> Invoice or Invoice without payment`
- Change the printed report name
- Try to print the report via the print menu (gear icon -> print) -> The report is shown with the new updated name.
- Try sending the invoice the regular way -> the attached invoice has the default name, Odoo ignores the changes.
**Observation**:
When printing the invoice manually, the file name correctly reflects the custom name configured in the report action. However, when sending the invoice by email, the attachment file name does not match the updated name and remains hardcoded.
**Issue**:
The email attachment file name is hardcoded in the mail sending logic. in the method:
```python
def _get_invoice_report_filename(self, extension='pdf'):
self.ensure_one()
return f'{self.name.replace('/', '_')}.{extension}'
```
It does not dynamically fetch the updated report name from the configured report action.
**Solution**:
When a custom report template is configured on the customer on field `(invoice_template_pdf_report_id)`, the system now dynamically uses the corresponding name from the report action for the email attachment.
opw-4923035
Forward-Port-Of: odoo/odoo#219279Quotation PDFs now correctly show zero values for custom number fields instead of leaving those fields blank. This prevents confusion for customers and sales teams when a quoted value is intentionally set to zero.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Using Studio, add an integer or float field to the sale order form; 2. upload a PDF using forms as a quotation header[^1]; 3. add a mapping of the form field to the studio field; 4. create a quoation using the header; 5. have the studio field be 0; 6. print quotation. [^1]: e.g. `tests/files/test_forms.pdf` Issue ----- The form field where the zero should be displayed is empty. Cause ----- When formatting values, it returns an empty string for any falsy value whose field isn't of type boolean or monetary. Solution -------- If the value is falsy, only return the empty string if the field type is not integer or float, this way, the zero value will get formatted in the final `else` as a string value (same as non-zero numeric values). opw-4937052 Forward-Port-Of: odoo/odoo#222487
This update corrects dependency declarations for the website and HTML builder areas so related features load with the components they need. It helps prevent setup or runtime issues in the website editing experience caused by missing or incorrect module dependencies.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Manufacturing unbuild operations now respect the decimal precision configured for the product's unit of measure. This prevents quantities with more than two decimals from being rounded or blocked, improving accuracy for products measured with finer precision.
Original PR description
Steps to reproduce the bug:
- Set the decimal precision and rounding accuracy for the unit of measure to more than 2 digits (e.g. 3)
- Create a storable product “P1”
- Create a manufacturing order to produce 1.234 units
- Confirm and validate it
- Try to unbuild the MO
Problem:
The unbuild form does not respect the product's UoM decimal precision, allowing only 2 digits for product_qty.
opw-4818591
Forward-Port-Of: odoo/odoo#220308
Forward-Port-Of: odoo/odoo#211944This fix ensures live chat visitors see the correct sender name in mail and chat messages. It prevents blank or missing names by using the live chat-friendly display name consistently.
Original PR description
Before this commit, using author.name directly could lead to not showing anything to livechat visitors. This is because the information is not send to the visitor. By using the authorName getter, we leverable the override in livechat and correctly use the livechat_username. task-4965911 Forward-Port-Of: odoo/odoo#221761 Forward-Port-Of: odoo/odoo#220104
This fixes a website editor issue where changing an image's position in a parallax cover section could distort the image size and placement. Business users editing website pages should now get predictable visual results when adjusting image positioning with scroll effects enabled.
Original PR description
Following the [html_builder refactoring], we had the issue with image's background overlay when we were changing its background position, which happened because the parallax interaction would change image's dimensions. To reproduce the issue: - open website, start editing - drop the `s_cover parallax` snippet and click on it - change its Scroll Effect option to "Zoom In" - Click on the Image Position option's crosshair => Observe that the image's dimensions and position are messed up. [html_builder refactoring]: https://github.com/odoo/odoo/commit/9fe45e2b7ddb
Creating or editing a milestone from the All Tasks screen now automatically keeps the related project information. This prevents an unnecessary required-field error and lets users save milestones without extra manual steps.
Original PR description
### Steps to Reproduce: - Install sale project - Go to All Tasks - Open any task create and edit a new milestone and click on save ### Issue: - A required field error is raised because `project_id` is not set by default. - It should not be the case. ### Cause: - The `milestone_id` field's attributes are overridden in `sale_project`. - The context is missing `default_project_id` when accessing the milestone from the "All Tasks" view. ### Fix: - Passed project_id as default_project_id when opening milestone form. task-4953620 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220735
A flaky automated test in the barcode stock transfer flow was stabilized by waiting for the destination location update to appear on screen before continuing. This reduces random test failures and helps keep stock barcode releases more reliable without changing user-facing behavior.
Original PR description
A non-deterministic error has been occurring across all versions starting from 18.0 when running the `test_split_line_on_destination_scan`. problem: The issue lies in one of the steps of the tour,…
A non-deterministic error has been occurring across all versions starting from 18.0 when running the
`test_split_line_on_destination_scan`.
problem:
The issue lies in one of the steps of the tour, where the destination location of the remaining quantity is changed from WH/Stock to shelf1 (LOC-01-01-00). Right after this change, the test proceeds to assertLineDestinationLocation. However, the test step was previously waiting for the presence of the .o_validate_page.btn-primary element — an element that is already visible before the destination location update is actually applied. As a result, the tour sometimes skips to the next step prematurely, without ensuring the location change has occurred, leading to test failure.
Fix:
We replaced the trigger .o_validate_page.btn-primary with a more reliable condition: waiting for an element containing the destination text .../Section 1 (.o_line_destination_location:contains(".../Section 1")). This ensures that the step only proceeds once the destination update has been reflected in the UI.
Runbot-145458
Forward-Port-Of: odoo/enterprise#92006
Forward-Port-Of: odoo/enterprise#91927The Approvals app now handles cases where the same person appears more than once as an approver on a request. This prevents a traceback when users open My Requests and keeps approval workflows accessible.
Original PR description
#### Reproduce Approvals app -> My Approvals -> My Requests (Traceback Error) #### Issue The demo data contains a duplicate record for an approver (the user is set as default approver for the approval category and added again as record in xml data), so the request had 2 approvers with the same user. #### Fix Get the first record of filtered approvers for current user if there are many. task-4984137
The Spanish VAT record book export now recognizes the 0.26% and 1% equivalence surcharge purchase taxes. This prevents an error when exporting VAT books for invoices using these rates, helping Spanish companies complete tax reporting reliably.
Original PR description
Added to SURCHARGE_TAX_EQUIVALENT taxes 0.26% SE and 1% SE When using the Odoo VAT book (location Spain) and we have an invoice with the taxes 0.26% SE (0,26% Recargo Equivalencia Compras) 1% SE (1%…
Added to SURCHARGE_TAX_EQUIVALENT taxes 0.26% SE and 1% SE When using the Odoo VAT book (location Spain) and we have an invoice with the taxes 0.26% SE (0,26% Recargo Equivalencia Compras) 1% SE (1% Recargo Equivalencia Compras). a KeyError error occurs <img width="1147" height="517" alt="Captura desde 2025-07-30 09-37-13" src="https://github.com/user-attachments/assets/771fcf6e-efed-4e79-a1d4-a133c7072c2a" /> Steps to Reproduce this error: 1. Create a new database using Odoo version 18. 2. Activate the module: “Spain - Accounting (PGCE 2008)” (l10n_es). 3. Create a new company and set Spain as the country. 4. In the company’s “Sales & Purchase” tab, set the Fiscal Position to "Equivalence surcharge". 5. Create a new quotation and select the company created in step 3. 6. Add a product with the following taxes: 0.26% and 2% VAT (G). 7. Add another product with the following taxes: 1% (SE) and 7.5% VAT (G). 8. Confirm the invoice generated from the quotation. 9. Go to Accounting → Reporting → Tax Report and select "Generic Tax Report". 10. Click the gear icon and select "VAT Record Books (XLSX)". OPW https://www.odoo.com/es_ES/my/tasks/4981807 @jco-odoo please review. Thank you! MT-10457 @moduon Forward-Port-Of: odoo/enterprise#92116
The US Payroll leave type setup screen now includes the intended fields and uses the correct label. This helps payroll administrators see and configure the required leave information without missing options.
Original PR description
Before this commit, the modification of the leave type views was not introduced in the manifest, resulting in the fields being absent from the view. This commit corrects the label as well as introduces that view in the manifest Forward-Port-Of: odoo/enterprise#87423
Automatic currency rate updates from the UAE Central Bank now include the Sudanese Pound. This ensures businesses using SDG receive current exchange rates without manual correction.
Original PR description
**Steps to reproduce**: 1. Install the `account` and `l10n_ae` modules. 2. Go to `Invoicing → Configuration → Currencies` and activate the `Sudanese Pound (SDG)` currency. 3. Navigate to `Settings → Invoicing → Currencies → Automatic Currency Rates`. 4. Select `[AE] Central Bank of the UAE` as the currency provider and manually fetch rates. <img width="463" height="181" alt="image" src="https://github.com/user-attachments/assets/31257e2e-8360-4cdb-877e-2ea41487ddea" /> 5. Return to the Currencies list. **Observed behavior**: - The rate for the `Sudanese Pound (SDG)` is not updated. **Root cause**: - The `SDG` currency is missing from the `MAP_CURRENCIES` dictionary, so the provider doesn't fetch its rate. **Solution**: - Add the missing `SDG` currency mapping to `MAP_CURRENCIES`. opw-4869204 Forward-Port-Of: odoo/enterprise#91790
16 changes
Resolved issues and error corrections
This fixes an issue where portal users could receive incorrect read access information for document messages, especially when opening documents through shared links. The change ensures the interface receives accurate access details, helping avoid misleading options or behavior in the chatter area.
Original PR description
Before this commit, the `_thread_to_store` method would always set the `hasReadAccess` property to true. This was fine because the only flow that would add the values to the store would already check the existance and access to the thread. However after change [1] the access values would be sent in more flows, one of which being portal chatter initialization. This causes the client to have incorrect access information to the thread (i.e. hasReadAccess would be true even when accessing portal document through token). This commit fixes the issue by sending the correct access values. [1] https://github.com/odoo/odoo/pull/220774 Forward-Port-Of: odoo/odoo#222545 Forward-Port-Of: odoo/odoo#222281
12 changes
Resolved issues and error corrections
Rental quotation product selection now avoids showing products that are neither available for sale nor rentable. This prevents sales teams from accidentally adding unavailable products to customer quotations, improving quote accuracy.
Original PR description
Versions
--------
- saas-18.3
Steps
-----
1. Have a product that's neither salable not rentable;
2. open a quotation;
3. click "Add a product".
Issue
-----
It's possible to select the unsalable product.
Cause
-----
Commit d5f72c201bf0 added a `_domain_product_id` override to `sale_renting` which includes `('rent_ok', '=', order_is_rental)`. As a consequence, whenever you have a quotation that isn't a rental, this domain will retrieve *any* product that isn't rental either.
Solution
--------
Add a `('rent_ok', '=', True)` condition to ensure the override only affects rental orders, and that non-rental orders won't retrieve all non-rental products.
opw-4983348
Forward-Port-Of: odoo/enterprise#9170116 changes
Resolved issues and error corrections
Odoo now shows a clear user-facing error when a document numbering prefix or suffix contains an invalid placeholder. This prevents confusing system errors when creating records such as sales orders and helps users correct the sequence setup more easily.
Original PR description
Currently, an error is raised when a sequence is generated with an invalid legend in the prefix or suffix. **Steps to reproduce:** - Install Sales module. - Update the sale order sequence prefix to S%(days)s. - Create a new sale order. **Error:** `KeyError - 'days'` **Cause:** An error occurs when the user provides an invalid suffix in `ir_sequence` and the system tries to generate that sequence at [1]. [1] - https://github.com/odoo/odoo/blob/18da9b6dfc9dc376700cd948a09ae201bf897990/odoo/addons/base/models/ir_sequence.py#L235-L236 **Fix:** To resolve the issue, raise a user error for an invalid sequence. **Ref:** https://github.com/odoo/odoo/commit/18cac1caa21149d70009aa50f3e90dfbc18456a3 Sentry - 6684586181 Forward-Port-Of: odoo/odoo#217142
Incoming return slips now show the actual destination address instead of placeholder demo text. This helps warehouse and operations teams avoid confusion when printing return documents for received products.
Original PR description
Issue ----- Incoming return slips have a "Demo Address and Name" text instead of the correct destination address. <img width="928" height="658" alt="image"…
Issue ----- Incoming return slips have a "Demo Address and Name" text instead of the correct destination address. <img width="928" height="658" alt="image" src="https://github.com/user-attachments/assets/6ff0a5e7-f1ee-4faa-a22b-76ec8f2f7a28" /> Steps to reproduce ----- - Create a receipt for a product - Print its return slip Cause ----- By default, the address is taken from the pickings location_id -> warehouse_id -> partner_id. For incoming pickings, the warehouse is the vendor one, with no associated partner. In such cases, the partner can be found directly on the picking itself with the partner_id field. Note ----- To render t-fields, qweb first applies a `rsplit` before evaluating the expression, see https://github.com/odoo/odoo/blob/cb1c761777e84d96f82c4f754586795509ce1b3d/odoo/addons/base/models/ir_qweb.py#L2015-L2016 With this in mind, using parentheses and moving `.partner_id` outside of them seems like the most readable way to go about it. ----- Ticket: opw-4660716 Forward-Port-Of: odoo/odoo#221807 Forward-Port-Of: odoo/odoo#219011
The mobile shop toolbar now stays visible above the live chat bubble, preventing overlap when no pricelist is configured. This makes the mobile shopping experience clearer and avoids customers missing key purchase controls.
Original PR description
In odoo/odoo@860dccec53cb0940212fe7d9161c7e3c805867f7 the floating toolbar layout was introduced, but there was an issue with the livechat bubble which was overlapping the floating bar on mobile when there was no priceslit (error with the calc()). This PR fixes this issue by displaying the floatingbar above the livechat bubble, taking the same style when there is a pricelist or not. task-4966406 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Quotation PDFs now correctly show zero values from custom integer or decimal fields instead of leaving those fields blank. This ensures generated sales quotes accurately reflect entered data and avoids confusion for customers and sales teams.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Using Studio, add an integer or float field to the sale order form; 2. upload a PDF using forms as a quotation header[^1]; 3. add a mapping of the form field to the studio field; 4. create a quoation using the header; 5. have the studio field be 0; 6. print quotation. [^1]: e.g. `tests/files/test_forms.pdf` Issue ----- The form field where the zero should be displayed is empty. Cause ----- When formatting values, it returns an empty string for any falsy value whose field isn't of type boolean or monetary. Solution -------- If the value is falsy, only return the empty string if the field type is not integer or float, this way, the zero value will get formatted in the final `else` as a string value (same as non-zero numeric values). opw-4937052 Forward-Port-Of: odoo/odoo#222487
Employees on flexible working schedules will no longer have public holidays deducted from their leave balance when requesting leave on those days. This keeps leave balances accurate and avoids charging employees for company holidays.
Original PR description
**Steps to reproduce:** 1) Create a flexible working schedule. 2) Assign this schedule to an employee. 3) Create a public holiday. 4) Create a leave request for the flexible employee on the public…
**Steps to reproduce:** 1) Create a flexible working schedule. 2) Assign this schedule to an employee. 3) Create a public holiday. 4) Create a leave request for the flexible employee on the public holiday. 5) Notice that the duration of the leave is 1 instead of 0. **Issue:** Due to recent changes in the [commit](https://github.com/odoo/odoo/commit/a826f65c2d95b796f919023d560ec9f0801090d8#diff-38469def2f870bb866f971f57797dd7c21b6a95d52a8eae72f832f0eea2434f9R427-R433) , When a single-day flexible leave is taken, the duration is always set to the real duration. However, we do not check if the leave falls on a public holiday, which results in the leave being set to 1 day, even on holidays. https://github.com/odoo/odoo/blob/8f24da78f60529ea0b1840e48de30e15d17ddb77/addons/hr_holidays/models/hr_leave.py#L427-L433 **For example:** If Christmas is marked as a public holiday and an employee with a flexible schedule requests a one-day leave on Christmas, the leave is recorded with a duration of 1 day. **Fix:** Check for a public holiday on leave date; if yes, set leave duration to 0. opw-4963122 Forward-Port-Of: odoo/odoo#220288
Steps to reproduce: 1. Install 'l10n_it' and 'accounting' from apps. 2. Enable debug mode. 3. Activate the Italian language and set it for the current user. 4. Go to Accounting > Customers / Vendors > Invoice / Bill > Electronic Invoicing tab Observation: When the Italian language is active, the 'Electronic Invoicing' tab and the fields within it are not translated. Issue: Missing translations in the PO file. Solution: Added the missing translations for the fields in the PO file.
Original PR description
Steps to reproduce: 1. Install 'l10n_it' and 'accounting' from apps. 2. Enable debug mode. 3. Activate the Italian language and set it for the current user. 4. Go to Accounting > Customers / Vendors > Invoice / Bill > Electronic Invoicing tab Observation: When the Italian language is active, the 'Electronic Invoicing' tab and the fields within it are not translated. Issue: Missing translations in the PO file. Solution: Added the missing translations for the fields in the PO file. opw-4937464
This fix ensures calendar records use valid default references when opening or creating related items. It prevents edge cases where an invalid zero identifier could cause incorrect behavior in calendar workflows.
Original PR description
Use valid res_model/res_id in context defaults runbot-235289 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222426
The help text for choosing a project documents folder has been corrected to match current behavior. This avoids telling users that task documents are automatically moved into that folder, reducing confusion for teams organizing documents manually.
Original PR description
Before this commit, the tooltip displayed for `documents_folder_id` defined in `project.project` model, said all documents linked to a task of a project will be automatically added inside that folder but it is no longer the case since the refactoring of Documents to simplify the implementation but also let the documents user sorts his documents as he wants since now the access rights are defined by folder. This commit updates the tooltip accordingly. PR simplifying the bridge between documents and project apps: #75214 opw-5000224 Forward-Port-Of: odoo/enterprise#92164
This update adjusts accounting report tests so they align with stricter validation rules for external report calculations. It helps prevent false test failures for complex tax reports, such as Luxembourg tax annexes, without changing day-to-day user workflows.
Original PR description
The corresponding community PR (https://github.com/odoo/odoo/pull/221407) contains a fix that requires the _validate_engine constraint to reject any groupby value for the 'external' engine. Therefore, it is now needed that the test ensuring non-stored related fields can be used in groupby is adapted in order to also exclude those expressions when changing the groupby value of the lines using a custom engine on any of their expressions. Without that, complex reports like the annexes of the Luxembourgese tax report fail the test. Forward-Port-Of: odoo/enterprise#92096
The Swedish SIE4 import now handles files that do not include previous-year information without crashing. This lets accounting users import opening balances more reliably, including files that require an alternate text encoding.
Original PR description
**Issue**: Importing a SIE4 file without previous year information causes a traceback. **Steps to reproduce**: - Go to Accounting > Settings > Import - Import SIE 4 file - Check the box "Import account opening balances" - Select the right xml and observe the traceback **Cause**: The method `_prepare_sie4_opening_balance_move` tries to directly access the previous year: https://github.com/odoo-dev/enterprise/blob/6d4919658650a006c73d4aaf1f500d67723dda0d/l10n_se_sie4_import/wizard/import_wizard.py#L376C9-L376C58 This results in a traceback when the previous year is not present. **Solution**: Make `_prepare_sie4_opening_balance_move` more permissive by falling back to the day before the first day of the current year if the `-1` section is not there. **Additional Notes**: The client file does not support `UTF8` format, retry with the `ISO-8859-1` format in case of `UnicodeDecodeError`. opw-4894495 Forward-Port-Of: odoo/enterprise#89425
Field service teams can once again open outgoing stock transfers in a map view. This restores an Enterprise-only view option that was temporarily unavailable after a related community fix.
Original PR description
This commit is the continuity of the fix made in community. The issue fixed in community was the map view cannot be defined in the view mode of an action since the map view only exists in enterprise. This commit overrides the method defined in community to add the map view as before. Related PR: odoo/odoo#222003 Forward-Port-Of: odoo/enterprise#92032
The US payroll leave type setup screen now includes the missing view update, so the intended fields appear for users. A label was also corrected, reducing confusion when configuring leave types.
Original PR description
Before this commit, the modification of the leave type views was not introduced in the manifest, resulting in the fields being absent from the view. This commit corrects the label as well as introduces that view in the manifest Forward-Port-Of: odoo/enterprise#87423
This fix ensures stock barcode tests include an email address for the user involved in quantity update notifications. It helps confirm that notifications can be sent correctly when initial demand on stock moves changes, avoiding failures caused by missing user email data.
Original PR description
Updating the initial demand of a stock move notify the users. Without email address, the notification cannot be send. As the email address of the admin user is only fill in the demo data, this commit adds one specially for the test. runbot: 226778 Forward-Port-Of: odoo/enterprise#89722
The Spanish VAT book export now recognizes the 0.26% and 1% equivalence surcharge purchase taxes. This prevents an error when exporting VAT Record Books for invoices using these tax rates, allowing affected Spanish accounting users to generate reports normally.
Original PR description
Added to SURCHARGE_TAX_EQUIVALENT taxes 0.26% SE and 1% SE When using the Odoo VAT book (location Spain) and we have an invoice with the taxes 0.26% SE (0,26% Recargo Equivalencia Compras) 1% SE (1%…
Added to SURCHARGE_TAX_EQUIVALENT taxes 0.26% SE and 1% SE When using the Odoo VAT book (location Spain) and we have an invoice with the taxes 0.26% SE (0,26% Recargo Equivalencia Compras) 1% SE (1% Recargo Equivalencia Compras). a KeyError error occurs <img width="1147" height="517" alt="Captura desde 2025-07-30 09-37-13" src="https://github.com/user-attachments/assets/771fcf6e-efed-4e79-a1d4-a133c7072c2a" /> Steps to Reproduce this error: 1. Create a new database using Odoo version 18. 2. Activate the module: “Spain - Accounting (PGCE 2008)” (l10n_es). 3. Create a new company and set Spain as the country. 4. In the company’s “Sales & Purchase” tab, set the Fiscal Position to "Equivalence surcharge". 5. Create a new quotation and select the company created in step 3. 6. Add a product with the following taxes: 0.26% and 2% VAT (G). 7. Add another product with the following taxes: 1% (SE) and 7.5% VAT (G). 8. Confirm the invoice generated from the quotation. 9. Go to Accounting → Reporting → Tax Report and select "Generic Tax Report". 10. Click the gear icon and select "VAT Record Books (XLSX)". OPW https://www.odoo.com/es_ES/my/tasks/4981807 @jco-odoo please review. Thank you! MT-10457 @moduon Forward-Port-Of: odoo/enterprise#92116
This change fixes an intermittent failure in an automated barcode inventory test by making the test wait for the destination location update to appear before continuing. It improves release stability and reduces false failures in quality checks without changing business functionality.
Original PR description
A non-deterministic error has been occurring across all versions starting from 18.0 when running the `test_split_line_on_destination_scan`. problem: The issue lies in one of the steps of the tour,…
A non-deterministic error has been occurring across all versions starting from 18.0 when running the
`test_split_line_on_destination_scan`.
problem:
The issue lies in one of the steps of the tour, where the destination location of the remaining quantity is changed from WH/Stock to shelf1 (LOC-01-01-00). Right after this change, the test proceeds to assertLineDestinationLocation. However, the test step was previously waiting for the presence of the .o_validate_page.btn-primary element — an element that is already visible before the destination location update is actually applied. As a result, the tour sometimes skips to the next step prematurely, without ensuring the location change has occurred, leading to test failure.
Fix:
We replaced the trigger .o_validate_page.btn-primary with a more reliable condition: waiting for an element containing the destination text .../Section 1 (.o_line_destination_location:contains(".../Section 1")). This ensures that the step only proceeds once the destination update has been reflected in the UI.
Runbot-145458
Forward-Port-Of: odoo/enterprise#92006
Forward-Port-Of: odoo/enterprise#91927Automatic currency rate updates from the UAE Central Bank now include the Sudanese Pound. This ensures businesses using SDG can receive updated exchange rates without manual corrections.
Original PR description
**Steps to reproduce**: 1. Install the `account` and `l10n_ae` modules. 2. Go to `Invoicing → Configuration → Currencies` and activate the `Sudanese Pound (SDG)` currency. 3. Navigate to `Settings → Invoicing → Currencies → Automatic Currency Rates`. 4. Select `[AE] Central Bank of the UAE` as the currency provider and manually fetch rates. <img width="463" height="181" alt="image" src="https://github.com/user-attachments/assets/31257e2e-8360-4cdb-877e-2ea41487ddea" /> 5. Return to the Currencies list. **Observed behavior**: - The rate for the `Sudanese Pound (SDG)` is not updated. **Root cause**: - The `SDG` currency is missing from the `MAP_CURRENCIES` dictionary, so the provider doesn't fetch its rate. **Solution**: - Add the missing `SDG` currency mapping to `MAP_CURRENCIES`. opw-4869204 Forward-Port-Of: odoo/enterprise#91790
Automatic currency rate updates from the UAE Central Bank now include the Sudanese Pound. This ensures businesses using SDG receive current exchange rates without manual correction.
Original PR description
**Steps to reproduce**: 1. Install the `account` and `l10n_ae` modules. 2. Go to `Invoicing → Configuration → Currencies` and activate the `Sudanese Pound (SDG)` currency. 3. Navigate to `Settings → Invoicing → Currencies → Automatic Currency Rates`. 4. Select `[AE] Central Bank of the UAE` as the currency provider and manually fetch rates. <img width="463" height="181" alt="image" src="https://github.com/user-attachments/assets/31257e2e-8360-4cdb-877e-2ea41487ddea" /> 5. Return to the Currencies list. **Observed behavior**: - The rate for the `Sudanese Pound (SDG)` is not updated. **Root cause**: - The `SDG` currency is missing from the `MAP_CURRENCIES` dictionary, so the provider doesn't fetch its rate. **Solution**: - Add the missing `SDG` currency mapping to `MAP_CURRENCIES`. opw-4869204 Forward-Port-Of: odoo/enterprise#91790
Worksheet fields created during onboarding are now properly included in translation exports. This helps field service and quality teams use localized worksheet labels reliably across languages and updates.
Original PR description
_*=industry_fsm_report, quality_control_worksheet Issue: - In the `industry_fsm_report` and `quality_control_worksheet` modules, worksheet fields created during onboarding were not translatable and were missing from the exported .po files. Cause: - Field creation was moved from XML to Python (see https://github.com/odoo/enterprise/commit/d619aa4d0d042be3f899b777081b7fb90f851c84). As a result, the fields were no longer automatically registered in `ir.model.data`, preventing the translation system from detecting them. Solution: - Set the `_import_current_module` context and added explicit IDs when creating fields in python. This registers the fields in `ir.model.data`, enabling translations and keeping field references stable across updates. task-4585020
The Spanish VAT record book export now recognizes the 0.26% and 1% equivalence surcharge purchase taxes. This prevents an error when exporting VAT books for invoices using these rates, helping Spanish companies complete tax reporting reliably.
Original PR description
Added to SURCHARGE_TAX_EQUIVALENT taxes 0.26% SE and 1% SE When using the Odoo VAT book (location Spain) and we have an invoice with the taxes 0.26% SE (0,26% Recargo Equivalencia Compras) 1% SE (1%…
Added to SURCHARGE_TAX_EQUIVALENT taxes 0.26% SE and 1% SE When using the Odoo VAT book (location Spain) and we have an invoice with the taxes 0.26% SE (0,26% Recargo Equivalencia Compras) 1% SE (1% Recargo Equivalencia Compras). a KeyError error occurs <img width="1147" height="517" alt="Captura desde 2025-07-30 09-37-13" src="https://github.com/user-attachments/assets/771fcf6e-efed-4e79-a1d4-a133c7072c2a" /> Steps to Reproduce this error: 1. Create a new database using Odoo version 18. 2. Activate the module: “Spain - Accounting (PGCE 2008)” (l10n_es). 3. Create a new company and set Spain as the country. 4. In the company’s “Sales & Purchase” tab, set the Fiscal Position to "Equivalence surcharge". 5. Create a new quotation and select the company created in step 3. 6. Add a product with the following taxes: 0.26% and 2% VAT (G). 7. Add another product with the following taxes: 1% (SE) and 7.5% VAT (G). 8. Confirm the invoice generated from the quotation. 9. Go to Accounting → Reporting → Tax Report and select "Generic Tax Report". 10. Click the gear icon and select "VAT Record Books (XLSX)". OPW https://www.odoo.com/es_ES/my/tasks/4981807 @jco-odoo please review. Thank you! MT-10457 @moduon Forward-Port-Of: odoo/enterprise#92116
This fix ensures the U.S. payroll leave type screen includes the expected fields by loading the missing view configuration. It also corrects a label so users see clearer information when managing leave types.
Original PR description
Before this commit, the modification of the leave type views was not introduced in the manifest, resulting in the fields being absent from the view. This commit corrects the label as well as introduces that view in the manifest Forward-Port-Of: odoo/enterprise#87423
The VoIP softphone now checks whether the user is typing in another editable field before taking focus back after a call. This prevents interruptions and reduces the chance of accidentally entering text in the wrong place.
Original PR description
Before switching the focus back to the softphone after a call, make sure the user isn't typing somewhere else. Only autofocus if the focus is not on an editable element. Task-4997513. Forward-Port-Of: odoo/enterprise#91970 Forward-Port-Of: odoo/enterprise#89562
The salary configurator now displays dropdowns and the personal information section more consistently across screen sizes. This makes the form easier to read and use for employees configuring their salary package.
Original PR description
this commit fixes dropdown styling in the salary configurator. moreover, `your personal information` section is fixed so that the background color covers the entire width of the screen in different screen sizes. task-4953595
Approval requests now prevent the same person from being added more than once as an approver. This avoids traceback errors in the Approvals app and removes duplicate demo data that could trigger the issue.
Original PR description
#### Reproduce Approvals app -> My Approvals -> My Requests (Traceback Error) #### Issue The demo data contains a duplicate record for an approver (the user is set as default approver for the approval category and added again as record in xml data), so the request had 2 approvers with the same user. #### Fix replaced the `@api.constrains` with a UNIQUE SQL constraint to enforce the check of same user linked to more than one approver for single request, and deleted duplicate record from demo xml data. task-4984137
Exported audit reports will now include the .pdf file extension in their names. This helps Windows recognize the files as PDFs so users can open them directly with their PDF viewer without manual renaming.
Original PR description
Currently, when a user exports an audit report, the server returns a download URL. During the download, the server sets the `Content-Type` HTTP header to `application/pdf`, indicating that the file is a PDF. However, for Windows users, setting the `Content-Type` header alone is not enough. The operating system may treat the file as a generic file, which means it won't automatically open in a PDF viewer when double-clicked. Instead, the user must manually assign the `.pdf` extension or choose a PDF reader to open it. To resolve this, we will include the `.pdf` extension in the file name. This ensures that the operating system correctly identifies the file as a PDF and opens it with the appropriate application. Task-4989809
Field service teams can once again use the map view when opening outgoing stock deliveries. This restores a helpful visual planning option that was temporarily missing due to a technical split between Odoo Community and Enterprise features.
Original PR description
This commit is the continuity of the fix made in community. The issue fixed in community was the map view cannot be defined in the view mode of an action since the map view only exists in enterprise. This commit overrides the method defined in community to add the map view as before. Related PR: odoo/odoo#222003 Forward-Port-Of: odoo/enterprise#92032
Adjusted accounting report tests so they respect new validation rules for externally calculated report lines. This prevents false test failures in complex tax reports, such as Luxembourg tax annexes, while keeping report behavior aligned with stricter safeguards.
Original PR description
The corresponding community PR (https://github.com/odoo/odoo/pull/221407) contains a fix that requires the _validate_engine constraint to reject any groupby value for the 'external' engine. Therefore, it is now needed that the test ensuring non-stored related fields can be used in groupby is adapted in order to also exclude those expressions when changing the groupby value of the lines using a custom engine on any of their expressions. Without that, complex reports like the annexes of the Luxembourgese tax report fail the test. Forward-Port-Of: odoo/enterprise#92096
This update adds the required AI VoIP dependency to the enterprise discussion test module. It prevents test failures when transcription-related VoIP settings are expected but the supporting module is not available.
Original PR description
After (ref.1) test suite includes `voip.provider.transcription_policy` in its expected values in the store (ref.2).
Since `transcription_policy`` is coming from ai_voip module, and there is no direct dependency, it can cause issues when ai_voip isn't there.
This commit prevents that situation by introducing the dependency.
Refs:
---
(1) [IMP] ai_voip: introduce per-provider transcription setting
df402bcdd9023157ee3661e453002bacb421384c
(2) mail.tools.discuss.Store (voipConfig wiring)
related task
task-4532108This fixes a timing issue in an automated point of sale sales test by ensuring quantity changes entered through the numpad are fully applied before the test continues. The change helps keep quality checks stable and reduces false test failures during development.
Original PR description
Wait for the quantity update to take effect when updating with numpad. runbot-230078
This update fixes an unstable automated test in the HTML editor area by ensuring the dropdown is handled consistently. It helps reduce false failures in Odoo's test pipeline, making validation runs more dependable without changing user-facing behavior.
Original PR description
The input dropdown is a popover and is therefore affected by [1]. Because of that, we cannot simply use `contains` without awaiting properly as it can easily break non-deterministically on the runbot. [1]: https://github.com/odoo/odoo/pull/211426/commits/54da715df84789f9a1acc0cfc91be41dcdbab140
This fix prevents upgrade failures when one module changes a field to use company-specific values while another module is being updated. It helps ensure upgrades complete reliably without unwanted database type conversion errors.
Original PR description
before this commit: if module_A has a field ``company_dependent=False`` and module_B override it to ``company_dependent=True`` When -u module_A, there would be an error since ORM tries to convert column type of the field from varchar/integer/boolean... to jsonb This commit will add a patch to the field in the ORM registry if the field was company dependent before upgrade. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customer invoice lists can now be sorted using the Status and Sent columns. This makes it easier for accounting users to organize invoices and quickly find records based on payment or delivery status.
Original PR description
**Issue** Users were unable to sort invoices by the "Status" and "Sent" columns in the customer invoices list view. **Steps to Reproduce** 1. Go to Accounting > Customers > Invoices 2. Try sorting by the "Status" or "Sent" columns 3. Observe that sorting is not functional for these fields **Root Cause** Both `status_in_payment` and `move_sent_values` are computed (non-stored) fields. Odoo cannot sort by non-stored fields unless a SQL representation is provided using the `_field_to_sql` method. Opw-4976838 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an intermittent automated test failure in Point of Sale when checking barcode searches for product variants. The change makes the test wait for the right product state, reducing false failures in validation runs without changing customer-facing behavior.
Original PR description
This fixes a random runbot failure in the barcode search test involving product variants. The issue was caused by timing problems when selecting a second variant of a product with the same template…
This fixes a random runbot failure in the barcode
search test involving product variants.
The issue was caused by timing problems when selecting a second variant of a product with the same template name. Due to UI delays, the wrong variant could be selected.
The issue happened in this sequence:
- The test searched the first barcode (12341357), which correctly
displayed the product template "Product with Attributes" with the
variant (Value 1, 3, 5, 7) preselected.
- The product was added successfully.
- Then the second barcode (12342468) was searched. But before the UI
had time to update
and reflect the new variant (Value 2, 4, 6, 8), the test clicked
again on the same product template — which still had the *first*
variant preselected.
- As a result, the first variant was added twice, and the expected
second variant was missing.
To prevent this, a distinct product template ("Product without Attributes") was introduced between the two variant searches to give the UI enough time to refresh. The tour was also updated to properly wait for the correct product to appear and to avoid triggering the configurator on products without attributes.
runbot-230339Geolocation lookup no longer crashes when a contact or sub-contact has no name. This keeps the address lookup workflow stable and shows a clearer contact label when no match is found.
Original PR description
<b>Steps to reproduce:</b> 1. Install base_geolocalize and Contacts > Go to Contacts. 2. Create a new contact or select an existing one (Individual). 3. Go to Contacts & Addresses > Add, leave all…
<b>Steps to reproduce:</b>
1. Install base_geolocalize and Contacts > Go to Contacts.
2. Create a new contact or select an existing one (Individual).
3. Go to Contacts & Addresses > Add, leave all fields empty, then Save & Close.
4. Open the newly created sub-contact > Partner Assignment > Geolocation
5. Click "Compute based on address".
<b>Issue:</b>
- Traceback is raised during geolocation computation if the sub-contact has no name Instead of Displaying.
<b>Cause:</b>
- If a partner does not have a name, the value is False.
- The join() operation results in a TypeError because False cannot be concatenated with strings.
<b>Problematic line:</b>
`'message': _('No match found for %(partner_names)s address(es).', partner_names=', '.join(partners_not_geo_localized.mapped('name')))`
<b>Solution:</b>
- Replaced `name` with `display_name` to ensure all elements passed to`join()` are strings.
This also improves readability in the UI when identifying partners without proper names.
opw-4930258
Forward-Port-Of: odoo/odoo#218292This fixes an issue where manually adjusted tax amounts on Portuguese vendor bills could make the displayed untaxed total differ from the accounting entries. The tax summary now stays aligned with the posted bill values, reducing confusion during invoice review and accounting reconciliation.
Original PR description
Create a vendor bill with a base of 123 and 23% tax. => untaxed_amount = 123 & amount_tax = 28.29 Edit the tax amount to be 28.30 => The tax totals shows an untaxed_amount of 122.99 but the accounting entries say 123.0 This is because during the rounding, since the tax computation is custom in Portugal, we subtract the tax amount from the total amount to get the expected base amount. Since the total is not updated according the tax lines, the base amount takes the difference instead of the total. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Cash Flow report now handles grouping by account codes consistently, preventing an error that could block report generation. This helps accounting users access the expected report breakdown without disruption when account code fields are present.
Original PR description
The term used by GROUP BY should be the same term in the SELECT, avoiding the posible error like: ERROR: column "account_move_line__account_id.code_store" must appear in the GROUP BY clause or be used in an aggregate function That appears when a column named account_code is created for the model account_move_line. opw-4963180
The Journal Audit report PDF export now works when users filter by receivable or payable account types. This prevents an error screen during export and helps accounting teams generate audit documents reliably.
Original PR description
- In the Journal Audit report options, set the Account Type (filter_account_type) to either receivable, payable, or both. - Attempt to export the PDF of the Journal Audit report. A traceback occurs because, in _generate_document_data_for_export, we attempt to add a join using an alias. However, if the filter_account_type option is enabled, there is already a left join in the query with the same alias: account_move_line__account_id. opw-4926547
The Belgian payroll salary configurator now calculates the laptop benefit in kind correctly. This ensures employee salary packages reflect the right laptop value, aligning it with existing internet and mobile benefit handling.
Original PR description
The benefit in kind laptop salary rule was not adapted for the salary configurator. This commit fixes the issue by always returning the correct laptop value if the salary rule is used in a salary configurator, like it is already the case for the internet and mobile benefits. task-4971722
The outdated Sign Base Folder setting is now hidden because it no longer works. Users should manage folder choices through Sign Document Templates instead, reducing confusion in configuration.
Original PR description
The setting no longer works and will be removed in future versions. Users should configure folders via Sign Document Templates instead. task-4879652
The default 13th-month salary rate for Swiss payroll contracts has been adjusted from 8.33% to 8.3333%. This improves payroll calculation accuracy and helps ensure Swiss salary amounts are computed with the expected precision.
Original PR description
-changed the default contractual thirteen month rate for Switzerland from 8.33 to 8.3333 Forward-Port-Of: odoo/enterprise#92095
Upsell orders now prevent users from changing the commission plan when the original subscription has Freeze Plan enabled. This avoids confusion by matching what users can edit with the commission plan that will actually be used for payouts.
Original PR description
**Problem:** An inconsistent behavior occurs when a user changes the commission plan while creating an upsell order for a recurring Sales Order (SO). **Steps to reproduce:** 1) Install the…
**Problem:** An inconsistent behavior occurs when a user changes the commission plan while creating an upsell order for a recurring Sales Order (SO). **Steps to reproduce:** 1) Install the Subscriptions and partner_commission modules. 2) Create a subscription SO with a referrer_id and set a recurrence. 3) Enable the Freeze Plan option and create a commission plan from the view 4) Add a rate of 50 and product category as service in the commission rules. 5) In SOL add a subscription product contains recurrence with unit price of 100 6) Confirm the SO → Create Invoice → Confirm → Pay. 7) Go back to the SO and create an upsell for it. 8) Change the commission plan rate to 30 by creating a new plan. 9)Repeat step 4. **Issue:** When you navigate to the referrer record from the SO and open the Purchase Order via the smart button, you will see two Purchase Order lines both showing a value of 50, even though the upsell order had a new commission plan with a rate of 30. **Cause:** When the invoice is marked as paid, a Purchase Order with POL is created using values from the commission plan. For subscription orders, the system intentionally uses the subscription’s original commission plan instead of the updated one. https://github.com/odoo/enterprise/blob/03a5efc04538fce380ec3ea993e7586047fe117e/partner_commission/models/account_move.py#L197-L203 However, the problem is that the commission plan field remains editable in upsell SOs even when the parent SO has Freeze Plan enabled, misleading users into thinking the new commission plan will be applied. **Solution:** Make the commission plan field read-only for upsell SOs when the parent SO has Freeze Plan enabled. opw-4954307
The accounting reports test suite was adjusted to avoid using unsupported grouping settings with external report calculations. This prevents false test failures for complex tax reports, helping keep accounting report validation reliable.
Original PR description
The corresponding community PR (https://github.com/odoo/odoo/pull/221407) contains a fix that requires the _validate_engine constraint to reject any groupby value for the 'external' engine. Therefore, it is now needed that the test ensuring non-stored related fields can be used in groupby is adapted in order to also exclude those expressions when changing the groupby value of the lines using a custom engine on any of their expressions. Without that, complex reports like the annexes of the Luxembourgese tax report fail the test.
Automatic currency rate updates from the Central Bank of the UAE now include the Sudanese Pound. This ensures businesses using SDG receive current exchange rates instead of having to update them manually.
Original PR description
**Steps to reproduce**: 1. Install the `account` and `l10n_ae` modules. 2. Go to `Invoicing → Configuration → Currencies` and activate the `Sudanese Pound (SDG)` currency. 3. Navigate to `Settings → Invoicing → Currencies → Automatic Currency Rates`. 4. Select `[AE] Central Bank of the UAE` as the currency provider and manually fetch rates. <img width="463" height="181" alt="image" src="https://github.com/user-attachments/assets/31257e2e-8360-4cdb-877e-2ea41487ddea" /> 5. Return to the Currencies list. **Observed behavior**: - The rate for the `Sudanese Pound (SDG)` is not updated. **Root cause**: - The `SDG` currency is missing from the `MAP_CURRENCIES` dictionary, so the provider doesn't fetch its rate. **Solution**: - Add the missing `SDG` currency mapping to `MAP_CURRENCIES`. opw-4869204 Forward-Port-Of: odoo/enterprise#91790