Monday, April 13, 2026
40 changes · saas-19.2
Enhancements to existing features
This update simplifies the printer LNA (Label Next Available) configuration by consolidating checkbox options. Previously, printers had separate IoT and ePOS checkboxes, which were confusing for clients. Now, a single ePOS checkbox controls the LNA functionality, streamlining the process and improving usability.
Original PR description
The printer model has two checkboxes: one for IoT and one for ePOS. LNA is already hard for clients to understand, we then simplify it by removing the IoT one from the printer model, to use the ePOS one for both. If we check `use_lna` for on a printer type "iot", it will check the checkbox on the IoT Box record. Also, if we check/uncheck `use_lna` on the IoT Box record, it will check/uncheck it on the corresponding printer model.
This update ensures Odoo correctly handles tax exemptions related to international transactions (UBL Cii) by incorporating all required tax exemption reasons defined by Peppol. This improves compliance with international tax regulations and avoids potential issues with cross-border invoicing.
Original PR description
Some tax exemption reasons were missing, This commit ensures having all the tax exemption reasons introduced by Peppol task-6048561 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258455 Forward-Port-Of: odoo/odoo#254841
Resolved issues and error corrections
This update resolves an issue where Odoo displayed a misleading 'This message has been removed' notification in the chatter when an approval request was canceled before a purchase order was created. The fix ensures that chatter messages are only logged when there's actual information to display, improving the user experience and preventing unnecessary notifications.
Original PR description
Steps to reproduce: ------------------------------------ 1. Install `approvals_purchase` module with demo 2. Approvals > New Request in Borrow Items 3. Create request with any product 4. Click on the Submit button 5. Click on the Cancel button Observation: ------------------------------------ In chatter there's a message stating: 'This message has been removed' Issue: ------------------------------------ When you cancel an approval request that has no purchase orders created yet, the `_log_po_cancellation_to_chatter` method is called with an empty `cancellation_log_msg` string, which causes Odoo to display 'This message has been removed' in the chatter. Solution: ------------------------------------ Only log to chatter if there's actually a message to log opw-6063998 Forward-Port-Of: odoo/enterprise#112454
This update enhances the logging of Stripe payment rejections for expense reports. Now, both the MCC name and code are recorded, providing clearer details for troubleshooting and improving the accuracy of expense data. This change helps our team quickly identify and resolve issues related to payment processing.
Original PR description
Before this commit: - Only the MCC name was logged when Stripe refused an MCC. After this commit: - The MCC code is now logged along with the MCC name for better clarity and debugging. task-6084569 Forward-Port-Of: odoo/enterprise#112599
This update simplifies error messages during database synchronization, reducing user alarm and confusion. Instead of detailed error lists, users now see a summary count of issues. Detailed error information is now logged in a separate location for technical review, streamlining the process.
Original PR description
This commit reduces the verbosity of error messages displayed in the synchronization wizard to avoid creating an unnecessary sense of alarm for users. Instead of showing a detailed list of errors,…
This commit reduces the verbosity of error messages displayed in the synchronization wizard to avoid creating an unnecessary sense of alarm for users. Instead of showing a detailed list of errors, the wizard now displays a single summary message indicating the number of databases that encountered an issue. A new Unreachable project tag is introduced (loaded from project_tags.xml if missing). It is automatically assigned to failing databases and removed upon the next successful synchronization. Detailed error information is no longer shown in the wizard and is instead logged in the chatter of the corresponding database settings for further inspection. Previously displayed non-blocking warnings for already-configured SaaS databases are now omitted to reduce noise, as they would otherwise generate chatter messages at each synchronization. Task-id: [5945269](https://www.odoo.com/odoo/project.task/5945269) Forward-Port-Of: odoo/enterprise#113585 Forward-Port-Of: odoo/enterprise#107975
This update resolves a warning message appearing when employee contracts partially overlapped with payslip periods. The fix ensures that contracts with even a single overlapping day are now processed without the warning, improving user experience. This change was made to align with the latest version (v.19) and addresses a known issue in previous versions.
Original PR description
[FIX] hr_payroll: fix payslip warning bug Bug reproduction: 1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well) 2 - Create an employee and make…
[FIX] hr_payroll: fix payslip warning bug
Bug reproduction:
1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well)
2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026 (DD/MM/YYYY) format.
3 - Generate payslip for March, the warning of "The period selected does not match the contract validity period" popups.
4 - But we do not want that, even though there is 1 overlapping day in contract with payslip we can continue.
Bug cause:
1 - In >= v.17 (not in v.19), there was a warning, when the contract dates do not fully contains the payslip dates, the warning was appearing.
2 - In v.19 it is not the case, when there is a contract that overlaps at least one dat of the payslip then we are fine, if no overlap then no contract on payslip warning should appear
Bug solution:
1 - I replaced old warning "The period selected does not match the contract validity period" with the one in v.19 "No running contract over payslip period"
Tests:
1 - There was a unit test about old warning (test_payslip_warnings), I changed that parts.
2 - I added further steps to the existing test about the new warning that should appear (No running contract over payslip period)
Note: Implemented feature: need to check what happens after v.17, should be removed in v.19 latest, maybe before as well.
task - 6006693
Forward-Port-Of: odoo/enterprise#109791This update resolves a problem where EPD bill payments weren't correctly marked as 'paid' in the system. The fix ensures that payments are accurately reflected after reconciling an EPD bill with a bank transaction, improving financial reporting accuracy. This was triggered by a specific test scenario involving early payment terms and EPD bills.
Original PR description
Steps to reproduce: - Create an early payment term. - Create a Vendor Bill with EPD and post it. - Register a payment for this bill (no outstanding account set on journal => no move created). - Create a bank transaction fully paying the bill. - Reconcile the transaction with the bill. Issue: Access the payment of the bill. The payment state remains 'in_process' instead of 'paid'. Fix in community: https://github.com/odoo/odoo/pull/256486 opw-5881976 Forward-Port-Of: odoo/enterprise#113357 Forward-Port-Of: odoo/enterprise#112398
This update resolves a technical issue that was preventing our payroll performance tests from running correctly. The change ensures the test setup properly initializes time off types, restoring the test suite's functionality without impacting normal business operations. This improves the reliability of our payroll performance testing.
Original PR description
Description of the issue this commit addresses: A constraint forbids changing requires_allocation on time off types once related leaves exist. The payroll performance test setup still toggled that field directly so the class crashes during initialization. --- Desired behavior after this commit is merged: This commit makes the performance test setup update seeded time off types in install context. The class initializes correctly again and the broken payroll test suite runs without changing normal business behavior. --- runbot-240729
A bug was preventing users from deleting timesheets when a confirmation dialog was open. The fix ensures that pressing the Enter key in the timesheet list view now correctly triggers the delete action instead of starting or stopping the timer. This improves the user experience and prevents incorrect time tracking.
Original PR description
When a delete confirmation dialog is open in the timesheet list view, pressing Enter starts/stops the timer instead of confirming the dialog. This happens because the timer's window keydown handler does not check for active modals before intercepting the Enter key. Add a `.modal` check consistent with the grid renderer's onKeyDown. Steps to reproduce: 1) Open timesheet list view 2) Select a record and delete it 3) When the confirmation dialog opens, hit ENTER key Current behavior: The Timer starts recording timesheet Expected behavior: The record should be deleted For ref: https://youtu.be/tzm_3RNe1ig Forward-Port-Of: odoo/enterprise#113207 Forward-Port-Of: odoo/enterprise#112583
This update addresses a minor usability issue in the Odoo form editor. Previously, groups within the editor were difficult to see and access due to a lack of padding. This change reintroduces padding to improve the visibility and accessibility of these groups, making the form editor more user-friendly.
Original PR description
Before this commit, and consequently to odoo/enterprise#8489b760dd601d2a5196c8323eb0e1929c0f2132 the "groups" in the form editor were not easily visible or accessible because they lacked some padding. After this commit, we reintroduce some padding. task-6072333
This update prevents regular employees from modifying target job selections within appraisals. The original issue stemmed from employees lacking the necessary permissions to view company job postings, leading to access errors. The fix restricts the 'target job' field to managers, aligning with the correct workflow and improving data integrity.
Original PR description
Steps to reproduce: 1- Create an appraisal for a regular employee 2- Confirm it so its state changes to 'ongoing' 3- Try to change the target job as an employee 4- Click on see more Cause: The main cause is that regular employees lack the privilage to view job postings by a company. therefore an access rights errors is resulted when the flow is executed. Solution: Made the field readonly for normal employees (as it should be, target jobs are the managers' responsibility to change). Forward-Port-Of: odoo/enterprise#112663
This update fixes a misleading warning in the payroll system that appeared when employee contracts overlapped slightly with payslip periods. The change ensures that a warning only appears when there's a genuine overlap, improving the user experience and preventing unnecessary alerts. This resolves an issue identified in previous versions.
Original PR description
Bug reproduction: 1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well) 2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026…
Bug reproduction:
1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well)
2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026 (DD/MM/YYYY) format.
3 - Generate payslip for March, the warning of "The period selected does not match the contract validity period" popups.
4 - But we do not want that, even though there is 1 overlapping day in contract with payslip we can continue.
Bug cause:
1 - In >= v.17 (not in v.19), there was a warning, when the contract dates do not fully contains the payslip dates, the warning was appearing.
2 - In v.19 it is not the case, when there is a contract that overlaps at least one dat of the payslip then we are fine, if no overlap then no contract on payslip warning should appear
Bug solution:
1 - I replaced old warning "The period selected does not match the contract validity period" with the one in v.19 "No running contract over payslip period"
Tests:
1 - There was a unit test about old warning (test_payslip_warnings), I changed that parts.
2 - I added further steps to the existing test about the new warning that should appear (No running contract over payslip period)
Last Test Update:
1 - I noticed that contract date changes was not affecting the warning appearance directly
2 - Unit test is expanded with contract date change and observing the warning appearance
Note: Implemented feature: need to check what happens after v.17, should be removed in v.19 latest, maybe before as well.
task - 6006693
Forward-Port-Of: odoo/enterprise#113566
Forward-Port-Of: odoo/enterprise#112758This update fixes a technical issue where duplicate checks were being generated during tax return creation, causing errors. The change prevents the same check code from running multiple times, ensuring smoother tax return generation processes. This improves reliability and avoids user disruption.
Original PR description
Steps to reproduce:
- Go to Accounting → Configuration → Accounting → Return Types.
- Open the standard Annual Closing: Corporate Tax return type.
- Select Generic Tax Report as a report in the Report field.
- Navigate to Accounting → Accounting → Closing → Tax Returns.
- Generate the tax return for the selected period.
Issue:
- Duplicate checks with code check_draft_entries are created for the same return, raising:
'You can only have a unique check code for each return.'
This happens because:
- `_check_suite_common_vat_report` adds a Draft entries check.
- `_check_suite_annual_closing` also adds a similar check (No draft entries) with the same code.
- Both run together, causing duplication.
Solution:
- Added `check_codes_to_ignore.add('check_draft_entries')`
in _check_suite_common_vat_report to ensure the check is not generated twice.
opw-6066030
Forward-Port-Of: odoo/enterprise#113393This update adjusts Belgian payroll tax rates (FFE) to reflect the latest regulations for 2026. This ensures accurate tax calculations and compliance for Odoo Enterprise users operating in Belgium, minimizing potential financial discrepancies. The change is a technical fix to maintain accurate reporting.
Original PR description
Forward-Port-Of: odoo/enterprise#113426
This update resolves a potential memory issue that could occur when processing large payroll warning datasets. The fix limits the number of warnings displayed and optimizes the search process, preventing errors and improving performance. A visual indicator now shows when a large number of warnings are truncated.
Original PR description
Before this commit, domain-based records were searched and then eventually filtered afterwards. With or without the filter, for very large recordset fetched, it was possible to get a MemoryError. This commit introduces 2 fixes: - removes the filter after the search and replaces it by an extension to the domain - limit domain-based warnings to 1000 records and displays a '+' on the dashboard to indicate that the results were truncated task-6093607
This update resolves a technical error that prevented label printing when validating receipts through the barcode app. The fix utilizes an optional operator to handle cases where receipt data is missing, ensuring labels can now be printed correctly.
Original PR description
Given a printer is configured to print a label for product receipts, when the receipt is validated from the barcode app, then a traceback appears. A filter on action.context.active_ids was introduced in https://github.com/odoo/enterprise/pull/106277. When validating the receipt from the purchase app, active_ids is set to the id of the purchase order and the behavior is as expected. When validating the receipt in the barcode app , it is not set (nor was it set in 17.0). The filter therefore crashes because it cannot work on undefined. An optional chaining operator is added to apply the filter only if active_ids is set. The barcode app does not raise a traceback anymore when validating a receipt and the label can be printed. Forward-Port-Of: odoo/enterprise#113146
This update fixes an issue where the mutual health warning incorrectly flagged employees with long sick leaves before 31 days. The change now accurately identifies employees who have been on sick leave for at least the past 31 days, ensuring more accurate reporting and compliance. This improves the reliability of payroll data.
Original PR description
-**Issue**: The warning shows employees who had a long sick leaves before 31 days, which is incorrect. -**Fix**: Adjust the logic to include employees who have been on a sick leave for the past 31 days (at least). Forward-Port-Of: odoo/enterprise#113249 Forward-Port-Of: odoo/enterprise#112985
A recent issue prevented users from accessing server actions within the Document module due to a problem with how the system prioritized its views. This update corrects this prioritization by setting a specific priority for the Document module's server action view, ensuring the correct view is displayed and the user interface functions properly.
Original PR description
When the document module is installed, sometimes the server action view that is shown when accessing the server actions from the normal menu can be broken: the model field for instance is no longer visible, which makes the user interface unusable. <img width="723" height="412" alt="image" src="https://github.com/user-attachments/assets/73f6d516-77be-4f66-80dc-033fd8c0cb7c" /> This is because the document module defines a new primary form view for server actions, but does not set a priority for that view. As a result we have 2 primary views, with the same default priority of 16 in the database, and in that case the sorting of view can lead to the document specific view to be selected, when the other one is expected. We fix this by explicitly setting a priority of 32 on the form view in the document module. Forward-Port-Of: odoo/enterprise#112847
This update fixes an issue where product names displayed in purchase order lines would change between different pages of the order. The fix ensures product names are consistently shown, improving order clarity and accuracy. This resolves a display inconsistency that could lead to confusion.
Original PR description
**Steps to reproduce:** * Install the *Purchase* module * Create a product and set an *Reference* and Under the *Purchase* tab, add a vendor and define a *Vendor Product Code*. * Create a Purchase…
**Steps to reproduce:** * Install the *Purchase* module * Create a product and set an *Reference* and Under the *Purchase* tab, add a vendor and define a *Vendor Product Code*. * Create a Purchase Order with the same vendor set as on the product. * Add the configured product to the *Purchase Order Lines*. * Add the same product again on a second line and save the order. * Activate debug mode * Go to the view:Form and add a limit to have only 1 POL per page * Return to your PO * Go to the second page **Observed behavior:** * The *product display name* in the purchase order lines is different on the second page compared to the first page. **Cause:** * On the first page, purchase order lines are fetched via a web_read on the purchase order. * On subsequent pages, lines are fetched via a web_read directly on the purchase order lines. * The client requests both name and product_id.display_name. product field context includes partner_id, causing product_id.display_name to be computed as the vendor name. * As both values resolve to the vendor name, the original product name is lost, leading to inconsistent display across pages. **Note:** A similar issue was addressed in this commit : https://github.com/odoo/odoo/commit/28d53e0e565e266ca3fa2b67e359b4383fa42c36 * but its consequence it breaks the search using the vendor code/name in POL. * That change was reverted in this commit duo to the there consequence : https://github.com/odoo/odoo/commit/c9e8a802315be27a076ae677b9191c075e4c239d **Fix:** * This ensures the product name is propagated correctly in the form view while preserving search by vendor code or name. --- opw-5170924 Forward-Port-Of: odoo/odoo#258467 Forward-Port-Of: odoo/odoo#240515
This update fixes a minor issue in the Odoo list editor where the cursor wasn't updating correctly when the list was being reformatted. This ensures a smoother and more intuitive user experience when editing list items, preventing potential confusion for users. It's a technical refinement to improve the overall usability of the Odoo interface.
Original PR description
Description of the issue this PR addresses: This PR is a fixup to [[1]](https://github.com/odoo/odoo/commit/77cbdc0120f7ae7d5c777eb946ad568f2caf05d7) where cursor was not updated properly before unwrapping the element. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258558
This update resolves an issue preventing credit notes from being correctly exported to Mojeracun when a recipient bank account isn't specified. The fix addresses two underlying problems: a faulty check for bank account data and an incorrect structure within the XML export format. This ensures credit notes are now successfully generated and sent.
Original PR description
**Steps to reproduce:** * Install `l10n_hr_edi` module. * Generate an invoice and validate it. * Generate a credit note from that invoice. * Without a recipient bank account, try to send the credit…
**Steps to reproduce:**
* Install `l10n_hr_edi` module.
* Generate an invoice and validate it.
* Generate a credit note from that invoice.
* Without a recipient bank account, try to send the credit note to Mojeracun.
**Observed behavior:**
* Two errors are raised before the XML is generated:
1. `AttributeError: 'NoneType' object has no attribute 'get'` in `_invoice_constraints_eracun_new` when checking for whitespace in the bank account number.
2. `ValueError: The following child node is not defined in the template: CreditNote/cac:BillingReference/cbc:IssueDate` during XML serialization.
**Cause:**
* issue 1 : https://github.com/odoo/odoo/commit/96cf6626d2b3e75637b908244cf2fa4da615c16b#diff-16f43166a8e5a637cb57b5695a1332845ba5440d989e25fcd59c828aa55cb036R81
* In the mentioned commit `_invoice_constraints_eracun_new`, `node.get('cac:PayeeFinancialAccount', {})` returns `None` instead of `{}` when the key exists but its value is explicitly set to `None` (which happens when no bank account is set). Chaining `.get()` on `None` raises `AttributeError`.
* issue 2 : https://github.com/odoo/odoo/commit/47ef0c2cb96be9fffdc4985255661807980839c6#diff-16f43166a8e5a637cb57b5695a1332845ba5440d989e25fcd59c828aa55cb036R146
* In the mentioned commit in `_ubl_add_billing_reference_nodes`, `cbc:IssueDate` was added as a direct child of `cac:BillingReference`. The UBL template only allows `cac:InvoiceDocumentReference` as a child of `BillingReference`, while `cbc:IssueDate` belongs inside `cac:InvoiceDocumentReference`.
**Fix:**
* Replace `.get('cac:PayeeFinancialAccount', {})` with `.get('cac:PayeeFinancialAccount')` to safely handle an explicitly `None` value before chaining further calls.
* Move `cbc:IssueDate` inside `cac:InvoiceDocumentReference` in the `BillingReference` node, matching the structure defined in `ubl_21_common.py`.
opw-6088424
Forward-Port-Of: odoo/odoo#258057This update ensures that Belgian province names are displayed in their native Dutch and French, improving the user experience for customers and partners in Belgium. The change addresses a previous limitation where these names were not translatable, now allowing for accurate and localized content.
Original PR description
The `name` field of `res.country.state` is not translatable. For that reason we want to have the province names in their native language. [opw-6107258](https://www.odoo.com/odoo/project.task/6107258) Forward-Port-Of: odoo/odoo#258445 Forward-Port-Of: odoo/odoo#258339
This update fixes an error in the Luxembourg company balance sheet reporting. Specifically, the 'Results brought forward' line was displaying incorrect values due to a technical issue with how account balances were calculated. The fix ensures accurate reporting of financial results for Luxembourg businesses, aligning with standard accounting practices.
Original PR description
Steps to reproduce: - Use a Luxembourg company - Post a P&L result for the year and do the year-end affectation (Dr 142 / Cr 1412) - Open the Luxembourg balance sheet (full or abbreviated) Issue:…
Steps to reproduce:
- Use a Luxembourg company
- Post a P&L result for the year and do the year-end affectation (Dr 142 / Cr 1412)
- Open the Luxembourg balance sheet (full or abbreviated)
Issue:
Line "V. Profit or loss brought forward" shows incorrect values.
Cause:
The `accounts` expression for that line used `account_codes` engine with formula `-14`,
which only sums accounts by code prefix. Account 1412 ("Results brought forward (assigned)")
was typed as `equity`, so its balance was carried forward as an initial balance instead of
being captured as retained earnings in the formula.
Solution:
- Set account 1412 to `equity_unaffected`, consistent with account 142.
- Change the `accounts` expression of Line V in both the full and abbreviated balance sheet
to use the `domain` engine:
`['|', ('account_id.code', '=like', '14%'), ('account_id.account_type', '=', 'equity_unaffected')]`
with subformula `-sum`.
This correctly captures the balance of all 14x accounts and any `equity_unaffected` accounts,
which covers the standard year-end affectation workflow.
opw-5883505
Forward-Port-Of: odoo/odoo#253559This update corrects a minor typo in the account_peppol module, resolving an issue that was previously flagged. This ensures the PEPPOL integration functions correctly, preventing potential disruptions in financial transactions. The change is a simple correction and does not impact any core functionality.
Original PR description
Correction in a typo from the last commit opw-6102471 Forward-Port-Of: odoo/odoo#258456
A recent update to our billing exports caused the 'Export XML' button to disappear for certain invoices. This fix ensures the button reappears only when an invoice is actually exportable, improving the user experience and preventing confusion. This change was made to align with recent UBL export refactoring.
Original PR description
Problem --------- Since the UBL export refactor, it was not possible to export the XML of non-imported bills and not self-bills. The Export XML option had been removed from the list view in odoo/odoo#255289. The Form view was omitted. Solution --------- Show the button "Export XML" only if the move can actually be exported. opw-6083344 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258512 Forward-Port-Of: odoo/odoo#257910
This update resolves an issue where unwanted message actions appeared when right-clicking on links within emails. The fix expands the original solution to handle more complex link structures, ensuring consistent behavior across all email messages. This improves the user experience by preventing unexpected actions.
Original PR description
Before this commit, when right-click on a link in a message, this sometimes show the message actions. A commit was dedicated on fixing this issue [1], however this was limited to exact click on `<a>`. Many links shared by email are `<a>` with some nested nodes, for example `<a><font>LINK</font></a>`. Such links were not covered by [1] and thus made the message actions show on right-click. This commit fixes the issue by not showing the message actions on right-click on links, including nested children. [1]: https://github.com/odoo/odoo/pull/244252 opw-6110949 Forward-Port-Of: odoo/odoo#258681
This update resolves a warning appearing on Odoo.sh production branches during module updates. Previously, logging about temporary field changes caused a yellow status, even though the updates were successful. The change lowers the log level to DEBUG, aligning with other processes and ensuring Odoo.sh branches consistently show a green, healthy status.
Original PR description
Description of the issue/feature this PR addresses: During a module update (-u ModuleName), the check introduced by #220983 patches temporarily a field with "company_dependent=True" because the…
Description of the issue/feature this PR addresses: During a module update (-u ModuleName), the check introduced by #220983 patches temporarily a field with "company_dependent=True" because the overriding module is not loaded yet. But currently it is logged as a warning and makes Odoo.sh production branch appears in yellow (warning state), while the update is actually fine. Current behavior before PR: Logs may contain warnings such as: - Patching res.partner.ref with company_dependent=True - Patching product.template.sale_ok with company_dependent=True - Patching product.product.default_code with company_dependent=True even though there is no actual issue (ok normal behavior) The main problem is that this makes Odoo.sh production branches appear not with green status, while the update module is actually fine. Desired behavior after PR is merged: Keep the same mechanism, but lower the log level from WARNING to DEBUG. This aligns the behavior with the "translate=True" patch logic, which is already logged at DEBUG. Having the production branches green. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258444 Forward-Port-Of: odoo/odoo#258326
This update resolves an issue where the website's auto-hide tour occasionally failed due to a change in how the system handles layout updates. The fix ensures the tour correctly detects navbar changes after a layout refresh, improving the user experience. This ensures the tour consistently functions as intended.
Original PR description
Since the delay between tour steps was removed [1], this tour fails sometimes. After changing the layout, the iframe reloads, but the tour attempts to check if the navbar layout changed directly without any delay. [1]: https://github.com/odoo/odoo/commit/769b193 runbot-241849
A visual issue with the cart quantity input border was resolved. This update adjusts the styling to align with the recent upgrade of Bootstrap, ensuring consistent and correct border rendering for all users. This improves the overall user experience when adding items to the cart.
Original PR description
Steps to produce: --- - Install the `E-commerce` module. - Configure a product with a very large price. - Open the product on the website, add it to the cart, and navigate to the cart. Issue: --- -…
Steps to produce: --- - Install the `E-commerce` module. - Configure a product with a very large price. - Open the product on the website, add it to the cart, and navigate to the cart. Issue: --- - The quantity input group appears visually stretched, and the border rendering is inconsistent. Root Cause: --- - After upgrading from Bootstrap 5.1 to 5.3, border utility behavior changed. Classes like `border-end-0` no longer apply unless a base border class is also present. Solution: --- - Explicitly add the `border` class alongside `border-end-0` on the affected elements to restore the intended border styling. Before: --- <img width="822" height="185" alt="image" src="https://github.com/user-attachments/assets/6478083e-f5c1-4374-9c9a-979254eaee3d" /> After: --- <img width="828" height="188" alt="image" src="https://github.com/user-attachments/assets/5a1cb138-c9a5-4508-ad34-64d988904407" /> opw-6075996 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258777 Forward-Port-Of: odoo/odoo#256797
This update allows users to disable automatic PDF generation when importing XML invoices through the account_edi_ubl_cii module. Previously, all invoices triggered PDF creation, even without an embedded PDF, which was causing unnecessary file generation. Now, users have the flexibility to control this behavior.
Original PR description
Commit 7bc35c4 introduced automatic PDF generation for imported XML invoices that don't include an embedded PDF file. However, this behavior was mandatory and couldn't be disabled. This commit adds a new configuration parameter to allow users disable this behaviour. Task-6050566 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257905 Forward-Port-Of: odoo/odoo#254847
This update fixes a visual issue where translation status highlights were hidden behind button backgrounds in the website builder. By adding a small span element, the translation state is now consistently displayed, ensuring accurate and clear translation status indicators for all website elements.
Original PR description
When buttons (`a.btn` elements) are translated inline, or badges (`span.s_badge`), the background color that shows the status of the translation appears under the background of the button/badge. The…
When buttons (`a.btn` elements) are translated inline, or badges (`span.s_badge`), the background color that shows the status of the translation appears under the background of the button/badge. The status is thus only visible on the surrounding text, and completely invisible when the button is alone (unless it has a transparent background). This commit adds a plugin in translate mode which adds a span with the color of the translation status in the problematic elements if they are inside a translation span and have a background color. Steps to reproduce: - Open website builder - Drop the `s_banner` snippet (or add a button by typing `/button`) - Add a second language - Open in translate mode - Bug: the text of the button does not have the green/yellow highlight that shows the translation state (technically, it is hidden under the background of the button, which you can see if you set a transparent background on the button) `o_translate_inline` on links: - 8fe88de0d5cc61395721cd8bda7b7ef2ea961760 - f65ac79631180e77aca5a53fc557b3e1acfcbd65 - 6aef5ee411656ec400e92fcc2bbd62e420645e0e task-6038029 Forward-Port-Of: odoo/odoo#258396 Forward-Port-Of: odoo/odoo#254000
This update corrects a display issue in the Point of Sale session reports. Previously, reports showed excessive decimal places when selling products with decimal quantities. The fix ensures that report totals are presented with the standard two decimal places, improving clarity and accuracy for sales reporting.
Original PR description
When selling a lot of product with different quantities (quantities with decimals) the session report total by category might have a lot of decimals instead of 2. Steps to reproduce: ------------------- * Open PoS * Make an order with a lot of product and modify the quantities to have random values with decimals * Close the session * Generate the session report > Observation: The total qty by category has a lot of decimals instead of the 2 expected. The same error also happens for the total price Why the fix: ------------ We round each value with their respective precision to make sure we don't have 15 decimals. opw-6039016 Forward-Port-Of: odoo/odoo#257885 Forward-Port-Of: odoo/odoo#256038
This update resolves an issue where attendance records were incorrectly flagged as duplicates due to incorrect timezone calculations. The fix ensures accurate attendance tracking by correctly applying employee timezones when determining check-in times, preventing errors related to timezone offsets.
Original PR description
### Steps to reproduce: - Have a database in timezone America/Asuncion for example - Create an employee - Create an attendance for the day before yesterday from 13h to 19h - Run the absence detection cron - An error will be raised saying the user is already checked-in on that day ### Cause: When trying to create an absence attendance we localized yesterday's midnight into UTC and then apply the employee timezone. Which cause a one-day shift when having a timezone behind UTC as at that point we try to create an attendance on the day before yesterday not yesterday ### Fix: We use the timezone of the employee to localize midnight then get this time in UTC. opw-5930309 Forward-Port-Of: odoo/odoo#258492 Forward-Port-Of: odoo/odoo#257932
This update resolves a bug that prevented users from successfully replacing images with illustrations in the mass mailing editor. The fix ensures compatibility by converting illustrations to PNG format for broader email client support and updating the system to correctly handle image attachments with optional parameters.
Original PR description
Currently, in the mass mailing editor, an error occurs when a user replaces an image with an illustration. Steps to reproduce: 1. Open the mass mailing editor 3. Drag and drop a snippet containing an…
Currently, in the mass mailing editor, an error occurs when a user replaces an image with an illustration. Steps to reproduce: 1. Open the mass mailing editor 3. Drag and drop a snippet containing an image 4. Double-click on the image 5. In the image search bar, type "test" and press `Enter` 6. Select an illustration => A traceback is raised. When an illustration is selected, it is automatically stored as an attachment with the mimetype `image/svg+xml; charset=utf-8`. The editor then loads the image using the attachment URL (e.g. `/html_editor/shape/illustration/usability-testingsvg-258?...`). When the media dialog is closed (via `on_media_dialog_saved_handlers`), the editor attempts to process the image and calls the `/html_editor/get_image_info` route to retrieve the image info. This route retrieves the corresponding attachment from the database using the attachment url, but filters results based on a predefined set of allowed mimetypes. The issue arises because this set does not account for valid mimetypes that include optional parameters such as `charset=utf-8`. As a result, the attachment is not found, preventing the image from being processed and ultimately causing the crash. To fix the issue, we will update the domain used to retrieve image attachments so that it accepts valid mimetypes with optional parameters (e.g. `image/svg+xml; charset=utf-8`). During image processing, the transformed image is temporarily encoded in base64 and stored in the src attribute. When the record is saved, this base64 image is converted into a new attachment via the `/html_editor/modify_image/<id>` route. **This conversion step is necessary because many email clients have limited support for SVG images. Converting the illustration to PNG ensures better compatibility and visibility across mail clients.** After conversion, the image url is then set to `/html_editor/shape/illustration/335/usability-testingsvg-258?...` This URL is handled by the `html_editor/shape/<module>/<path:filename>` route. Its purpose is to process SVG files and dynamically adjust their colors based on query parameters (e.g. the `c1` parameter). However, once the image has been converted to PNG, this logic no longer applies. To address this, an additional conditional check will be introduced: if the file is not an SVG, the route will bypass the SVG-specific transformation logic and instead serve the image directly. Task-5977962 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255134
This pull request resolves an issue where email templates related to sales orders were not being correctly applied. The changes update data files in the 'sale' and 'website_sale' modules, ensuring that customers receive the appropriate email notifications for their orders. This improves the overall order process and customer communication.
Original PR description
Issue: Steps to reproduce: Cause: opw-6114223
This pull request resolves an issue where email templates related to website and sales functionalities were not being correctly applied. The update corrects a data file discrepancy, ensuring that relevant email notifications are sent to users during website browsing and sales processes. This improves the user experience and ensures consistent communication.
Original PR description
Issue: Steps to reproduce: Cause: opw-6114223
This update prevents a bug where changing a child company's ZATCA API mode would inadvertently reset and unboard the parent company's related sales journal. The fix ensures that journal resets are limited to the company being modified, improving data consistency and preventing unexpected disruptions.
Original PR description
**Steps to reproduce:** * Install `l10n_sa_edi` module. * Create a parent company and a child company, both with the same VAT number. * Onboard the parent company's Sales journal with ZATCA. *…
**Steps to reproduce:**
* Install `l10n_sa_edi` module.
* Create a parent company and a child company, both with the same VAT number.
* Onboard the parent company's Sales journal with ZATCA.
* Onboard the child company's Sales journal with ZATCA. Create a journal for the child if there is no journal.
* Change the child company's ZATCA API mode to any other mode.
**Observed behavior:**
* Changing the child company's API mode resets and unboards the parent company's Sales journal as well.
**Cause:**
* In `res.company.write`, when `l10n_sa_api_mode` changes, journals to reset are fetched using `_check_company_domain(company)`.
* `account.journal` uses `check_company_domain_parent_of`, which returns journals where `company_id` is a parent of the given company — so passing a child company also matches journals belonging to the parent.
**Fix:**
* Replace `_check_company_domain(company)` with a direct `('company_id', '=', company.id)` filter, so only journals strictly owned by the company being modified are reset.
opw-6099340
Forward-Port-Of: odoo/odoo#258750
Forward-Port-Of: odoo/odoo#258006This update resolves an issue where reopening the Point of Sale (PoS) after an archived combo product was removed caused an error. This change ensures a smoother user experience when managing products, preventing disruptions to sales operations. The fix was part of a larger effort to improve PoS stability.
Original PR description
Before this commit, when a combo product was archived, and the PoS was reopened, an error was raised. opw-5952006 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250673
This update resolves an issue where creating a financial transaction without a linked partner would cause an error when attempting to export the XML. The fix ensures that the system handles these moves correctly, preventing disruptions in the export process and improving data reliability. This change ensures all financial transactions can be exported without errors.
Original PR description
Issue: Confirmed move without partner get a traceback while opening the cog wheel Steps to reproduce: - Create a misc move without Partner/commercial partner. - Confirm it - Click on the cog wheel button Current behavior: - Traceback Before commit 48983eb6efdd6690f92f2839eedd39d9a288ab42, looping on `move.commercial_partner_id` prevented calling `_get_ubl_cii_edi_format` on empty records. no-task Forward-Port-Of: odoo/odoo#258881
This update resolves an issue where Odoo restarts could fail due to a delay in initializing the server. The fix adds a check and retry mechanism, ensuring restarts are more reliable and preventing potential disruptions to Odoo's operation. This improves overall system stability.
Original PR description
`service.server.restart()` can sometimes fail when `server` attribute is not yet set. We now add a check and retry. Task: 5982438