Friday, January 30, 2026
29 changes · saas-18.3
Resolved issues and error corrections
This update resolves an issue where dynamic product snippets would cause horizontal scrolling when the content width was set to 'max'. The fix repositions the navigation buttons to prevent this, ensuring a consistent and user-friendly experience across larger devices. This improves the visual presentation of product listings.
Original PR description
Steps to reproduce: 1. Drag and drop the dynamic products snippet. 2. Select it and change the content width to **max**. Issue: When the content width is set to **max**, an unnecessary horizontal scroll appears. Reason: The issue occurs because the `previous` and `next` navigation buttons were not properly positioned. Fix: For devices larger than "mobile", the `previous` and `next` buttons are re-positioned, horizontally inward by "**50%**" of their own width with the help of `transform` property. This keeps the controls within the visible area and prevents horizontal scrolling. task-5090468 Before: <img width="1915" height="966" alt="image" src="https://github.com/user-attachments/assets/0c20d0b6-32cc-477b-8403-55bb0d372d8d" /> After: <img width="1920" height="963" alt="image" src="https://github.com/user-attachments/assets/4194b0f1-f3ad-4818-aa6f-2fda4561d2c7" /> Forward-Port-Of: odoo/odoo#237876
This update corrects a bug where archived journals with outbound payment methods were still appearing as selectable options when creating expense reports. The fix ensures that only active journals are considered, preventing users from selecting outdated payment methods and improving data accuracy. This resolves an issue that could have led to incorrect expense reporting.
Original PR description
Steps to Reproduce: 1. Go to Accounting > Configuration > Journals 2. Archive a Journal with outgoing payment method 3. Go to Expenses > Create an Expense paid by company 4. Note that payment methods…
Steps to Reproduce:
1. Go to Accounting > Configuration > Journals
2. Archive a Journal with outgoing payment method
3. Go to Expenses > Create an Expense paid by company
4. Note that payment methods from archived journal are still visible and can be selected.
Issue:
- Archived journals with outbound payment methods were still selectable when creating company-paid expenses.
- Due to this [commit](https://github.com/odoo/odoo/commit/5c9a6704dd54bbbde1703850619ddcc1a3552547) The journals can be archived without system prevention as the action_archived method has been removed.
Solution:
- This occurred because selectable_payment_method_line_ids did not filter out inactive journals when falling back to a generic search. -Aligning the search domain with
[company_expense_allowed_payment_method_line_ids]
(https://github.com/odoo/odoo/blob/19.0/addons/hr_expense/models/res_company.py#L20) by excluding payment method lines linked to inactive journals.
Before Fix:
```py
In [1]: expense = self.env['hr.expense'].browse(1639)
In [2]: expense.selectable_payment_method_line_ids
Out[2]: account.payment.method.line(2, 4, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 166, 170, 172, 512, 516)
In [3]: archived_journal_ids = []
In [4]: payment_method_lines = self.env['account.payment.method.line'].search([
...: *self.env['account.journal']._check_company_domain(expense.company_id),
...: ('payment_type', '=', 'outbound'),
...: ])
In [5]: payment_method_lines
Out[5]: account.payment.method.line(2, 4, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 166, 170, 172, 512, 516)
In [6]: for payment_method_line in payment_method_lines:
...: if not payment_method_line.journal_id.active:
...: archived_journal_ids.append(payment_method_line.journal_id.id)
...:
In [7]: archived_journal_ids
Out[7]: [7, 8]
```
After Fix:
```py
In [8]: payment_method_lines_with_fix = self.env['account.payment.method.line'].search([
...: # The journal is the source of the payment method line company
...: *self.env['account.journal']._check_company_domain(expense.company_id),
...: ('payment_type', '=', 'outbound'),
...: ('journal_id.active', '=', True),
...: ])
In [9]: payment_method_lines_with_fix
Out[9]: account.payment.method.line(153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 166, 170, 172, 512, 516)
In [10]: archived_journal_ids_with_fix = []
In [11]: for payment_method_line in payment_method_lines_with_fix:
...: if not payment_method_line.journal_id.active:
...: archived_journal_ids_with_fix.append(payment_method_line.journal_id.id)
In [12]: archived_journal_ids_with_fix
Out[12]: []
```
OPW-5461359
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#242743This update corrects a bug that prevented new partner records from being created when attempting to add them to an existing recordset. The issue stemmed from a mismanaged 'self' variable within the partner creation process. This fix ensures correct record handling during partner creation, improving data integrity.
Original PR description
**Issue:** `ValueError: Expected singleton` when creating new partners on a non empty (no singleton) recordset due to the `_add_missing_default_values` call. The default create method uses `self = self.browse()` to remove the records, but the `res.partner` override was still using its original `self`. **Fix:** Properly call the method on an empty recordset. related: https://github.com/odoo/odoo/commit/79486ec3fc553845cac14fb135c16fe0b093e3b4 opw-4932114
This update fixes an error in the French Profit and Loss report (`l10n_fr_reports`) where account 649 was incorrectly placed. The change aligns with French accounting standards (PCG 2025 & 2026) by correctly categorizing this account within 'Wages and Salaries' and 'Social Security Charges'.
Original PR description
## Issue In the *Profit and Loss* report for the French localization (`l10n_fr_reports`), the account 649 was mentioned in the *"Reversals of provisions (and depreciation), expense transfers"*…
## Issue
In the *Profit and Loss* report for the French localization (`l10n_fr_reports`), the account 649 was mentioned in the *"Reversals of provisions (and depreciation), expense transfers"* section, instead of *"Wages and salaries"* and *"Social security charges"*. This classification is described in the *"Recueil des normes comptables françaises"* (Versions [2025](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Reglements/Recueils/PCG_Janvier2025/Recueil-NF-Janvier-2025.pdf) and [2026](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/recueil/RECEUIL-PCG-2026-AVEC-COUVERTURE.pdf)).
## Steps to reproduce
1. Install *France - Accounting Reports* (`l10n_fr_reports`)
2. Go to the *Profit and Loss* report
3. In debug mode, click the information buttons on the following rows:
- *Reversals of provisions (and depreciation), expense tranfers*: **649 is mentioned**
- *Wages and salaries*: **649 is not mentioned**
- *Social security charges*: **649 is not mentioned**
## Note
The account 649 was added at the beginning of the formula for the *"Wages and salaries"* section in order to respect a logical order. In the *"Social security charges"* formula, since no logical order appears to be used, the account was added at the end.
opw-5724559
Forward-Port-Of: odoo/enterprise#105856
Forward-Port-Of: odoo/enterprise#105474This update corrects a bug that prevented visitors from appearing in search results when their check-in times were recorded in time zones other than the user's local time. The fix ensures all date/time comparisons are done in UTC, resolving filtering inaccuracies and improving visitor data visibility across different locations.
Original PR description
Steps to reproduce -------------------------- 1. Install Frontdesk 2. Go to Frontdesk → Visitors 3. Create a visitor with a check-in time before today 05:30 (local timezone: Asia/Kolkata) 4. Check visitors Issue: -------- The created record is not displayed because "today" filter used the user's local date to build a datetime range but failed to convert those boundaries to UTC before querying the database, leading to incorrect filtering in non-UTC time zones. Solution ------------- Convert those datetimes to UTC using `.to_utc()` in the filter domain opw-5385995 Forward-Port-Of: odoo/enterprise#102865
This update ensures that WebGL testing continues to function correctly in Odoo's automated tests, even with recent changes in Chrome. Because SwiftShader (a software renderer) is now the default fallback for Chrome 144 in headless mode, this change re-enables WebGL to maintain testing of features like image filters. While SwiftShader is less secure, it's deemed acceptable for controlled test environments.
Original PR description
Since Chrome 144 disabled [^1] by default the WebGL fallback to the software renderer SwiftShader, this commit reenables [^2][^3] it when running in headless mode to allow to keep testing WebGL features (i.e. image filters in website builder). Note: the SwiftShader implementation is considered deprecated and less safe than proper hardware based ones, hence not recommended for a regular usage with untrusted content. However, as tests are run in a more controlled environment, it looks reasonnable to opt-in to keep actually testing WebGL features. [^1]: https://chromium-review.googlesource.com/c/chromium/src/+/7128438 [^2]: https://issues.chromium.org/issues/476172421 [^3]: https://chromestatus.com/feature/5166674414927872 Forward-Port-Of: odoo/odoo#246289
This update resolves an issue where editing a bank statement line caused unnecessary recalculations of all related lines, including reconciled ones. The change now ensures that only the edited line is recomputed, improving performance and stability when working with bank statement data. This optimization enhances the user experience and reduces processing time.
Original PR description
When we edit a bank statement line, it triggers the recompute of all other lines, even the reconciled ones. This commit changes this behavior so reconciled lines are not recomputed task-5882885
This update ensures that the current day location field is consistently included when retrieving data for the homeworking feature, particularly in scenarios like creating many-to-many relationships in Studio. Previously, this data was sometimes missing, causing issues. This fix guarantees accurate location information is provided, improving the functionality of the homeworking workflow.
Original PR description
Before this commit, the feature at commit odoo/odoo@b3be3af61cc08d0dea84969425d24957f215b26f worked by chance, because in most cases ALL fields where returned in the get views, since most of the time the search view is asked for as well, hence yielding all fields in the model There were issues when triggering get_views from another place, namely studio when creating a many2many. After this commit, we make sure the current day location field's description is sent opw-5484321 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246096 Forward-Port-Of: odoo/odoo#245740
This update resolves a problem where customer claims weren't being processed correctly due to a limitation in how the system matched invoices with VAT numbers. Specifically, when a child invoice shared the same VAT number as the parent, the system would incorrectly select a partner, preventing the necessary account move updates. This fix ensures accurate claim processing.
Original PR description
When we process new customer claims, we need to search for the corresponding account moves in order to update their `l10n_cl_dte_acceptation_status`. Currently, we only expect 1 partner per VAT number when searching for a partner to match with the account move. However, this is not always true. For instance, a child invoice contact will share the same VAT number than the parent partner. This can lead to the selection of the wrong partner in the search domain and consequently, the account move not being found. Related ticket: opw-5257481 Forward-Port-Of: odoo/enterprise#105653 Forward-Port-Of: odoo/enterprise#103366
This update resolves a confusion for users of the account_peppol module. Previously, a setting was configured as 'demo' while another related setting was 'test'. This change ensures a consistent and clear setup process, improving usability and reducing potential errors.
Original PR description
Currently, the proxy_client_user is neutralized as demo. But the edi_mode is set to test. It's confusing for the users, and we should be consistent. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246181
This update corrects a bug where the serial number of products on 'ready' delivery orders was being incorrectly updated. The fix prevents changes to the assigned serial number when adding new moves to these orders, ensuring accurate stock tracking and order fulfillment. This resolves an issue that could lead to discrepancies in inventory counts.
Original PR description
Steps to reproduce: - Create a storable product tracked by serial number (e.g. "P1") - Set the quantity on hand to 2 with serial numbers SN1 and SN2 - Create a delivery order - Add any product with available quantity - Mark the delivery as "To Do" -> The picking is in the `ready` state - Add a new move line with product "P1" and assign serial number SN2 -> Before saving, the quantity is correctlyupdated to 1 - Save the delivery Problem The assigned lot/serial number is unexpectedly replaced with 'SN1'. Fix: Do not update or recompute the serial/lot number when creating a move on pickings that are already in the `ready` state. Forward-Port-Of: odoo/odoo#245622 Forward-Port-Of: odoo/odoo#245447
This update resolves a bug where the serial number assigned to products on 'ready' pickings was incorrectly updated during delivery order creation. The fix prevents unnecessary serial number changes, ensuring accurate tracking of stock and serial numbers. This improves data integrity and reduces potential errors in inventory management.
Original PR description
Steps to reproduce: - Create a storable product tracked by serial number (e.g. "P1") - Set the quantity on hand to 2 with serial numbers SN1 and SN2 - Create a delivery order - Add any product with available quantity - Mark the delivery as "To Do" -> The picking is in the `ready` state - Add a new move line with product "P1" and assign serial number SN2 -> Before saving, the quantity is correctlyupdated to 1 - Save the delivery Problem The assigned lot/serial number is unexpectedly replaced with 'SN1'. Fix: Do not update or recompute the serial/lot number when creating a move on pickings that are already in the `ready` state. opw-5385993 Forward-Port-Of: odoo/enterprise#105420 Forward-Port-Of: odoo/enterprise#105338
This fix ensures that customers purchasing event tickets through POS are accurately registered as attendees. Previously, if customer information wasn't provided at the time of purchase, the registration was incomplete. This update aligns the POS registration process with the website, ensuring consistent attendee tracking and reporting.
Original PR description
Currently, when a customer is set on the order and buys a event ticket, the information is not set as partner on the registration. Steps to reproduce: ------------------- * Create an event that asks…
Currently, when a customer is set on the order and buys a event ticket, the information is not set as partner on the registration. Steps to reproduce: ------------------- * Create an event that asks for name but is not required * Open pos and sell on ticket * Do not put name info * Select a customer for the order * Validate order * Check registrations > Observation: The customer is not registered as the attendee Why the fix: ------------ We compare the scenarios with the same flow but from website registrations. On the website if there is no user registered: - If information is not filled, nothing will be registered on the registration - If information is filled it will be used to populate attendee fields If there is a user registered while on website: - If no information is filled, attendee fields will be populated with the data from the connected user - If information is filled, it will be used for attendee fields - If partial information is filled, it will be used for attendee fields but will also be completed with data coming from the connected user To achieve the same behavior from the pos we first need to register the customer as the partner for the event. During event creation we also remove values regarding attendee name, email, phone and company if they were not provided during the order. From the website they are not used during creation if they were not given by the customer. However, in the pos this information is present anyway (as empty string or False) as they are fields on the model "event.registration" and are still send to the backennd even if we remove the information here https://github.com/odoo/odoo/blob/787621e44a9cef30469849929df267cae9e977f2/addons/pos_event/static/src/app/screens/product_screen/product_screen.js#L127 We do the fix server-side as a fix in the frontend would not be as straightforward. A customer might be on the order before selecting event ticket and it's easy but one might also add the customer after the ticket was selected. opw-5137197 Forward-Port-Of: odoo/odoo#242783 Forward-Port-Of: odoo/odoo#234871
This update resolves a technical issue where a missing space in a route caused a problem with the account online synchronization process. This fix ensures the synchronization functionality operates correctly, preventing potential disruptions to data synchronization. It's a routine maintenance update.
Original PR description
During this forward port: https://github.com/odoo/enterprise/commit/a5b9372ca0b23151046c14c9a8ead0ed9cd46b80 there was a missing space in the route. no task id Forward-Port-Of: odoo/enterprise#105849
This update fixes an issue where some Odoo records wouldn't open correctly in their default form view. The change ensures that other views are enabled when opening records, providing a smoother and more reliable user experience. This resolves a technical glitch that impacted record access.
Original PR description
Records of some models may not want to be shown in their form view by default. See related ENT PR for documents. We re-export to avoid patching order issues. In particular, this makes sure that if we are in the webclient, the chat window is opened before executing the "real" open. Task-5386466 Forward-Port-Of: odoo/odoo#246173 Forward-Port-Of: odoo/odoo#244289
This update prevents documents from automatically opening in a form view when accessed through various channels like links or notifications. Previously, users were unexpectedly directed to the document's form, which has now been corrected to align with how documents are accessed in other views. This improves the user experience and ensures consistent document access.
Original PR description
Users do not want to access the form view of the document by default. This PR solves three cases for accessing documents.document records that were not covered before: * From the basic path pattern `odoo/x/documents.document/<id>` * From a systray notification "Open Form View" * when we are not yet in Documents * when we already are in Documents * From the Discuss app, on the record's thread Tests for most of these are included. Additionally, make sure the document is selected on accessing from `_get_access_action`. Task-5386466 Forward-Port-Of: odoo/enterprise#105809 Forward-Port-Of: odoo/enterprise#104622
This update prevents users without the necessary access rights from being redirected to the website when attempting to view the eCommerce reporting menu. The fix clarifies access restrictions by raising an error instead of a redirect, improving the user experience and ensuring proper access controls.
Original PR description
__Steps to reproduce on runbot:__ 1. Login with Mitchell Admin 2. Remove Marc Demo from the `sales_team.group_sale_salesman` access group (User: Own Documents Only) 3. Login with Marc Demo 4. Open…
__Steps to reproduce on runbot:__ 1. Login with Mitchell Admin 2. Remove Marc Demo from the `sales_team.group_sale_salesman` access group (User: Own Documents Only) 3. Login with Marc Demo 4. Open the Website app and go to Reporting > eCommerce => You are redirected to the website in frontend mode __Reason:__ Clicking on the eCommerce reporting menu calls `action_dashboard_redirect`, which redirects to the website if the user is not in `base.group_system`, `website.group_website_designer`, or `sales_team.group_sale_salesman`. Since Marc Demo is not in any of these groups, he is redirected to the website without any message, which is not very user friendly. __Fix:__ - Add the groups to the menu to prevent showing it if the user does not have access to it anyway. - Raise an access error instead of redirecting to the website to make it clear to the user that they cannot open the dashboard even if they could see it. This also fixes [`TestMenusDemo`] by preventing this menu from being tested with the demo user in case he doesn't have access to it. [`TestMenusDemo`]: https://github.com/odoo/odoo/blob/736b71202db840ba6a7ed7e7f014b5b7c493d589/addons/web/tests/test_click_everywhere.py#L41C9-L41C41 runbot-234747
This update resolves a critical issue where downpayment invoices generated through POS weren't correctly linked to final invoices, leading to report errors. The fix ensures accurate reference creation and correct invoice type codes for downpayment invoices, improving the reliability of financial reporting within the POS system.
Original PR description
Description of the issue/feature this PR addresses: This PR addressed two issues, one related to pos_sale, and the other related to l10n_gcc_invoice that was found during testing. the first and main…
Description of the issue/feature this PR addresses: This PR addressed two issues, one related to pos_sale, and the other related to l10n_gcc_invoice that was found during testing. the first and main issue this PR addresses is that _get_downpayment_lines and _is_downpayment don't work properly on downpayment and final invoices generated in POS since there is no link formed between them through the sale order. the second issue occurs during when printing downpayment invoices that were made through POS. since there is no line.name for the downpayment line. an error pops up due to the dual language logic in place. To reproduce the issue: - install pos_sale & l10n_sa_edi_pos. - configure downpayment product on pos.config - generate an SO and confirm it in the backend - create a downpayment for that SO through POS - settle the SO on the POS or through the backend. - you'll find that the final invoice generated doesn't reference the downpayment invoice - you'll also find that the downpayment invoice doesn't have the correct invoice type code indicating that it's a downpayment. - printing the invoice will also give an error when l10n_gcc_invoice is installed (for the downpayment invoice) Current behavior before PR: xml documents generated from l10n_sa_edi don't carry the correct reference to the downpayment invoice when it's the final invoice. they also don't have the correct invoice type code when it's a downpayment invoice if generated through POS Desired behavior after PR is merged: the methods _get_downpayment_lines and _is_downpayment now correctly identify the downpayment lines & if it's a downpayment respectively. the dual language product name now shows on the invoice pdf without raising an error if line.name is undefined. Task-5135918 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a test failure caused by a recent change to the payment method processing logic in the l10n_uy_edi module. The commit simply adds the necessary update to the test suite to account for the new method extension, ensuring the system continues to function correctly.
Original PR description
The PR odoo/odoo#244443 introduces a new extension to the method _is_downpayment hence the test fails since it is not patched. This commit adds the new extension to the patched list. task-5135918
A bug was causing the input field in the campaign test dialog to disappear, requiring users to close and reopen the dialog to use it. This fix addresses a technical issue related to how the system handles empty input fields, ensuring the field remains visible and functional. The scope was limited to the marketing automation module for efficiency.
Original PR description
Steps to reproduce: 1. Install `marketing_automation` 2. Create a campaign with activity and click on `Launch a test` button 3. Clear the input field and then click outside the input area Issue: -…
Steps to reproduce: 1. Install `marketing_automation` 2. Create a campaign with activity and click on `Launch a test` button 3. Clear the input field and then click outside the input area Issue: - The input area has disappeared. Now, the only way to get it back is by closing the dialog and reopening it Cause: - Field `resource_ref` uses `hide_model: True`, and when cleared, the widget has no value and no model selector to determine the target model because of the function `getRelation` that now returns `undefined`, by this XML fails to render the `<Many2OneField/>` https://github.com/odoo/odoo/blob/7680b83501cef18362be38f90715d824f2bf9cd6/addons/web/static/src/views/fields/reference/reference_field.js#L107-L119 Solution: - Add `model_field: model_id` option to the view so the widget can resolve the model from the `model_id` field even when input is empty Note: - This behavior also occurs in other places. After discussion with the framework team, we agreed to keep the scope of this PR limited to marketing_automation, as this is not a priority issue. A broader fix can be addressed in the master if needed. opw-5473320 Forward-Port-Of: odoo/enterprise#104547
This update resolves a performance issue in the project timesheet report that was causing it to fail with large datasets. By using a more efficient query structure with CROSS LATERAL JOIN, the report now loads significantly faster – approximately 2 seconds – improving user experience. This change focuses on optimizing the report's data processing.
Original PR description
After this commit https://github.com/odoo-dev/enterprise/commit/6c33bde74342b634d9f6fbda4ef407ffe9bac54f we introduced a new left join which seems that it slowed down the query a lot. So the report…
After this commit https://github.com/odoo-dev/enterprise/commit/6c33bde74342b634d9f6fbda4ef407ffe9bac54f we introduced a new left join which seems that it slowed down the query a lot. So the report doesn't load at all if we have a lot of records. In this PR we are introducing CROSS LATERAL JOIN as we want to generate only the the relevant dates not all dates between the min starting date and max ending date of all slots. Query plan after modification https://explain.dalibo.com/plan/eh5293ba2354f43c The testing cardinality of the tables: `planning.slot` 7178 rows `hr.employee` 332 rows `resource.resource` 332 rows `resource_calendar_leaves` 4061 rows `account_analytic_line` 267376 rows `generate_series()` will produce 206417 rows | Before | After | |-----------------------------------------|-------| | Query keep being active with no results | ~2s | opw-5089052 Forward-Port-Of: odoo/enterprise#105538 Forward-Port-Of: odoo/enterprise#102283
This update corrects a warning message appearing in the sales module. The previous code incorrectly processed multiple sales leads at once, leading to an error. This change ensures that each sales lead is handled individually, resolving the warning and improving system stability.
Original PR description
### Issue: In #244061 changes, the expired so leads to warning message. However, the batch `res_id` is used instead of single record which is an error. opw-5478691 Forward-Port-Of: odoo/odoo#246369
This update allows store managers to directly create new products within the Point of Sale (POS) interface. Previously, this functionality was restricted to system administrators, limiting store managers' ability to quickly add products to the system. This change improves operational efficiency and responsiveness for retail locations.
Original PR description
Before this commit, only system users could create products from the POS interface. This limited the ability of store managers. opw-5418727 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243605 Forward-Port-Of: odoo/odoo#240520
This update resolves issues preventing correct QR code generation for invoices and receipts in the Saudi Arabia (SA) POS system. Specifically, it ensures invoices reprint correctly even with ZATCA onboarding problems and displays the appropriate Phase 1 QR code when electronic invoicing is disabled, improving compliance and user experience.
Original PR description
Ensure proper handling of QR code generation and POS EDI behavior by fixing multiple issues across invoice reprints and journal onboarding. QR codes now correctly appear on reprinted invoices when…
Ensure proper handling of QR code generation and POS EDI behavior by fixing multiple issues across invoice reprints and journal onboarding. QR codes now correctly appear on reprinted invoices when journal problems occur during order confirmation. POS correctly falls back to the Phase 1 flow when the journal is not onboarded and electronic invoicing is not enabled. Additionally, POS receipts now display the proper Phase 1 QR code whenever the EDI module is installed. Problem 1: If ZATCA does not properly receive the invoice generated from a POS order (wrong onboarding, wrong details on company, etc.) the invoice printed from POS will not contain the QR code, even after successfully resubmitting the invoice to ZATCA, load the order and reprint the invoice to see this Testing the fix: Change the VAT number on the company to be faulty, create a POS order, Fix the VAT number and resubmit the invoice, load the POS order and reprint invoice, it will now show the QR code. Problem 2: When disabling the E-invoicing for a phase 2 journal, the POS receipt will still try to print the phase 2 QR code but the system will flag it as 'not legal' leaving the POS receipt empty, when it should instead print the phase 1 QR code Testing the fix: On the journal, disable the E-invoicing, and create a POS order, it will now show the phase 1 QR code on the receipt task-5032474 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242486 Forward-Port-Of: odoo/odoo#234945
This update fixes a technical error that could occur when changing the timesheet invoicing policy after a sales order was created and then the user who created it was deleted. The change ensures the system correctly handles scenarios where the original user's information is no longer available, preventing a traceback and maintaining proper policy application.
Original PR description
Steps to reproduce: 1. Create a new user in the database 2. Create a new sales order as the new user 3. Add an order line where the product is of type "Service" and has an invoicing policy of "Based on Timesheets" 4. Confirm the sales order 5. Sign out of the new users account and sign in as admin 6. Delete the newly created user 7. Go into Settings > Timesheets > Invoicing Policy 8. Attempt to change the policy to "Validated timesheets only" 9. Save your changes 10. Observe the traceback The `if` statement would trigger if any record in the recordset had a `create_uid`, which would cause a traceback if the first record in the recordset happened to not have a `create_uid`. This can occur if the user who created a given sale order is deleted from the database. This change will ensure that the function correctly falls back to the currently signed in user if the sale order create_uid doesn't exist. opw-5868538 Forward-Port-Of: odoo/enterprise#105687
This update corrects an issue where text within Odoo views was unexpectedly removed when a field was restricted through access controls. Previously, this created inconsistent and confusing view layouts. This fix ensures that all text remains visible after a field is removed, maintaining a consistent user experience.
Original PR description
In a view, if a field is removed due to security access restrictions, the text that follows it is not preserved. This leads to inconsistencies in the view. opw-5798852 Forward-Port-Of: odoo/odoo#246238 Forward-Port-Of: odoo/odoo#245855
This update fixes an issue where product names weren't consistently displayed in the correct language based on the user's selected language setting. Previously, repeated access to the product name within a method would default back to the initial language. Now, the system always uses the current language context when generating product names, ensuring accurate display for all users.
Original PR description
Description of the issue/feature this PR addresses: Compute of display_name in different languages that can be returned incorrect Current behavior before PR: When accessing two times in the same method the display_name of a configured product but the second time having a .with_context(lang=lang) other than the previous language, the returned display name will not be in the specified language as the cached value will be returned. Desired behavior after PR is merged: _compute_display_name should always take into account a change of language in context when the value is accessed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242829
This update resolves an issue where a technical error during bill import could cause duplicate entries in our PEPPOL integration. The change ensures that these errors don't block the import process and allows bills to be left unlinked, improving the reliability of our data synchronization.
Original PR description
Backport of https://github.com/odoo/odoo/commit/71de6902d73bec32f93e3be8f4de4ec89e9dc987 A UserError there can cause duplicates in peppol fetching. It should never block an ack. We can leave them unlinked We also do the same for any unexpected error that occurs after we've created the move. opw-5492092 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246475
This update resolves an issue where a 100% discount combined with shipping costs caused a technical error in the Express Stripe checkout form. The fix adjusts how zero minor amounts are handled, ensuring the checkout process functions correctly when discounts are applied. This prevents errors and allows for accurate order processing with significant discounts.
Original PR description
### Issue: Due to this issue, there is a traceback, in express stripe checkout when there is a 100% discount and shipping cost. Steps to reproduce: 1- Setup `Stripe` as the only payment provider in the db. 2- Create a discount code with 100% discount on order. 3- Set a fixed price on the delivery method. 4- On shop, add a product to cart, and then enter the discount code. 5- Refresh the page. There is a traceback. #### Cause: This issue is introduced after #209103, which set `minor_amount` to amount excluding delivery. In the case it's 0, it's not going to be rendered on express_checkout view as it is false. Which cause a traceback here: https://github.com/odoo/odoo/blob/8f7e3d588c6c1189e64442a33037666d5d70aae7/addons/payment_stripe/static/src/js/express_checkout_form.js#L73-L81 opw-5482646 Forward-Port-Of: odoo/odoo#246355