Daily updates from Odoo
Monday, September 29, 2025
61 changes · 19.0
Security fixes and vulnerability patches
Shared MP4 videos in Documents can no longer be previewed by anyone with only a public link. This reduces unintended public viewing and helps prevent the system from being used as a video streaming service.
Original PR description
**Issue:** When sharing an MP4 video with "Anyone with the link" viewer access, the video is available to preview without login. **Steps to reproduce:** 1. Install documents 2. Upload an MP4 video 3. Share it with the smart button with anyone with the link viewer access 4. Copy link and paste it in incognito in chrome **Result:** - Video preview option is available **Cause:** - The method get_previewable_file_extensions allows 'mp4' videos to be previewed. **Solution:** - Remove the 'mp4' extension from the previewable list. **NOTE:** - We do not want to be 'used' as a video streaming platform. We do not do it for our own eLearning videos, so we can't do it here, Preview file should simply not be publically available for videos we host. opw-4926384 Forward-Port-Of: odoo/enterprise#90158
Enhancements to existing features
Hong Kong Payroll now includes a dedicated button to download IR56B report files in XML format. This makes it easier for payroll users to retrieve the required tax reporting file directly from the relevant screens.
Original PR description
Add ir56b report download button for downloading .xml file in Hong Kong Payroll. task - 5081474 Forward-Port-Of: odoo/enterprise#95294 Forward-Port-Of: odoo/enterprise#95013
The tax search screen now includes the configured tax amount in search results. This makes it easier for users to quickly find taxes by their percentage rate or fixed amount directly from the search bar.
Original PR description
This commit improves the usability of the tax search view by including the `amount` field. Users can filter taxes based on their configured percentage or amount directly from the search bar. task-5088050 Forward-Port-Of: odoo/odoo#227131
The point of sale closing process has been reorganized so order cancellation is handled in a separate, reusable step. This does not change the cashier experience, but it makes future customizations easier for businesses with specialized closing workflows.
Original PR description
In this commit: =============== - Extract the order cancellation logic during session closing into a new method `cancelOrders`. - This makes it possible to override the method in other modules if needed. Task: 4966693 Related Enterprise PR: https://github.com/odoo/enterprise/pull/95074
Employee-related version records now automatically track changes to most business-relevant fields across HR, payroll, contracts, attendance, sign, and localization modules. This improves auditability by making it easier to see what employee data changed, when it changed, and supporting stronger compliance records.
Original PR description
Most fields in hr.version represent business-relevant employee data that should be tracked to ensure a complete audit trail. This commit adds `tracking=True` by default on hr.version fields across community and enterprise modules. task-5022109 Forward-Port-Of: odoo/enterprise#92601
New tables added on the restaurant floor screen now receive a number after the highest existing table number instead of reusing gaps from deleted tables. This makes table numbering more predictable for staff and avoids confusion when tables have been removed.
Original PR description
Before this commit: ------------- - When adding a new table in the floor screen, the system reused missing number. - For example, if table 2 was deleted, the next added table would again be number 2. - Logic: find the minimum missing number starting from 1. After this commit: -------------------- - A new table in the floor screen always gets the next number after the biggest existing one. - For example, with tables [1, 3, 4], the next table becomes 5 (not 2). Task-5056800
Employee history records now track changes to more business-relevant fields by default. This strengthens audit trails for employee information across HR, attendance, and work entry areas, making it easier to review what changed and when.
Original PR description
Most fields in hr.version represent business-relevant employee data that should be tracked to ensure a complete audit trail. This commit adds `tracking=True` by default on hr.version fields across community and enterprise modules. task-5022109 Forward-Port-Of: odoo/odoo#223342
Payroll payslip line and worked days reports have been adjusted so users can no longer edit report data directly. This helps preserve payroll data accuracy while making the reports easier to navigate and search.
Original PR description
-In payslip line report, some fields can be edited, which should not be allowed. -Views have been adjusted to prevent the navigation from pivot to list view. -Search view has been modified for easier data reaching. Forward-Port-Of: odoo/enterprise#94284
The Documents screen can now show a larger fixed list of related items in its selector, so users can see all relevant options without needing an unavailable “Search more” action. This keeps existing behavior unchanged elsewhere while improving visibility in Documents.
Original PR description
In Documents, we have a static list of 9 items to show with this widget. As there is no "Search more" available, and we're in stable, this is the minimal change to not change behavior. Task-5075200 See related ENT PR (includes an integration test). Forward-Port-Of: odoo/odoo#227509 Forward-Port-Of: odoo/odoo#226608
Italian electronic invoice imports now use the document type from the XML without relying on whether the invoice is incoming or outgoing. This reduces duplicate document type records and helps bills and invoices be classified more consistently during import.
Original PR description
In the FatturaPA XML, the Document Type (Tipo Documento) doesn't indicate the direction of the journal entry. A `TD01` can be an `in_invoice` or `out_invoice` depending on whether the company is set to be the seller or the buyer. That's what we consider when importing invoices from the EDI. - saved the `l10n_it_document_type` from the imported bills' XML - removed the filter in the view - removed the `l10n_it_document_type` duplicates that just differed by `l10n_it_document_type.type` - updated the invoices to point to the original `l10n_it_document_type` if there were duplicates We will have to remove the field in `master` See odoo/upgrade#8484 Forward-Port-Of: odoo/odoo#228802 Forward-Port-Of: odoo/odoo#225425
The Documents details panel now shows the full list of available model labels instead of a shortened static list. This makes it easier for users to see their options immediately without guessing whether more choices exist.
Original PR description
As the list is static and there are only a few and searching for more is not supported, this enables to show all labels so that users don't have to guess what is available or not. Task-5075200 Forward-Port-Of: odoo/enterprise#94934 Forward-Port-Of: odoo/enterprise#94180
Repair orders now create their required quality checks much faster when a company has a very large number of quality control points. This reduces long waits or timeouts during repair creation, improving reliability for high-volume quality setups.
Original PR description
Description ----------- Creating a repair creates new `quality.check` based on `quality. point`s. When you have many matching points to explore, the `filtered_domain` can be pretty slow when…
Description ----------- Creating a repair creates new `quality.check` based on `quality. point`s. When you have many matching points to explore, the `filtered_domain` can be pretty slow when processing linear the records to compute the intersection between the all points and the points that should be associated with the repair. This commit rewrites `_create_quality_checks_for_repair` to use a `search` instead if necessary, to offload the intersection search in the database. We also split the ids to not inject a large list of ids in the query. Benchmark --------- For a database that will have 500k `quality.point` that satisfies the domain of `quality.point._get_domain`, the invocation of `_create_quality_checks_for_repair` for creating a Repair takes (excluding the `create` call time): | | Before | After | |---------|------------------|-------| | Timings | Timeout (15+min) | 1 min | Reference --------- opw-4980036 Forward-Port-Of: odoo/enterprise#95631 Forward-Port-Of: odoo/enterprise#91729
Resolved issues and error corrections
This fix prevents errors when assigning a previously created worksheet template after Field Service has been uninstalled and reinstalled. User-created worksheet templates are now removed during uninstall so invalid leftover templates do not disrupt task creation.
Original PR description
When user uninstalls and reinstalls `industry_fsm` the user created template is not removed causing `model_id` for the worksheet template turning `False` and raising a key error when indexing via `model_id`. **Replication steps:** * Install `industry_fsm` * Field Service>Configuration>Settings>Enable Worksheet templates * Configuration>Templates>Create New Template * Uninstall and reinstall `Field Service` * Field Service>New Task>Set worksheet template to the one you created `KeyError: False` **Solution:** * Unlink user created worksheet template on uninstallation of the application. **Sentry-6615576986** Forward-Port-Of: odoo/enterprise#86084
UAE invoice reports no longer show the amount column twice when tax-inclusive pricing is enabled. This makes printed proforma and tax invoices clearer and avoids confusing duplicate totals for customers and staff.
Original PR description
**Step to reproduce:** - install account module with localization "UAE" - go to Settings > Tax Included - create a invoice (make sure a tax is applied) - print any invoice (Proforma or Tax)…
**Step to reproduce:**
- install account module with localization "UAE"
- go to Settings > Tax Included
- create a invoice (make sure a tax is applied)
- print any invoice (Proforma or Tax)
**Observation:**
- the amount is being displayed twice in the Amount column.
**Cause:**
- A change was introduced in 18.0 to add additional column right after Amount
column, [1] in l10n_ae module
- Another commit [2] in saas-18.3 introduces same column in main account module
- hence we have two columns printing same information
**Fix:**
- Removed and fixed a faulty xpath from view, as after commit [2]
base layout provides same logic
[1] https://github.com/odoo/odoo/commit/fe68fa30b18f90411043fc6e2314fd376ddaed0c
[2] https://github.com/odoo/odoo/commit/1bf232c22f430d282aaadd858c5e61fed12f4da6
**Before:**
<img width="774" height="146" alt="image" src="https://github.com/user-attachments/assets/a9eb6af2-81b3-4989-bf6e-6676eafe10f8" />
**After:**
<img width="813" height="143" alt="image" src="https://github.com/user-attachments/assets/fb019516-de7d-4dd3-b7dd-3fd14322b031" />
opw-4976410
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#223382The self-ordering test now cancels only orders that are still in draft status, instead of trying to cancel every order. This prevents test failures when finalized or paid demo orders are present, helping keep validation runs stable.
Original PR description
Before this commit: = - Previously, `test_self_order_mobile` set all orders to cancel, causing errors with finalized orders (e.g., paid orders from demo data). After this commit: = - Only draft orders are cancelled, preventing errors and ensuring correct test behavior. Runboat Error: 224197 Forward-Port-Of: odoo/odoo#214935
A redundant navigation step was removed from a Point of Sale test flow to prevent intermittent test failures. This improves reliability of automated checks without changing business functionality or user workflows.
Original PR description
Before this commit: ================= The `test_draft_pos_order_linked_sale_order` test fails intermittently with a `psycopg2.ProgrammingError: no results to fetch`. This failure occurs when the…
Before this commit:
=================
The `test_draft_pos_order_linked_sale_order` test fails intermittently with a
`psycopg2.ProgrammingError: no results to fetch`. This failure occurs when the
browser tour navigates back to the backend.
After this commit:
=====================
The problematic navigation step is removed from the `PosSettleOrder5` tour,
stabilizing the test and preventing the runbot error.
Cause:
========
The `Chrome.clickMenuOption("Backend", { expectUnloadPage: true })` step
forces an immediate database flush (`self.cr.flush()`) during the test's
authentication phase.
This forced flush happens when the records are in an intermediate state (after
loading the Sale Order but before payment/validation). This specific
intermediate state, combined with the subsequent recomputation of computed
fields (like `qty_delivered` through `sale_mrp` and `sale_margin`), exposes an
underlying bug in Odoo's ORM cursor management, leading to the
`psycopg2.ProgrammingError`.
Since the backend navigation is not necessary for the test's assertion logic,
removing this step prevents the premature flush and resolves the failure.
Runbot Error: 226521
Task: 4974084
Forward-Port-Of: odoo/odoo#228799
Forward-Port-Of: odoo/odoo#228193Failed webpage scraping in the AI module is now recorded as a warning instead of an error. This avoids unnecessary error alerts while still informing users when a webpage cannot be processed.
Original PR description
Currently, an error can occur on unsuccessful scrapping of URL.
**Error:**
`Error scraping URL https://agenciavirtualpy.com: HTTPError('403 Client Error: Forbidden for url: https://agenciavirtualpy.com/')`
- Instead of logging an error, we log only warning during unsuccessful URL
scraping because it is not a blocking point in the code.
- On unsuccessful scraping, we log warnings [1] and raise a UserError [2] to
inform the user about the failed URL scraping. Therefore, we should log a
warning as the UserError is already present.
[1]: https://github.com/odoo/enterprise/blob/1930d045a5f40f33b0a391b90d5adaed0eb90083/ai/models/ai_agent.py#L258
[2]: https://github.com/odoo/enterprise/blob/1930d045a5f40f33b0a391b90d5adaed0eb90083/ai/models/ai_agent.py#L283-L285
sentry-6634525990
Forward-Port-Of: odoo/enterprise#94002Colombian Support Document Credit Notes now send product identification in the format expected by DIAN, even when barcode or UNSPSC data is available. This prevents avoidable document rejections and helps businesses submit compliant supplier credit notes more reliably.
Original PR description
Before this PR:
- Support Document Credit Notes sent barcode (scheme 010) when available, causing DIAN `NSAZ13` error and document rejection.
After this PR:
- Although a product has all of these 3 fields configured (barcode, UNSPSC, internal reference), still, for a Support Document Credit Note, the `cac:StandardItemIdentification` is always sent with the Internal Reference information ('999', 'Estándar de adopción del contribuyente').
- If internal reference is not configured, then barcode or UNSPSC code is sent with scheme ('999', 'Estándar de adopción del contribuyente').
task-4796034
Forward-Port-Of: odoo/enterprise#94140The POS payment screen now prevents repeated Validate clicks while an online payment order is still syncing. This avoids checkout errors on slow networks and helps cashiers complete online payments more reliably.
Original PR description
Currently, an error occurs when validating an online payment if the network is slow. **Steps to Reproduce:** 1) Install POS (with demo data) and the Demo Payment module. 2) Go to Payment Methods and…
Currently, an error occurs when validating an online payment if the network is slow.
**Steps to Reproduce:**
1) Install POS (with demo data) and the Demo Payment module.
2) Go to Payment Methods and create a new online payment method for any shop (e.g., a clothing shop). Set the Payment Provider to `Demo`.
3) Open a POS session for the clothing shop, select any product, and proceed to payment.
4) Open Inspect → Network tab, create a custom slow network profile(e.g., `set both download and upload speed to 1 KB/s`), and switch to that network.
5) Select the online payment method you just created and continuously click on Validate.
Error:
ValueError: Expected singleton: pos.order('p', 'o', 's', '.', 'o', 'r', 'd', 'e', 'r', '_', '4')
**Root Cause:**
When an online payment is validated, the `_isOrderValid` and `addNewPaymentLine` methods are called.
- With a slow network, the order ID is still temporary(e.g., e74a3369-7dcd-4234-b35e-04daa149ffe6) as the order is not synced completely, when the code at [1] is executed.
- Due to multiple clicks, `_isOrderValid` forces a call to `update_online_payments_data_with_server` at [2] before order is synced.
- This eventually passes the temporary ID to `get_and_set_online_payments_data` at [3], causing the issue.
**Fix:**
Prevent multiple clicks on Validate until the order is successfully synced.
[1]- https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/pos_online_payment/static/src/overrides/pos_overrides/components/payment_screen/payment_screen.js#L11-L17
[2]- https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/pos_online_payment/static/src/overrides/pos_overrides/components/payment_screen/payment_screen.js#L87
[3]- https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/pos_online_payment/static/src/overrides/pos_overrides/models/pos_store.js#L18-L26
**sentry-6849786792**
Forward-Port-Of: odoo/odoo#227967
Forward-Port-Of: odoo/odoo#225371This update resolves several user-facing issues across Odoo, including clearer payment error handling, correct website category breadcrumbs, safer signature submission, and fixes for localized document handling. These changes reduce confusion, prevent duplicate attendance actions, and improve reliability in day-to-day workflows.
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
This fix makes Turkish Nilvera e-invoice imports save progress after each document is processed. If an import times out or hits an error, already imported documents are kept instead of being rolled back, reducing the need to repeat work.
Original PR description
Following bcab79c0ba9b550726164d80a22b50e689a2789c we are no longer committing changes in `_l10n_tr_nilvera_get_documents` as we loop through documents. The idea behind having that commit inside the loop was to avoid having to rollback all changes if we timeout or an error occurs. This is especially important when importing the current maximum amount of documents (30). This commit restores that behavior. No Task ID. Forward-Port-Of: odoo/odoo#228616
This fix restores the correct VAT return status workflow for French, Danish, and Latvian reports. It helps ensure users see and use the proper return states when preparing VAT filings, reducing the risk of process errors.
Original PR description
*: fr, dk, lt In a3083e9db2534d649bfc2d02dac79582ebb6397a a new field `states_workflow` was added which determined the states possible for the return. The commit also incorrectly set the wrong value for this field in the XML for French, Danish and Latvian VAT returns. This fixes it. no task-id
Timesheet approvers with the right permissions can now see other users' timesheets on private project tasks they follow. This fixes a visibility gap so managers and approvers can review relevant time entries consistently in task views and reports.
Original PR description
**Issue:** Users with "All Timesheets" rights can't see other users’ timesheets on tasks they followed within private projects, even though they had access to the task itself. **Cause:** The security…
**Issue:** Users with "All Timesheets" rights can't see other users’ timesheets on tasks they followed within private projects, even though they had access to the task itself. **Cause:** The security rules for approvers (`timesheet_line_rule_approver` and `timesheet_analysis_report_approver`) only check project-level follower access and ignore task-level access. https://github.com/odoo/odoo/blob/48cfd650053c794a838c130605c4280351b4f5d9/addons/hr_timesheet/security/hr_timesheet_security.xml#L66-L76 https://github.com/odoo/odoo/blob/48cfd650053c794a838c130605c4280351b4f5d9/addons/hr_timesheet/security/hr_timesheet_security.xml#L108-L117 **Steps to reproduce:** 1. Create a private project (`privacy_visibility == 'followers'`) 2. Give another user (e.g., Marc Demo) "All Timesheets" rights and only "User" project access 3. Add Marc Demo as a follower of a task in that private project 4. Have another user log time on that task 5. Log in as Marc Demo Marc cannot see the other user's timesheets, neither on the task form nor in reporting. opw-5022877 Forward-Port-Of: odoo/odoo#226948 Forward-Port-Of: odoo/odoo#224025
This fix swaps the placement of the “exempt” and “exempt imports” fields in the Mexican DIOT report so each value appears in the legally expected column. The amounts were already calculated correctly, but the corrected layout helps avoid confusion and reporting mistakes.
Original PR description
Description of the issue/feature this PR addresses: The description of the columns “exempt imports” and “exempt” is somewhat ambiguous, so when developing the diot, there was a small error in the order of the columns. The values are calculated correctly, but columns 49 and 50 were inadvertently swapped. Current behavior before PR: “exempt” is column 49 “exempt imports” is column 50 Desired behavior after PR is merged: “exempt” is column 50 “exempt imports” is column 49 Task-id: 5096808 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228882 Forward-Port-Of: odoo/odoo#228303
Dark mode display issues were corrected in Point of Sale and appointment screens. Icons and text now use colors that remain readable across light and dark themes, making the interface easier to use for staff.
Original PR description
In this commit: ------------------- - Added a dark mode color for the star icon. - Changed the text color to white in light mode, which is reflected as black in dark mode. This fixes the issue of the text not being properly visible in dark mode. task:4943078 Forward-Port-Of: odoo/enterprise#93993
The Mexican DIOT report export now places the “exempt imports” and “exempt” values in the correct columns. This prevents confusion when businesses submit or review the downloaded TXT file, while the underlying calculated amounts remain unchanged.
Original PR description
The description of the columns “exempt imports” and “exempt” is somewhat ambiguous, so when developing the diot, there was a small error in the order of the columns. The values are calculated correctly, but columns 49 and 50 were inadvertently swapped. This Pr changes the order of the columns in the downloadable file (txt) and corrects the tests due to the change. Task-id: 5096808 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#95679 Forward-Port-Of: odoo/enterprise#95383
Project users can no longer create new task stages from the task list when they do not have the right permissions. This keeps project workflows controlled by project managers and prevents accidental or unauthorized changes to task stages.
Original PR description
Steps to reproduce: - Go to a project - Open the task list view - Select a task - In the `Stage` field, attempt to create a new stage Issue: - Project users were able to create new task stages from…
Steps to reproduce: - Go to a project - Open the task list view - Select a task - In the `Stage` field, attempt to create a new stage Issue: - Project users were able to create new task stages from the task list view, despite not having the required permissions. Cause: - The `_default_user_id` method assigns the current user as the owner `user_id` of a new stage only when `default_project_id` is not present in the context. As a result, the method returned the current user’s ID, unintentionally making them the owner of the stage. This allowed project users to bypass the intended access rules and create new stages. Solution: - Use the `no_create` option for users outside the project manager group to prevent them from creating new stages. - Updated the `stage_id` field in the task list view to explicitly include `default_project_id` in the context, ensuring proper access control of that stage. task-4628666 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228907 Forward-Port-Of: odoo/odoo#206407
Fixes an issue where website tab image descriptions could disappear when a slide title was formatted as a paragraph or placed inside another text style. This ensures editors can use the “Active only” description setting without losing visible content on the page.
Original PR description
After the new options for s_tabs_images were added in [1], it wouldn't display the active description if the title was inside of another tag. Steps to see the issue: - Open website and start editing - Drop the s_tabs_images snippet and click on the first slide title - Change the Descriptions option from "All items" to "Active only" - Select the title and change the font style from "Normal" to "Paragraph" => Observe that the description isn't displayed [1]: https://github.com/odoo/odoo/commit/e2e26bb8ad239fe13c504f0f811eab9cae1fb376
Accounting imports now avoid linking invoice lines to unrelated products when the imported product name is very short, such as “-” or “a”. This helps prevent incorrect product assignments on documents created from XML or EDI imports, improving data accuracy for accounting teams.
Original PR description
hen resolving a product in _retrieve_product, the code searched by barcode, default_code, and then by name using both exact and ilike domains. For very short item names coming from imports (e.g., “-”, “A-1”, “0001”), the ilike fallback could match unrelated products whose names merely contain that short string. this led to incorrect product linkage on created documents (e.g., EDI-imported invoices). discussed with: Christophe (chkl) Steps to reproudce: Accounting -> Invoices upload an XML with a product name liek `-` or `a` See the product attched to the invoice line. opw-5003482 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225143
Importing certain electronic invoice files could fail when a base quantity was explicitly set to zero. This fix prevents that error so affected customer invoices can be imported successfully instead of being blocked.
Original PR description
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Customers / Invoices" - Import a UBL file having a value of 0 for a `<cbc:BaseQuantity>` element **Issue:** The import fails due to a division by 0 at: `price_unit = (net_price_unit + rebate) / basis_qty` **Cause:** "basis_qty" is retrieved as followed: `basis_qty = float(self._find_value(xpath_dict['basis_qty'], tree) or 1)` If the element is not defined, it will fall back on 1. But if the element exists with a value of 0, the "_find_value" method will retrieve the string "0" which is not False and will not fall back on 1. Then it will become `0.0` once converted to float. opw-5062985 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227446
This fixes an issue where email signature image styling could be damaged when preparing messages for Outlook. Signatures and formatted email content should now appear more consistently for recipients, especially when resized images are used.
Original PR description
Problem: `_hideForOutlook` breaks the last style when appending `mso-hide: all;` if the style string does not end with `;`. Example: `width: 100%` → `width: 100% mso-hide: all;` Solution: Ensure the new attribute is appended correctly at the end of the styles, regardless of whether the last style ends with `;`. Note: The problem might be only observed on `18.4` because the composer doesn't use the user signature before `18.4`. Steps to reproduce in 18.4: 1. Open "My Profile". 2. Add an image to "email signature" with reduced scaling (25%, 50%). 3. Open any record with chatter (task, SO, invoice, etc.). 4. Type a message in chatter and click "Send". 5. Click "Open Full Compositor" and send a message from the email compositor. 6. Open the runbot's MailHog and observe the differences between the two emails. opw-5046573 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224985
Payment terminal messages printed at the bottom of POS receipts now use the correct font sizing. This makes the printed text larger and more consistent with what staff see on screen, improving receipt readability for customers and cashiers.
Original PR description
When you pay with a payment terminal, it can produce some text which gets appended to the bottom of the POS receipt. Before this commit, this text appears too small to be legible when printed on a…
When you pay with a payment terminal, it can produce some text which gets appended to the bottom of the POS receipt. Before this commit, this text appears too small to be legible when printed on a receipt printer. This is because the font size styling was in the wrong place, and in the UI it fell back to bootstrap's CSS which makes it fairly large, but html2canvas renders it very small. After this commit, the problem is fixed by moving the font size styling to the correct place to apply to the text. In the UI, the text is actually slightly smaller than before, but when printed it is bigger and consistent with the UI. Before/After (UI): <img width="346" height="325" alt="image" src="https://github.com/user-attachments/assets/0a9dceb3-e224-473f-b02f-ff94b81b0a8d" /> <img width="349" height="319" alt="image" src="https://github.com/user-attachments/assets/b096172a-4a98-4249-a5d4-00c8a46ab4d0" /> Before/After (Receipt): <img width="513" height="503" alt="image" src="https://github.com/user-attachments/assets/e1d6ba27-1ff6-4853-b617-1c010857f1eb" /> <img width="516" height="528" alt="image" src="https://github.com/user-attachments/assets/82cb2431-707f-40c7-a9a5-f439d3934e16" /> task-5116506 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228775
Customers renting products online will again see stock availability warnings during checkout. This helps prevent confusion and reduces the chance of orders being placed when rental stock may not be available.
Original PR description
Introduced by 151349aeaf899a3b70534a0120a5f49882981d53, the `_set_shop_warning_stock` method was modified and is now supposed to return the applied warning.
The Time Off calendar now shows the selected employee's working schedule instead of the schedule of the person viewing it. This helps managers and HR staff accurately review availability and days off when checking another employee's time off.
Original PR description
Steps to reproduce: - In the Employee app, select an employee with a different working schedule than yours - Click on the "Time Off" smartbutton - Switch from Kanban to Calendar view - The displayed working schedule is yours and not the employee's (easier to see if you and the employee have different days off) Reason: The employee_id field in the context used by the Python method was null instead of an ID, which caused the Python method to default to not use the employee's working schedule but the working schedule of the user viewing it. How it was fixed: By using a different field already present in the context, the employee's ID is correctly retrieved and used to display the calendar. Task ID: 4987732 Forward-Port-Of: odoo/odoo#225839
Shiprocket Cash on Delivery shipments now include coupon discounts in the discount amount sent to Shiprocket. This helps ensure COD shipment values match the customer’s discounted order total, including taxes where relevant.
Original PR description
Issue ----- When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons. Steps to reproduce ----- - Set an Indian…
Issue
-----
When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons.
Steps to reproduce
-----
- Set an Indian company up (with valid address and some dummy mail & phone)
- Create a customer "IN Cust" (with valid address and some dummy mail & phone)
- Create a product "IN Prod"
- Sale price: 1000 INR
- Weight: 100g
- Set some reference, eg "INPROD"
- Create a Shiprocket delivery method
- Payment Method: COD
- Set some "Shiprocket Channel"
- Enable Debug requests
- In settings, enable "Promotions, Loyalty & Gift Card"
- Go to Sales > Products > Discount & Loyalty
- Create a new program
- Name: 50% off
- Program Type: Coupons
- Change the existing reward to 50% discount on order
- Generate some coupon
- Copy the code of the generated coupon
- Create a SO our product and customer
- Use the coupon code & apply the 50% discount
- Add shipping
- Shiprocket COD
- Get rate
- Confirm the SO
- Go to the picking & validate it
- Open logs (Settings/Technical/Database Structure/Logging)
- Open the "shiprocket_request_external/shipments/create/forward-shipment" log
--> total_discount is 0
Cause
-----
The problem comes from
https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L301
There are 2 issues here.
The first and most important one is how we find the discount lines.
https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L320
Discounts from coupons don't use the `sale_discount_product_id`. We can use the `_can_be_invoiced_alone` function to find both regular and loyalty discounts
https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/sale/models/sale_order_line.py#L1033-L1041
def _can_be_invoiced_alone(self):
""" Whether a given line is meaningful to invoice alone.
It is generally meaningless/confusing or even wrong to invoice some specific SOlines
(delivery, discounts, rewards, ...) without others, unless they are the only left to invoice
in the SO.
"""
self.ensure_one()
return self.product_id.id != self.company_id.sale_discount_product_id.id
https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/sale_loyalty/models/sale_order_line.py#L50-L51
def _can_be_invoiced_alone(self):
return super()._can_be_invoiced_alone() and not self.is_reward_line
We just have to be careful not to accidentally include delivery fees because of
https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/delivery/models/sale_order_line.py#L18-L19
def _can_be_invoiced_alone(self):
return super()._can_be_invoiced_alone() and not self.is_delivery
The second issue is that we use the untaxed discount amount.
https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L321
This leads to an incoherent total amount, since the tax is computed on the products' full prices. We should instead be forwarding the total discount value (with tax included to offset the taxes applied on the full product price).
-----
Community PR:
https://github.com/odoo/odoo/pull/223517
Ticket:
opw-4755357
Forward-Port-Of: odoo/enterprise#95435
Forward-Port-Of: odoo/enterprise#92310Fixed an issue in Brazilian electronic invoicing that could cause an error when users confirmed several invoices at the same time. This makes bulk invoice processing more reliable and helps avoid interruptions during invoicing workflows.
Original PR description
opw-5107516 Forward-Port-Of: odoo/enterprise#95532 Forward-Port-Of: odoo/enterprise#95511
Preparation ticket printing now handles order notes saved in different formats, so tickets print reliably across multiple kitchen printers. This prevents a failure where the second printer could stop with an error when an order note was included.
Original PR description
Normalize getStrNotes() to handle multiple note formats (JSON array string, array, plain string) and avoid crashes when printing preparation tickets to multiple printers. Steps to reproduce:…
Normalize getStrNotes() to handle multiple note formats (JSON array string, array, plain string) and avoid crashes when printing preparation tickets to multiple printers.
Steps to reproduce:
-------------------
* Configure two preparation printers for a pos_restaurant with food categorie.
* Create an order with a note in that restaurant.
* Send the order to the kitchen.
> Observation:
The second printer fails to print the ticket with an (uncaught) JSON parse error (Unexpected token), while the first prints correctly.
Why the fix:
------------
`getStrNotes()` assumed notes were always JSON strings like [{"text":"...","colorIndex":0}]. In practice, notes can be plain strings or already-parsed arrays depending on the update path and last printed changes.
The function now:
- returns joined texts for arrays,
- tries to parse JSON strings and joins texts if it’s an array,
- falls back to the raw string if parsing fails. This makes note rendering stable across printers and prevents the error, ensuring tickets are printed consistently.
opw-5029870
Forward-Port-Of: odoo/odoo#227430Invoice Analysis now calculates product quantity, average price, margin, and inventory value correctly when invoice lines use product packaging. This prevents misleading sales and profitability reporting after the unit-of-measure packaging changes.
Original PR description
#### Issue: Quantity, average price, margin and inventory value are wrong in Invoice analysis for invoice lines using packagings. #### Step to reproduce: - Choose a product - Make sure it has a cost,…
#### Issue: Quantity, average price, margin and inventory value are wrong in Invoice analysis for invoice lines using packagings. #### Step to reproduce: - Choose a product - Make sure it has a cost, and it differs from sales price - In the sales sheet, add a packaging - Create a sale order - Add the product using the package - Confirm - Go to delivery, validate - Back to sale order create an invoice and confirm it - Go to "Invoice Analysis" - Go to Pivot View - In "Measures" select: - Average Price, - Inventory Value, - Margin, - Product Quantity - In "Total" select: - Product #### Current behavior: - Those fields display wrong values as they were miscalculated: - Average Price line_balance / number_of_packages * number_of_unit_in_package - Inventory Values account_currency_table.rate * number_of_packages / number_of_unit_in_package - Margin margin_on_one_unit * number_of_packages / number_of_unit_in_package - Product Quantity number_of_packages / number_of_unit_in_package #### Expected behavior: - These fields should be right: - Average Price line_balance / number_of_packages / number_of_unit_in_package - Inventory Values account_currency_table.rate * number_of_packages * number_of_unit_in_package - Margin margin_on_one_unit * number_of_packages * number_of_unit_in_package - Product Quantity number_of_packages * number_of_unit_in_package #### Cause of the issue: - As per the refactor of the UoM and packaging, the uom factor field is now the mathematical inverse of the previous uom factor field. This model wasn't updated and used wrong formulas. opw-5031495 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227489
The barcode kanban view now only displays existing inventory quantity records instead of allowing new ones to be created from that screen. This prevents accidental stock record creation and keeps inventory data cleaner when users scan or enter product barcodes.
Original PR description
Steps to reproduce: - Scan or type product barcode - Navigate to Kanban View Problem: - New `stock.quants` are not supposed to be created from `stock.quant.kanban.barcode`, its only to supposed to show existing ones. Forward-Port-Of: odoo/enterprise#95487 Forward-Port-Of: odoo/enterprise#94802
This fix prevents hidden editor markers in Knowledge comments from multiplying and causing errors while editing. It improves reliability when users navigate or interact with comments in Knowledge articles, reducing the risk of unexpected crashes.
Original PR description
Context: `\ufeff` characters are used in the editor to handle how the cursor behaves when using arrow keys. In the case of knowledge comments, we want to have 2 cursor positions at each comment…
Context: `\ufeff` characters are used in the editor to handle how the cursor behaves when using arrow keys. In the case of knowledge comments, we want to have 2 cursor positions at each comment boundary. I.e.: at the first beacon, we want a cursor position before the anchor (outside of the comment), and one after (inside of the comment). Issue: Since this [commit], empty links receive 2 `zwnbsp` nodes to allow the user to type inside, instead of 1 previously. However knowledge comments beacons are not editable and only need one `zwnbsp`, since we never want to type inside. Furthermore, having 2 and nothing in between them would cause an issue when their content is normalized, which may lead to a traceback: - `link_plugin` executes `selection.anchorNode.parentNode.normalize();` which merges 2 FEFF together. However the function `isZwnbsp` does return true for one text node with 2 FEFF characters. This means that during the next "add feffs" phase, new text nodes with one `FEFF` characters will be added, creating a growing loop generating new `FEFF` at every normalization phase. - Furthermore, merging the nodes in one text node may not result in a new step in some cases, which prevent the `history_plugin` from registering the new node in time in its `nodeMap`, which may lead to a serialization traceback. Resolution: This commit stops using the deprecated `padLinkWithZwnbsp` method to ensure that there are 3 `zwnbsp` characters for each beacon: 2 around it, and one inside. [commit]: https://github.com/odoo/odoo/commit/f0eaeb6 task-5046068 Forward-Port-Of: odoo/enterprise#95550
This fix makes coupon and global discount lines identifiable on sales orders so they are handled correctly by related processes such as Shiprocket cash-on-delivery shipments. It also prevents discount line values from being reset when quantities change, helping ensure order totals and external shipment requests reflect the real discounted amount.
Original PR description
Issue ----- When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons. Steps to reproduce ----- - Set an Indian…
Issue ----- When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons. Steps to reproduce ----- - Set an Indian company up (with valid address and some dummy mail & phone) - Create a customer "IN Cust" (with valid address and some dummy mail & phone) - Create a product "IN Prod" - Sale price: 1000 INR - Weight: 100g - Set some reference, eg "INPROD" - Create a Shiprocket delivery method - Payment Method: COD - Set some "Shiprocket Channel" - Enable Debug requests - In settings, enable "Promotions, Loyalty & Gift Card" - Go to Sales > Products > Discount & Loyalty - Create a new program - Name: 50% off - Program Type: Coupons - Change the existing reward to 50% discount on order - Generate some coupon - Copy the code to the generated coupon - Create a SO our product and customer - Use the coupon code & apply the 50% discount - Add shipping - Shiprocket COD - Get rate - Confirm the SO - Go to the picking & validate it - Open logs (Settings/Technical/Database Structure/Logging) - Open the "shiprocket_request_external/shipments/create/forward-shipment" log --> total_discount is 0 Cause ----- The problem comes from https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L301 There are 2 issues here. The first and most important one is how we find the discount lines. https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L320 Discounts from coupons don't use the `sale_discount_product_id`, we'll have to define a new function to override in `sale_loyalty` for this. The second issue is that we use the untaxed discount amount. https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L321 This leads to an incoherent total amount, since the tax is computed on the products' full prices. We should instead be forwarding the total discount value (with tax included to offset the taxes applied on the full product price). ----- Enterprise PR: https://github.com/odoo/enterprise/pull/92310 Ticket: opw-4755357 Forward-Port-Of: odoo/odoo#228375 Forward-Port-Of: odoo/odoo#223517
Point of Sale receipts for delivery orders no longer show the customer's name and address twice. This keeps printed receipts cleaner and avoids confusion for staff and customers.
Original PR description
Steps to reproduce: - Open the restaurant configuration. - Select the preset as Delivery and choose a customer with an address. - Validate the order and print the receipt. Issue: - The customer’s name and address appear twice on the receipt. Fix: - Removed the duplicate name and address from the receipt header. task-5097764
This fixes an issue in Sales Commission reporting so grouped report results can be formatted as needed instead of being blocked by a read-only setting. It helps ensure commission and achievement reports display reliable grouped information for business review.
Original PR description
runbot-89585061
This fixes an issue where online shoppers could receive the wrong pricelist after signing in or creating an account without an address. Website sales now keep using the shopper's GeoIP country when recalculating pricing, helping ensure country-specific pricing rules are applied correctly.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have GeoIP enabled/mocked; 2. have at least 2 pricelists available in eCommerce; 3. have all pricelists restricted to a certain country group; 4. have the 1st…
Versions -------- - 17.0+ Steps ----- 1. Have GeoIP enabled/mocked; 2. have at least 2 pricelists available in eCommerce; 3. have all pricelists restricted to a certain country group; 4. have the 1st pricelist be incompatible w/ the current GeoIP location; 5. open a cart as a public user; 6. check pricelist in back-end (should be correct); 7. go to "Sign In" & create a new portal account without address; 8. check pricelist in back-end (should still be correct); 9. go back to cart with portal account; 10. check pricelist in back-end. Issue ----- The first pricelist is assigned to the order, which shouldn't be compatibly with the partner's current GeoIP location. Cause ----- The pricelist is recomputed on changing the `partner_id` on a sale order. Commit 6504c0624b990 added a check on the `country_code` context value when retrieving the `property_product_pricelist` for a partner. This context value is currently not getting added during `_compute_pricelist_id`. Because all pricelists are restricted to a country group, when the pricelist gets recomputed on `partner_id` change, there's no location-independent pricelist to fall back on, which is why the first pricelist is used regardless of country restrictions. Solution -------- Add a `_compute_pricelist_id` override which adds the current GeoIP country code to the context when computing the field for website orders. opw-5000198 Forward-Port-Of: odoo/odoo#228909 Forward-Port-Of: odoo/odoo#225582
Rating records now hide placeholder words like “by” and “on” when there is no publisher comment or related information to show. This removes confusing leftover text and makes rating screens clearer for users reviewing feedback.
Original PR description
Steps to Reproduce: 1. Navigate to a rating record form view 2. View ratings without publisher comments 3. Notice confusing 'by on' text fragments appearing Current Behavior: - 'by on' text shows even when there's no comment or publisher information - Text fragments remain visible after comments are removed Expected Behavior: - 'by' and 'on' text should only appear when there's actual content to display - Proper conditional visibility based on comment presence Changes Made: - Added conditional visibility to rating form view text elements - Improved XML structure for better maintainability - Fixed persistent text display issues when comments are removed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225300
Manufacturing planning now handles extremely small operation or work order durations safely. This prevents scheduling failures that could block production planning when durations are entered below the expected minimum precision.
Original PR description
Operation & Workorder duration is a float with 2 decimal digits to be expressed in minutes, meaning minimal duration is 1sec. However one can encounter numbers like 0.001, 0.00001, ... This can lead to : AttributeError: 'NoneType' object has no attribute 'astimezone' in function _get_first_available_slot task: 5090338 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228760 Forward-Port-Of: odoo/odoo#227253
The ESG Database menu no longer offers a direct create option, reducing the chance that users expect unsupported automatic data imports. Users can still create database entries from within emission factors when they need to manually classify emission factors.
Original PR description
Before this commit, when the user goes to Database menu inside ESG app, the user can create a database if he wants. However, when he creates a database, he might think it can add the link of the database to automatically fetch the data, but this system is not implemented because each database has its own formatting. This commit disables the create action inside that menu to avoid confusing the user. However, he can still create a database inside a emission factor if he wants to classify his emission factors manually created. task-5117594
Event registration confirmation emails now keep QR codes at the correct height when templates are previewed or edited. This prevents distorted QR codes, helping attendees reliably scan their event tickets.
Original PR description
### Steps to reproduce: 1. Set up an event registration with atleast 1 attendee. 2. Go to email templates and search for "Event: Registration Confirmation". (or any with QR code in it) 3. Check the preview of the email template. 4. Edit any text inside the template and check the Preview again. (QR code stop taking the proper height) ### Issue: During the rendering of the email template, the QR code image html is changing provoking the QR to not have the proper aspect ratio and look stretched. ### Fix: We can make sure we're always taking the 100% height of the container by adding a style attribute to the image tag, thus not losing the aspect ratio of the QR code. opw-4976893 Forward-Port-Of: odoo/odoo#223774
This fixes a restaurant Point of Sale issue where added items could fail to sync before being sent to the kitchen printer or preparation display. It helps prevent outdated order errors and keeps table orders consistent between the register and server.
Original PR description
Before this commit, if an order had no changes and no preparation display was active, adding items to the order in the restaurant PoS and then returning to the tables would sync the order to the server and mark it as not dirty. As a result, reopening the order and clicking the order button to send it to the preparation display or printer would not sync the updated changes. This caused inconsistencies and errors. Steps to reproduce: 1. Open a table, place an order, and send it to the kitchen printer 2. Add more products but instead of placing the order, go back 3. Re-enter the table, place the order, and send it 4. When placing another order, the error "Order Outdated" appears This commit fixes the syncing logic to ensure that last changes are properly synced, avoiding the "Order Outdated" error. opw-5097566 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228680 Forward-Port-Of: odoo/odoo#227824
Australian Taxable Payments Annual Reports now exclude unrelated customer payments from the Gross Paid amount. This keeps reported supplier payment totals accurate and helps avoid overstating taxable payments.
Original PR description
Customer payment shoudn't be included in the TPAR report Steps: - Unarchive 10% TPAR tax - Make a bill for a partner X, set 10% TPAR tax on the invoice line and confirm - Create and confirm a customer payment for partner X - Go to 'Taxable Payments Annual Reports (TPAR)' -> The column 'Gross Paid' includes the customer payment Before this commit, we took all line from bank or cash journal to calculate the gross paid value. With this commit, we also restrict the lines to include only the one with 'asset_current' or 'liablility_current' account type. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/5045457) opw-5045457 Forward-Port-Of: odoo/enterprise#95592 Forward-Port-Of: odoo/enterprise#95029
This fix prevents Mexican electronic invoices with external trade details from failing when the USD currency has been deactivated. Businesses can continue confirming and sending affected CFDI invoices without needing to reactivate USD solely to avoid this error.
Original PR description
**Steps to Reproduce:** 1. Install `l10n_mx_edi_extended` module without demo data. 2. Set company's country to "Mexico" and switch Fiscal Localization. 3. Deactivate USD currency. 4. Configure CFDI…
**Steps to Reproduce:** 1. Install `l10n_mx_edi_extended` module without demo data. 2. Set company's country to "Mexico" and switch Fiscal Localization. 3. Deactivate USD currency. 4. Configure CFDI Certificate and activate Testing mode in PAC. 5. Create a new product with "UNSPSC Category". 6. Create an invoice with CFDI to the public and "Definitive" in External Trade. 7. Confirm and send the invoice. **Sample certificate:** Certificate file: https://drive.google.com/file/d/1kklNGeRtR08erxWRPfIdeiwheDibcB8M/view?usp=drive_link Private key file: https://drive.google.com/file/d/1VJnKVo1doA4cCYPeZBHXKT4JGkbHhOhk/view?usp=drive_link Private key password: 12345678a **Error:** `ValueError - Expected singleton: res.currency()` **Cause:** When sending the invoice, the system attempts to retrieve the USD currency to compute exchange rates. Since the search only considers active currencies, this results in no record being returned, which raises an error in further computation. **Fix:** This commit handles the case when USD currency is deactivated. sentry-6860601127 Forward-Port-Of: odoo/enterprise#94179
Planning views now show a valid allocated percentage for employees on flexible or fully flexible work schedules when grouped by resource and role. This avoids confusing display errors and gives managers clearer staffing information.
Original PR description
Steps to reproduce: ==== - Install the Planning module. - Go to Planning and apply two level group by: Resources ⇒ Role. - Ensure some employees (e.g., AKA Foster) are assigned a 'Flexible Hours'…
Steps to reproduce: ==== - Install the Planning module. - Go to Planning and apply two level group by: Resources ⇒ Role. - Ensure some employees (e.g., AKA Foster) are assigned a 'Flexible Hours' work schedule. Issue: === When grouping by Resource ⇒ Role, employees with flexible hours display 'NaN' instead of a valid allocated percentage. Cause: ==== Flexible and fully flexible resources do not have predefined work intervals in their schedules. The calculation previously relied on work_intervals to compute 'workHours', which is undefined for flexible users, resulting in 'NaN' in the UI. Fix: === The issue is resolved by using avg_hours instead of work_intervals for flexible and fully flexible resources. Additionally, the necessary change has been added to handle fully flexible schedules as well. Since both flexible and fully flexible resources lack scheduled intervals, their avg_hours serve as a reliable value for computing 'workHours', preventing the display of NaN. task-4968436
This fix ensures product carousel indicators on website shop pages are correctly centered when a mobile page first loads. It prevents a visual alignment issue that could make the storefront look less polished to shoppers.
Original PR description
Since the introduction of interactions with [22e777c] in 18.2, the indicators on the CarouselProduct interaction were wrongly computed on mobile: on page load, the indicators appeared on the left instead of centered. This is because an explicit `updateContent()` has to be done at the end of the `updateJustifyContent` method, since it modifies a parameter that impacts the `dynamicContent`. We also take the opportunity to simplify the code of `updateJustifyContent`, which became needlessly complicated after [22e777c]. [22e777c]: https://github.com/odoo/odoo/commit/22e777c046521f3f89b62caa5876680beb7f5aba task-5080057 Forward-Port-Of: odoo/odoo#226632
This fix makes an automated test for free shipping discounts in the online shop more reliable. It helps prevent random test failures, supporting smoother maintenance and more dependable releases without changing customer-facing behavior.
Original PR description
This commit fixes non-deterministic `website_sale_loyalty` tour, which was randomly failing because of the interaction's life cycle behavior where our tour runs too fast before even handlers are attached in interaction. error-229963 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Website building blocks now behave correctly for visitors and editors who navigate with a keyboard. Floating blocks scroll properly in both directions, category showcase cards expand when tabbed through, and focus states now show the same visual feedback as mouse hover effects.
Original PR description
Snippets `.s_floating_blocks` added in [493ea3e] and `.s_ecomm_categories_showcase` added in [efe5de2] work nicely on mobile and with a mouse, but have some shortcomings when it comes to keyboard navigation: - Floating blocks are properly scrolled when using "Tab", but failed to scroll back up when pressing "Shift+Tab". - Categories showcase did not expand when going through the cards with "Tab". Additionnally, [9ae02d8] made the snippet previews focusable, and the hover effects of both those snippets where not rendered on focus. This is now the case. [493ea3e]: https://github.com/odoo/odoo/commit/493ea3e43a18e8ad5e33a165f760851ae26a70e9 [efe5de2]: https://github.com/odoo/odoo/commit/efe5de268e5914723986c045289e6db22c8c07a9 [9ae02d8]: https://github.com/odoo/odoo/commit/9ae02d80894d4043e49d8e2cad068f8018e6f113
Discuss calls now handle startup information more reliably so a user's microphone is less likely to appear or become muted incorrectly when joining. Warning indicators are also shown more consistently during connection recovery, helping users understand call issues sooner.
Original PR description
This commit fixes: - the SFU could send outdated information about our own session during the initialisation of the connection. This can lead to the microphone being muted when joining a call if the updates occur when the user rtc session is marked as mute when querying the audio stream. - the warning indicator was hidden if the connection state was undefined this could lead to a missing warning during some recovery steps when session data is reset. Forward-Port-Of: odoo/odoo#228811 Forward-Port-Of: odoo/odoo#228601
The website SEO tool now handles redirected icon links, such as social media links, more accurately and avoids showing blank spaces where link icons should appear. This reduces false broken-link warnings while still detecting real missing or invalid links, helping users trust SEO checks and maintain cleaner pages.
Original PR description
In SEO, check for broken links there are some empty spaces before the link for icon links (e.g. social media snippet). <hr/> Before this commit, the SEO dialog flagged the "social media" snippet as a broken link because it followed the redirect to the "YouTube consent" page and the browser stopped the call. After this commit, we first run a "normal fetch" so internal redirects still reach their final page, then we try a "manual" redirect only when the browser blocks the call, counting "opaqueredirect" answers as valid. This keeps "controller proxies" green while we still report the real "4xx" errors. This commit also slightly improves the performance of broken link detection.
This fixes Swedish localization tax setup so non-EU goods purchase VAT with a non-zero amount is marked as deductible input VAT. It helps Swedish companies report VAT more accurately and reduces the risk of incorrect tax declarations.
Original PR description
The taxes "EX G" (VAT Purchase of goods outside EU) with a non-zero amount should have the tag se_48 (Input VAT to be deducted). opw-4916405
Rental orders can now be confirmed even if the assigned resource is unavailable, as long as rental-to-shift synchronization is not enabled. This prevents unnecessary blocking for businesses that do not use shift planning sync with rentals.
Original PR description
Step to reproduce: - Set up a role with a resource not available this week - Not activate the option to sync Rental order - Shift - Set up a rental-service product, with an auto-plan for this role Issue: - Rental orders could not be confirmed from the portal or the rental app if the required resource was unavailable, even when the `sync_shift_rental` option was not disabled. Cause: - The logic in `_planning_slot_vals_list_per_sol` treated all unavailable resources as problematic, without checking whether the shift synchronization was enabled (`sync_shift_rental`), resulting in unnecessary blocking of the order confirmation. Solution: - Added a condition to check if `sync_shift_rental` is enabled before marking a service as problematic. This allows rental orders to be confirmed when shift sync is disabled. task-5072920 Forward-Port-Of: odoo/enterprise#94176
This fix ensures certain Swedish purchase taxes for goods bought outside the EU are correctly marked as deductible input VAT when the tax amount is not zero. It helps keep Swedish VAT reporting accurate and restores related automated checks.
Original PR description
The taxes "EX G" (VAT Purchase of goods outside EU) with a non-zero amount should have the tag se_48 (Input VAT to be deducted). This PR fixes the tests that were broken because of it: odoo/odoo#227513 opw-4916405
When a signer is no longer assigned to a person, their previous profile picture is now removed from the signing template sidebar. This prevents outdated avatars from appearing and keeps signer information accurate for users preparing documents.
Original PR description
Issue: - In the template iframe view, when editing a signer’s settings, removing the "Assign To" field did not clear the profile picture. - As a result, the previous avatar remained visible in the sidebar even though no user was assigned. Fix: - Updated `updateRoleNameAndAvatar` to reset the `profilePic` state to an empty string when `assignTo` is removed. Impact: - The profile picture is now correctly hidden when no signer is assigned, ensuring the sidebar always reflects the current state of the signer. Steps to reproduce: 1. Open the signer settings dialog in the template view. 2. Clear the `Assign To` field. 3. Save the dialog.