Daily updates from Odoo
Navigate
Branch
Tuesday, September 30, 2025
279 changes
18 changes
Enhancements to existing features
The self-ordering setup screens now present QR code actions more clearly across desktop and mobile. Users also get a clearer Settings label and a new option for free metal or wood stand references, making setup choices easier to understand.
Original PR description
In this commit: ------------------- - Removed the QR code icon from the desktop view of the `Get QR Code` button. - Moved the QR code button from the navbar into the burger menu for mobile view. - Added a new reference option `Free Metal / Wood Stands` in settings. - Renamed the `Edit` menu item to `Settings`, to make the button functionality clear from the label as it leads the user to the settings page for the selected config. task:5003448 Forward-Port-Of: odoo/odoo#228772 Forward-Port-Of: odoo/odoo#225856
Email content now preserves border styles more reliably when formatting is converted for sending. This helps images and other bordered elements appear as intended in recipients' email clients.
Original PR description
This commit ports the following fixes to `convert_inline` of `mail`: - https://github.com/odoo/odoo/commit/8923f32426fc64e90db249fad47d7ca7e338adef [FIX] web_editor: adapt border-style value based on border widths - https://github.com/odoo/odoo/commit/7de31c6261d2fe9f58b0c6cb635977e77eecd9d6 [FIX] web_editor: ensure image border visible in emails --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228970
Resolved issues and error corrections
Fixed an issue where Peruvian electronic invoices for foreign-currency down payments could show the company currency instead of the invoice currency. This helps ensure invoice XML data matches the actual transaction currency and avoids compliance or validation problems.
Original PR description
#### Issue: - After invoicing a downpayment in a foreign currency, in the XMl of the total invoice, the currency_id on the prepaid tag is set to PEN instead of the right currency. #### Step to…
#### Issue: - After invoicing a downpayment in a foreign currency, in the XMl of the total invoice, the currency_id on the prepaid tag is set to PEN instead of the right currency. #### Step to reproduce: 1. Install l10n_pe_edi 2. Sell a product to "Comercial Constructora los Patitos" through the sales app and make sure you use USD (or a different currency than PEN). 3. Create a downpayment invoice, could be any percentage. 4. To make sure it works correctly, add a random document number on the invoice with the format ABC-01234567. 5. Confirm this invoice. 6. Now go back to the sale order and deliver your product. 7. Create the final invoice, where the downpayment will be deducted. Make sure it is also in USD (or whatever currency you chose). 8. Confirm the invoice. #### Current behavior: - Display "PEN" in the attribute currencyID of tag PaidAmount in a PrepaidPayment: <cbc:PaidAmount currencyID=PEN> #### Expected behavior: - The currency displayed should match the invoice currency #### Cause of the issue: - the currency of the company emitting the invoice was used instead of the currency of the invoice. opw-5061019
This fix ensures temporary database counters created for self-order point-of-sale sessions are removed once a session is closed. It helps prevent unnecessary database clutter over time, supporting smoother system maintenance without changing the user experience.
Original PR description
to avoid having too many postgres sequences, this make sure the sequence used by the pos session is cleaned up after being closed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229069 Forward-Port-Of: odoo/odoo#223758
The payment wizard now checks the bank account the user actually selects, rather than only the account originally tied to the bill. This prevents unnecessary warning banners when a trusted bank account is chosen for SEPA vendor payments.
Original PR description
**Steps to reproduce:** 1. Install the modules: `accounting` and `account_iso20022`. 2. Configure a bank journal with SEPA credit transfer in *Outgoing payment methods*. 3. Create a partner with two…
**Steps to reproduce:** 1. Install the modules: `accounting` and `account_iso20022`. 2. Configure a bank journal with SEPA credit transfer in *Outgoing payment methods*. 3. Create a partner with two bank accounts: one trusted, one untrusted. 4. Create a vendor bill for this partner. 5. Register a payment using the SEPA credit transfer method. 6. Manually select the trusted bank account from the dropdown. **Observed behavior:** * A warning banner is shown when the trusted account is selected. **Root cause:** * `_compute_trust_values` only validated the bank account from the batch (original invoice data) and ignored the `partner_bank_id` if the user changed it manually in the wizard. **Solution:** * Update `_compute_trust_values` to also validate the currently selected `partner_bank_id`, ensuring the trust check reflects the user’s actual selection. * added testcase for the same in account_iso20022 [#95124](https://github.com/odoo/enterprise/pull/95124) opw-5059740 Forward-Port-Of: odoo/odoo#227404
The CRM periodic digest now shows the correct number of free credits for targeted lead generation. This prevents customers from seeing an overstated offer and helps keep product communication accurate.
Original PR description
## Versions 17.0+ ## Issue The Periodic Digest contains wrong information in a tip. 20 credits are given for specific target lead generation, not 200. opw-5114252 Forward-Port-Of: odoo/odoo#228791
This fixes an issue in Odoo's web testing tools where creating records linked through many-to-many relationships could fail. The change improves reliability for automated tests and helps prevent false errors during development and quality checks.
Original PR description
Before this commit, using CREATE Command on a many2many field would result in an error. This is because upon record creation the inverse field would be set to the single id, which is incorrect for a many2many field. This commit fixes the issue by setting the inverse field of a many2many to a list containing the new id. Forward-Port-Of: odoo/odoo#208524
Fixed an issue where opening the barcode scanner in Attendance kiosk mode could trigger an error when debug mode was enabled. This keeps the kiosk scanning flow stable for administrators and users testing or troubleshooting the Attendances app.
Original PR description
**Step to reproduce:** - install Attendances app - turn on debug mode - go to Attendance -> kiosk mode - open the scanner **Observation:** - We get a traceback **Cause:** - we pass a extra prop `token` to BarcodeDialog component, which is not accepted by it https://github.com/odoo/odoo/blob/178dff30131a93680dfd994fd22b29a766ee9354/addons/web/static/src/core/barcode/barcode_dialog.js#L12 - this raises issue from OWL when we have debug-mode on **Fix:** - reuse the actual `scanBarcode` method and remove the faulty one. https://github.com/odoo/odoo/blob/178dff30131a93680dfd994fd22b29a766ee9354/addons/web/static/src/core/barcode/barcode_dialog.js#L47-L60 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227551 Forward-Port-Of: odoo/odoo#225738
The SEPA payment flow now checks the bank account actually selected by the user before showing a trust warning. This prevents incorrect warning banners when a trusted account is chosen, reducing confusion during vendor payment processing.
Original PR description
**Steps to reproduce:** 1. Install the modules: `accounting` and `account_iso20022`. 2. Configure a bank journal with SEPA credit transfer in *Outgoing payment methods*. 3. Create a partner with two bank accounts: one trusted, one untrusted. 4. Create a vendor bill for this partner. 5. Register a payment using the SEPA credit transfer method. 6. Manually select the trusted bank account from the dropdown. **Observed behavior:** * A warning banner is shown when the trusted account is selected. **Root cause:** * `_compute_trust_values` only validated the bank account from the batch (original invoice data) and ignored the `partner_bank_id` if the user changed it manually in the wizard. **Solution:** * Update `_compute_trust_values` to also validate the currently selected `partner_bank_id`, ensuring the trust check reflects the user’s actual selection. opw-5059740 Forward-Port-Of: odoo/enterprise#95124
Arabic invoice reports for Saudi Arabia now display the description column with consistent alignment alongside the other invoice columns. This improves readability for users printing or sharing localized invoices without changing invoice data or workflow.
Original PR description
**Steps to reproduce:** 1. Install l10n_gcc_invoice. 2. Add and Switch to a Saudi Arabia company. 3. Select boxed layout (or keep any layout). 4. Create and print an invoice. **Issue:** - The…
**Steps to reproduce:** 1. Install l10n_gcc_invoice. 2. Add and Switch to a Saudi Arabia company. 3. Select boxed layout (or keep any layout). 4. Create and print an invoice. **Issue:** - The description column is misaligned in the Arabic invoice report. According to Saudi localization, it should be aligned to the left for better readability. The current alignment makes Arabic text inconvenient to read. **Cause:** - Other columns (e.g., quantity, taxes) already use the `text-end` class, but the description column has no alignment class, causing inconsistent layout and misalignment. **Solution:** - Added the `text-end` class to the description column to ensure proper alignment and consistent readability in Arabic invoice reports. **Before FIX:** <img width="831" height="329" alt="image" src="https://github.com/user-attachments/assets/857f9f7f-d930-4c73-b2fa-eacd7a153ea3" /> **After FIX** <img width="788" height="354" alt="image" src="https://github.com/user-attachments/assets/929acdb1-bb13-4e1e-829c-8fdbe18334a4" /> **opw-5087770** Forward-Port-Of: odoo/odoo#228118
This fix prevents an error from appearing when users change a website theme color and then save their changes. It improves the reliability of the website editing experience by handling the save process correctly.
Original PR description
This PR resolves a traceback that occurred when changing the theme color from the color palette and pressing the save button. This was due to an unhandled promise rejection. task-3919146 Forward-Port-Of: odoo/odoo#227946
Field service sale order lines now use the customer’s assigned pricelist instead of the product’s default price. This ensures customers are billed according to agreed pricing when tasks with timesheets are validated.
Original PR description
Before this commit, the service line on the sale order ignored the customer’s pricelist and used the product’s default price. Steps to reproduce: - Assign a fixed-price pricelist to a customer. - Create an FSM task for them and add a timesheet. - Validate the task and check the service line price. After this commit, the service line correctly reflects the price from the assigned pricelist. task-4830183 Forward-Port-Of: odoo/enterprise#95650 Forward-Port-Of: odoo/enterprise#88039
The forum page cover block can now be selected and edited in the website builder. This restores expected editing behavior for website managers, making it easier to customize forum pages without workarounds.
Original PR description
Steps to reproduce: - Go to the "/forum" page and click "Edit". - Click the "s_cover" block. - Bug: the snippet is not editable. The cover snippet contains a link rendered with "t-attf-href", which makes the website builder refuse to mark the block as editable. This commit adds "t-ignore="True"" on the "oe_structure" so the branding stops before reaching the link and the snippet becomes editable again. task-5095234 Forward-Port-Of: odoo/odoo#227724
This update makes sure errors raised during automated tests are properly detected and reported. It helps improve product quality by preventing problems from being silently ignored before release.
Original PR description
This commit follows a community fix that restores proper error handling within and outside of unit tests. As such, it fixes tests reporting errors that were previously not picked up. Community PR: https://github.com/odoo/odoo/pull/228836
Coupon and global discount lines are now identified more reliably on sales orders, so discounted amounts are passed correctly to delivery services such as Shiprocket. This prevents cash-on-delivery shipments from being created with missing discount totals and keeps discount line values stable when quantities change.
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
Shiprocket Cash on Delivery orders now send coupon discounts correctly, including the tax-inclusive discount amount. This helps ensure the amount collected from customers matches the discounted order total and avoids overcharging or reconciliation issues.
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#92310The internal web test runner now treats errors and warnings with clearer severity levels, so problems are reported appropriately depending on when they occur. This helps prevent test issues from being missed or from unnecessarily stopping test runs, improving confidence in automated quality checks.
Original PR description
This commit associates separate "issue levels" to the test runner's internal logger. These affect the logging and reporting of issues, i.e. errors and warnings: - suppressed (by 'test.todo'): issues are traced in the console but not reported in test results; - trace (default in test runs): issues are traced in the console and reported in test results; - global: issues are warned/errored in the console with "HOOT" prefix (i.e. won't interrupt the test run); - critical (default outside of test runs): issues are warned/errored in the console without "HOOT" prefix, thus interrupting the whole test run. This fix should hopefully solve errors that were too quiet before test run, or too "important" during the run. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228674
Fixes the employee onboarding helper so teams can load sample data and add a new employee from the onboarding view. The helper now appears only in the right empty-company situations, reducing confusion for users managing employee records.
Original PR description
## Issue
The load sample data button of the employee onboarding helper doesn't work.
## PR Purpose
1) Add a "New employee" button to the onboarding view
2) Display the onboarding employee view only when :
- 'My Company' is being displayed
- There is 0 or 1 (Administrator) employee in 'My Company'
- The demo data have not been loaded
3) When you jump on an empty screen due to a search, display only the onboarding "helper blocks" (design)
Task: #4879557
Signed-off by thha11 changes
Enhancements to existing features
Email content now preserves image and element borders more reliably when formatting is converted for sending. This helps ensure emails look as intended for recipients across email clients.
Original PR description
This commit ports the following fixes to `convert_inline` of `mail`: - https://github.com/odoo/odoo/commit/8923f32426fc64e90db249fad47d7ca7e338adef [FIX] web_editor: adapt border-style value based on border widths - https://github.com/odoo/odoo/commit/7de31c6261d2fe9f58b0c6cb635977e77eecd9d6 [FIX] web_editor: ensure image border visible in emails --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228970
The self-ordering interface has been simplified by making the Get QR Code button cleaner on desktop and easier to find in the mobile menu. Settings now include a clearer option for free metal or wood stands, and menu labels better explain where users will be taken.
Original PR description
In this commit: ------------------- - Removed the QR code icon from the desktop view of the `Get QR Code` button. - Moved the QR code button from the navbar into the burger menu for mobile view. - Added a new reference option `Free Metal / Wood Stands` in settings. - Renamed the `Edit` menu item to `Settings`, to make the button functionality clear from the label as it leads the user to the settings page for the selected config. task:5003448 Forward-Port-Of: odoo/odoo#228772 Forward-Port-Of: odoo/odoo#225856
Resolved issues and error corrections
The CRM Periodic Digest tip now states the correct number of free credits for targeted lead generation. This avoids misleading users by changing the communicated amount from 200 credits to the actual 20 credits.
Original PR description
## Versions 17.0+ ## Issue The Periodic Digest contains wrong information in a tip. 20 credits are given for specific target lead generation, not 200. opw-5114252 Forward-Port-Of: odoo/odoo#228791
This update corrects how the web mock server handles creating linked many-to-many records. It prevents test errors by storing the new relationship in the expected list format, improving reliability of web feature validation.
Original PR description
Before this commit, using CREATE Command on a many2many field would result in an error. This is because upon record creation the inverse field would be set to the single id, which is incorrect for a many2many field. This commit fixes the issue by setting the inverse field of a many2many to a list containing the new id. Forward-Port-Of: odoo/odoo#208524
The payment registration flow now checks the bank account the user actually selects, not only the account originally linked to the invoice. This prevents an incorrect warning from appearing when a trusted bank account is chosen for SEPA vendor payments.
Original PR description
**Steps to reproduce:** 1. Install the modules: `accounting` and `account_iso20022`. 2. Configure a bank journal with SEPA credit transfer in *Outgoing payment methods*. 3. Create a partner with two…
**Steps to reproduce:** 1. Install the modules: `accounting` and `account_iso20022`. 2. Configure a bank journal with SEPA credit transfer in *Outgoing payment methods*. 3. Create a partner with two bank accounts: one trusted, one untrusted. 4. Create a vendor bill for this partner. 5. Register a payment using the SEPA credit transfer method. 6. Manually select the trusted bank account from the dropdown. **Observed behavior:** * A warning banner is shown when the trusted account is selected. **Root cause:** * `_compute_trust_values` only validated the bank account from the batch (original invoice data) and ignored the `partner_bank_id` if the user changed it manually in the wizard. **Solution:** * Update `_compute_trust_values` to also validate the currently selected `partner_bank_id`, ensuring the trust check reflects the user’s actual selection. * added testcase for the same in account_iso20022 [#95124](https://github.com/odoo/enterprise/pull/95124) opw-5059740 Forward-Port-Of: odoo/odoo#227404
SEPA payment registration now checks the bank account the user actually selects, rather than only the account originally linked to the bill. This prevents unnecessary warning banners when a trusted account is chosen, reducing confusion during vendor payment processing.
Original PR description
**Steps to reproduce:** 1. Install the modules: `accounting` and `account_iso20022`. 2. Configure a bank journal with SEPA credit transfer in *Outgoing payment methods*. 3. Create a partner with two bank accounts: one trusted, one untrusted. 4. Create a vendor bill for this partner. 5. Register a payment using the SEPA credit transfer method. 6. Manually select the trusted bank account from the dropdown. **Observed behavior:** * A warning banner is shown when the trusted account is selected. **Root cause:** * `_compute_trust_values` only validated the bank account from the batch (original invoice data) and ignored the `partner_bank_id` if the user changed it manually in the wizard. **Solution:** * Update `_compute_trust_values` to also validate the currently selected `partner_bank_id`, ensuring the trust check reflects the user’s actual selection. opw-5059740 Forward-Port-Of: odoo/enterprise#95124
Fixes an error that could occur when users changed a website theme color from the color palette and then saved. This improves reliability of website editing and helps prevent interruptions during design updates.
Original PR description
This PR resolves a traceback that occurred when changing the theme color from the color palette and pressing the save button. This was due to an unhandled promise rejection. task-3919146 Forward-Port-Of: odoo/odoo#227946
This fixes an issue that prevented website editors from modifying the cover block on the forum page. Forum page content can now be edited normally in the website builder, reducing friction for teams maintaining their community pages.
Original PR description
Steps to reproduce: - Go to the "/forum" page and click "Edit". - Click the "s_cover" block. - Bug: the snippet is not editable. The cover snippet contains a link rendered with "t-attf-href", which makes the website builder refuse to mark the block as editable. This commit adds "t-ignore="True"" on the "oe_structure" so the branding stops before reaching the link and the snippet becomes editable again. task-5095234 Forward-Port-Of: odoo/odoo#227724
This fixes a website display issue where the video size placeholder could appear even when visitors had not accepted optional cookies. The change keeps video-related elements hidden until consent is given, improving privacy compliance and avoiding confusing page content.
Original PR description
Commit [958b41c] introduced a way not to load videos if the user did not accept optional cookies. In doing so, the "video size" container was hidden. However, since [b9b3a60], the code was wrong: - Instead of a proper handler, the `optionalCookiesAccepted` listener wasn't a listener at all and immediately removed `d-none` on `media_iframe_video_size`. - It was all done in the `setup` instead of the `start` or `dynamicContent`. [958b41c]: https://github.com/odoo/odoo/commit/958b41c4acec7e1700ca4d6e0b25ee0ad2aac9f1 [b9b3a60]: https://github.com/odoo/odoo/commit/b9b3a605e0f4c5da3a258c980107d6162da7f44f Forward-Port-Of: odoo/odoo#226817
Arabic invoice reports for Saudi Arabia now display the description column with consistent alignment. This makes printed invoices easier to read and better aligned with local presentation expectations.
Original PR description
**Steps to reproduce:** 1. Install l10n_gcc_invoice. 2. Add and Switch to a Saudi Arabia company. 3. Select boxed layout (or keep any layout). 4. Create and print an invoice. **Issue:** - The…
**Steps to reproduce:** 1. Install l10n_gcc_invoice. 2. Add and Switch to a Saudi Arabia company. 3. Select boxed layout (or keep any layout). 4. Create and print an invoice. **Issue:** - The description column is misaligned in the Arabic invoice report. According to Saudi localization, it should be aligned to the left for better readability. The current alignment makes Arabic text inconvenient to read. **Cause:** - Other columns (e.g., quantity, taxes) already use the `text-end` class, but the description column has no alignment class, causing inconsistent layout and misalignment. **Solution:** - Added the `text-end` class to the description column to ensure proper alignment and consistent readability in Arabic invoice reports. **Before FIX:** <img width="831" height="329" alt="image" src="https://github.com/user-attachments/assets/857f9f7f-d930-4c73-b2fa-eacd7a153ea3" /> **After FIX** <img width="788" height="354" alt="image" src="https://github.com/user-attachments/assets/929acdb1-bb13-4e1e-829c-8fdbe18334a4" /> **opw-5087770** Forward-Port-Of: odoo/odoo#228118
Features or functions removed from Odoo
An obsolete internal component in Sales External Tax was removed because invoicing now uses Odoo's standard process. This reduces maintenance overhead without changing the expected user experience.
Original PR description
The `wizard/` folder contained only `sale_make_invoice_advance.py`, which overrode `_prepare_down_payment_lines_values` but is no longer used. All functionality now relies on Odoo's standard implementation.
2 changes
Resolved issues and error corrections
Sales orders no longer keep an outdated quote calculator after the quotation template is changed. This prevents users from relying on calculator data from the previous template and keeps the sales order aligned with the selected template.
Original PR description
Step to reproduce: - Create a new SO - Add a customer and quotation template to the order - Click on quote calculator smart button - Return to sale order (click on SO number in top left) - Change the quotation template - Result: it does not change the quote calculator that is linked to the new quotation template Cause: - Clicking on Quote Calculator creates a copy of the quotation template spreadsheet and links it to the SO. https://github.com/odoo/enterprise/blob/8bc6098335d283e6d210dc788463a8ef8c559b14/spreadsheet_sale_management/models/sale_order.py#L30-L35 - When the quotation template is later changed, the spreadsheet linked to the old template remains attached to the SO. Fix: - On changing the sale_order_template, the old spreadsheet should be unlinked from the SO. - Keeping it linked is inconsistent, as it does not matches the current template opw-4998587 Forward-Port-Of: odoo/enterprise#93970
The SEPA payment flow now checks the bank account actually selected by the user, rather than only the account originally linked to the invoice. This prevents unnecessary warning banners when a trusted bank account is chosen, improving confidence during vendor payment processing.
Original PR description
**Steps to reproduce:** 1. Install the modules: `accounting` and `account_iso20022`. 2. Configure a bank journal with SEPA credit transfer in *Outgoing payment methods*. 3. Create a partner with two bank accounts: one trusted, one untrusted. 4. Create a vendor bill for this partner. 5. Register a payment using the SEPA credit transfer method. 6. Manually select the trusted bank account from the dropdown. **Observed behavior:** * A warning banner is shown when the trusted account is selected. **Root cause:** * `_compute_trust_values` only validated the bank account from the batch (original invoice data) and ignored the `partner_bank_id` if the user changed it manually in the wizard. **Solution:** * Update `_compute_trust_values` to also validate the currently selected `partner_bank_id`, ensuring the trust check reflects the user’s actual selection. opw-5059740 Forward-Port-Of: odoo/enterprise#95124
47 changes
Security fixes and vulnerability patches
AI tools are now limited to system users because they rely on server actions that regular users should not access. This helps prevent unintended use of privileged automation while keeping normal AI features safer for everyday users.
Original PR description
Tools are server actions to which normal users don't have access. (runbot.build.error/231672) Forward-Port-Of: odoo/enterprise#95534
New functionality added to Odoo
Adds support for Argentina's new IVA Simple tax report export, allowing companies to generate the required CSV zip files for upload to the government portal. This helps Argentinian customers stay compliant with the latest reporting requirements directly from Odoo.
Original PR description
The Argentinian government has released support for a new type of a tax report that companies can upload called IVA Simple. This is a zip of CSV files that can be imported to the government portal. As such we want to support exporting this report for our customers. This commit adds a new auto installed module for a new report export type of IVA Simple on the Argentinian Tax Report as well as the model data required for the export. task-[5027104](https://www.odoo.com/web#id=5027104&view_type=form&model=project.task) Forward-Port-Of: odoo/enterprise#93871
Enhancements to existing features
The Point of Sale interface has been updated to use the newer way of showing tags on orders and order lines. This helps keep the system compatible with upcoming platform changes while preserving the current user experience.
Original PR description
This commit replaces the use of component TagsList by t-foreach and tag component. TagsList will soon not render tags anymore. This commit is a first pass to reduce the diff and make the transition smoother. task-4660360
Manufacturing planning suggestions now use an exact date range to calculate monthly product demand instead of broad preset periods. This makes demand estimates slightly more precise and better aligned with the actual sales or stock movement period being reviewed.
Original PR description
Adapts MPS suggestion to use the new product monthly demand, which now takes a date range, instead of string selection to compute demand BEFORE: product.product monthly_demand compute takes string as arguments for calculations (eg: "three_months") NOW: product.product monthly_demand compute takes date ranges for calculations.
Payroll payslip line and worked days reports have been adjusted so users can no longer edit report fields that should only be viewed. The update also improves report navigation and search options, helping payroll teams access the right data more reliably.
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#95313 Forward-Port-Of: odoo/enterprise#94284
The report editor now uses a newer version of its content-cleaning component, helping keep edited report HTML consistent and reliable. Related automated tests were updated because the underlying tool now produces a more predictable attribute order.
Original PR description
Note: due to the PR [1], the attributes' order is more predicatable, hence the tests adaptations. [1]: https://github.com/cure53/DOMPurify/pull/1085 task-5110128
Portal users can now view and respond to helpdesk tickets created by colleagues from the same company, not only tickets they created or follow. This improves collaboration and visibility for customer teams managing support requests together.
Original PR description
Currently, a portal user can only see tickets that they have created or are following. With this commit, portal users will also be able to view and communicate on tickets created by other colleagues from their company. task-4555162
Resolved issues and error corrections
This fixes visibility issues in dark mode for appointment and point-of-sale screens. Icons and text now use colors that remain readable across light and dark themes, making the interface easier to use.
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#95673 Forward-Port-Of: odoo/enterprise#93993
Mexican electronic invoicing now handles cases where the US dollar currency has been deactivated. This prevents invoice confirmation and sending from failing for companies using Mexico localization and external trade documents.
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
When the AI feature cannot scrape a webpage, the system now records it as a warning instead of an error. This better reflects that the issue is already shown to the user and does not block the overall process, helping reduce unnecessary error alerts.
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#94960
Forward-Port-Of: odoo/enterprise#94002Orders from self-service or kiosk online payments now appear on the preparation display only after payment is confirmed. This prevents staff from preparing unpaid orders while still ensuring confirmed orders reach the kitchen display, including when customers leave through the payment portal exit flow.
Original PR description
pos_*= pos_online_payment_self_order_preparation_display, pos_self_order_iot Before this commit, if an online payment method was assigned to a self or a kiosk, the order was displayed on the preparation display before the payment was confirmed. After this commit, the order is no longer displayed on the preparation display until the payment confirmation. Community PR: https://github.com/odoo/enterprise/pull/87173 Backport of https://github.com/odoo/odoo/pull/87173, with additional logic to ensure the order is correctly sent to the preparation display even if an exit route is used in the payment portal Forward-Port-Of: odoo/enterprise#95583 Forward-Port-Of: odoo/enterprise#95312
The Australian Taxable Payments Annual Report now excludes unrelated customer payments from the Gross Paid amount. This makes TPAR figures more accurate by counting only relevant supplier payment lines for report calculations.
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
The Spanish Mod 349 tax report now correctly shows the underlying invoice details when users audit the summary line for intra-community operations. This helps accounting teams verify reported amounts more reliably and reduces manual investigation when reviewing tax filings.
Original PR description
Steps to reproduce: - With an ES company setup - Create 1 invoice to an EU partner - Make sure Mod349 Invoice Type is set - Go to Accounting / Reporting / Statement Reports / Tax Report - Select Tax Report (Mod 349) (ES) - Audit line 'Importe de las operaciones intracomunitarias' Issue: No line will be shown This occurs because the system will allow auditing the line, since the report line is defined as aggregation of sublines, however those sublines are all custom so we should provide a custom domain to retrieve the relevant lines opw-4752813 Forward-Port-Of: odoo/enterprise#84633
This change corrects how Mexican electronic invoices are calculated so totals match the official XML validation rules. It helps prevent valid invoices from being rejected because of tiny rounding differences in decimal amounts.
Original PR description
The validation in the XML are made based on values rounded to 6 digits. However in Odoo, we do the computation without any rounding. 352.2413793103448 + 876.7435344827586 + 162.92327586206898 + 198.73706896551727 + 526.0383620689655 + 17.241379310344826 = 2133.925 ~= 2133.93 352.241379 + 876.743534 + 162.923276 + 198.737069 + 526.038362 + 17.241379 = 2133.924999 ~= 2133.92 != 2133.93 opw-5096249 Forward-Port-Of: odoo/enterprise#95555 Forward-Port-Of: odoo/enterprise#95413
The partner ledger now keeps names and expand arrows properly aligned on phones and tablets. This makes the report easier to read and use on smaller devices without changing its underlying data or behavior.
Original PR description
Problem: On smaller screens (phone or tablet) the center alignment between the partner name and the little arrow is broken. Cause: This happened because the little arrow has btn class, which gets larger on smaller screens (to make it easier to click). The larger button causes the center alignment to be lost, as it grows alone inside the table row. Fix: This commit fixes this issue by ensuring that the content of line_name and line_cell are vertically aligned to the middle, and that items in their sub-containers are aligned to the center. task-5106889 Forward-Port-Of: odoo/enterprise#95317
Rental orders are no longer blocked by unavailable planning resources when shift synchronization is disabled. This prevents unnecessary confirmation failures in the portal and rental app, making rentals proceed as expected when planning shifts are not being synced.
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#95745 Forward-Port-Of: odoo/enterprise#94176
This fixes naming inconsistencies introduced during a previous refactor of Indian GST reporting. The change helps keep India-specific reporting logic isolated so it does not interfere with other localizations, improving reliability for tax reporting workflows.
Original PR description
Following the refactor-https://github.com/odoo/enterprise/commit/3722e9255647254a078166c5ea9696cbf7818147 and removal of `l10n_in.gst.return.period` and adapting the `account.report` since it's no longer an Indian Localisation model the method names not renamed to the localisation specific in this commit we fix that so other localisation are aren't affected Forward-Port-Of: odoo/enterprise#94441
Fixed an issue where the download menu for a signature request could appear empty when the request was opened from a record's chatter. Users can now reliably access the related documents from the download dropdown, reducing confusion and extra navigation.
Original PR description
Version: - saas-18.4 Steps to reproduce: - Create sign request from 'request signature' activity. - From the chatter of the related record, open the sign request. - It will redirect to form view of that sign request. - click on download dropdown button. Before: - The download dropdown was empty. - This happened because the 'sign_request_documents_dropdown' widget tried to use 'active_id' from the context, but 'active_id' was missing when the sign request was opened from chatter. After: - The download dropdown correctly shows the related documents. - When active_id is not in the context, the widget now uses the sign request id from evalcontext, so it can fetch the right documents. Impact: - Users will always see the correct documents in the download dropdown, even when opening a sign request from chatter. task-5089829 Forward-Port-Of: odoo/enterprise#94885
The AI service now handles invalid tool requests and usage limits more clearly, preventing conversations from stalling or failing silently. This makes AI-powered features more dependable and helps the system recover gracefully when the model makes an unsupported request.
Original PR description
This commit introduces several related fixes to the LLM API service to make tool call processing more robust and prevent silent failures. - **Unknown Tool Calls**: When an LLM requests a tool with an…
This commit introduces several related fixes to the LLM API service to make tool call processing more robust and prevent silent failures. - **Unknown Tool Calls**: When an LLM requests a tool with an invalid or unknown name, it previously resulted in an empty response, causing the conversation to stall. This change ensures that a proper error message is now returned to the LLM for the invalid tool call. This allows the LLM to process the failure and continue the conversation. - **Failing on Limits**: The query processing loop in `_request_llm` has limits for both successive API calls and the number of tool calls per request. Previously, these limits would be reached silently. - **API Call Limit**: If the `AI_MAX_SUCCESSIVE_CALLS` limit is reached without the LLM providing a final answer, a `ValueError` is now raised. This prevents silent failures and makes it clear to the calling code that the request could not be completed. - **Tool Call Limit**: If the number of tool calls in a single response exceeds `AI_MAX_TOOL_CALLS_PER_CALL`, any calls beyond the limit are now provided with a result stating that the limit was reached. This gives the LLM the opportunity to try the unprocessed tool calls again in a subsequent turn. - **Ignore Explanatory Text**: The text that LLMs often include alongside a tool call request (the "thinking" text) is now ignored to provide a cleaner and more concise final response to the user. Forward-Port-Of: odoo/enterprise#94413
Planning now shows a valid allocated percentage for employees using flexible or fully flexible work schedules when grouped by resource and role. This prevents confusing 'NaN' values from appearing in the schedule view 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 Forward-Port-Of: odoo/enterprise#91436
When a signer is no longer assigned in a Sign template, the sidebar now removes the old profile picture instead of showing a stale avatar. This keeps the signer information accurate and avoids confusion for users preparing documents for signature.
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. Forward-Port-Of: odoo/enterprise#95743
Creating a related monetary field in Studio now also creates the matching related currency field, so the amount can be used correctly. This prevents unusable monetary fields and helps ensure values display and calculate with the right currency.
Original PR description
Before this commit, when creating a related field to a monetary, the created currency field was not stored and not related either, so the monetary was unusable. This was because of 5cf5a35a0a8f78655989009d0eddcf39f8430965 , b177b058be1531c3d2af2b591c22591c19240d33 and in general the changes in read_group that largely improve the situation. After this commit, we create a currency field related to the currency field of the related monetary to ensure that the monetary's value is coherent. This is made possible by the above mentionned improvements in read_group opw-5094619 Forward-Port-Of: odoo/enterprise#95407
This fix exposes the company country code in payroll configuration settings. It helps the system access the correct country context from settings, reducing configuration-related errors during setup or processing.
Original PR description
Add a related field in res.config.settings to expose country_code build_error-231405
Payroll settings now include the company country code needed by the configuration view. This prevents upgrade validation errors and access-rights inconsistencies, helping payroll setup remain stable during module updates.
Original PR description
The payroll settings view referenced `country_code` in its invisibility condition, but the field was missing from `res.config.settings`. This caused a validation error and access rights inconsistency during module upgrade. A related field `country_code` has been added, pointing to `company_id.country_id.code`. build_error-231409
This fix prevents errors when upgrading the Lithuanian payroll module by ensuring the payroll settings screen has the country information it expects. It improves reliability for companies using Lithuanian payroll without changing day-to-day payroll features.
Original PR description
The payroll settings view referenced `country_code` in its invisibility condition, but the field was missing from `res.config.settings`. This caused a validation error and access rights inconsistency during module upgrade. A related field `country_code` has been added, pointing to `company_id.country_id.code`. build_erro-231395
Documents can now create server actions that generate journal entries for journals marked as Credit Card. This fixes a gap that prevented users from setting up credit card statement workflows through Documents.
Original PR description
We are unable to create an action to create a credit card statement on a journal with type credit card Allow to create a Server Action to create Journal Entries in journals of type "Credit Card" in Documents. task-5123868
The SEPA payment flow now checks the bank account actually selected by the user, not only the account originally linked to the bill. This prevents unnecessary warning banners when a trusted account is chosen, improving confidence during vendor payment processing.
Original PR description
**Steps to reproduce:** 1. Install the modules: `accounting` and `account_iso20022`. 2. Configure a bank journal with SEPA credit transfer in *Outgoing payment methods*. 3. Create a partner with two bank accounts: one trusted, one untrusted. 4. Create a vendor bill for this partner. 5. Register a payment using the SEPA credit transfer method. 6. Manually select the trusted bank account from the dropdown. **Observed behavior:** * A warning banner is shown when the trusted account is selected. **Root cause:** * `_compute_trust_values` only validated the bank account from the batch (original invoice data) and ignored the `partner_bank_id` if the user changed it manually in the wizard. **Solution:** * Update `_compute_trust_values` to also validate the currently selected `partner_bank_id`, ensuring the trust check reflects the user’s actual selection. opw-5059740 Forward-Port-Of: odoo/enterprise#95124
Helpdesk team tag assignment now only lets internal users be selected as team members. This prevents portal users from being accidentally assigned to handle tickets, keeping automatic ticket dispatch aligned with staff responsibilities.
Original PR description
**Steps to Reproduce:** 1. Go to Helpdesk → Overview. 2. Open a team (e.g., 'Customer Care') and click on 'Settings'. 3. In the team settings, enable 'Automatic Assignment' → 'Dispatch tickets based on tags'. 4. Configure tags handled by team members. 5. In the 'Team Members' field, try to assign users. **Issue:** Portal users are displayed in the 'Team Members' selection list, even though they should not be assignable to helpdesk team tags. **Current behaviour:** - The 'Team Members' field shows all users, including portal users. **Expected behaviour:** - Only internal users should be selectable as 'Team Members'. - Portal users should not appear in the many2many list. **Fix:** Added a domain on the 'user_ids' field to exclude portal users from the 'Team Members' selection. **task-5093188** Forward-Port-Of: odoo/enterprise#95264
This fix ensures the main DATEV account is only assigned for companies based in Germany, preventing incorrect accounting setup for non-German companies. It also improves how debit and credit lines are gathered, making the report logic more efficient for larger records.
Original PR description
The main datev account should only be set for German companies (check for country code) Also fix the complexity of gathering the debit and credit lines: `+=` has a complexity of `O(n²)` whereas `filtered` has a complexity of `O(n)`. Forward-Port-Of: odoo/enterprise#69881
This fixes an issue where General Ledger lines using custom grouping could not be expanded to show details. Businesses using tailored report groupings can now drill into their accounting data as expected.
Original PR description
Before when we added different groupby on the gl line than the default ones, that would not be unfoldable by default. This is due to a default dict that set has_sublines to False by default and it would never be set to true for groupby other than the default ones. Forward-Port-Of: odoo/enterprise#95545
The ESG Database menu no longer offers a direct create option, reducing confusion about unsupported automatic database imports. Users can still create database records from emission factors when they need to manually classify custom 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 Forward-Port-Of: odoo/enterprise#95613
Carbon emissions calculations now convert quantities using the unit of measure expected by the emission factor, rather than the invoice line. This fixes incorrect emissions values and improves the reliability of ESG reporting.
Original PR description
Prior to this commit, the UoM conversion in the carbon emissions calculation was done by targeting the UoM of the account move line instead of the UoM of the emission factor. Which led to incorrect emissions values calculations. task-5107685 Forward-Port-Of: odoo/enterprise#95468
Invoices from Point of Sale can once again be sent directly to configured IoT printers instead of only being downloaded as PDFs. This fixes a regression and reuses the printer selection flow so printing behavior stays consistent across reports and invoices.
Original PR description
This PR contains two commits, the first is a refactoring, and the second is the invoice printing itself. - **[REF] iot: extract printer select into separate function** Before this commit, the printer…
This PR contains two commits, the first is a refactoring, and the second is the invoice printing itself.
- **[REF] iot: extract printer select into separate function**
Before this commit, the printer selection wizard was tightly coupled to
the IoT report handler, and the call to send to the printer was
duplicated in the wizard and the handler.
After this commit, the printer selection wizard is contained in a
function that will always return the selected printers directly to the
caller, whether the dialog needs to be opened or not. The wizard is
simplified as a result and the print call always occurs in the handler.
This refactoring will allow other places to use the printer selection
wizard, namely for invoice printing.
- **[FIX] pos_iot: print invoices via IoT**
In the commit https://github.com/odoo/enterprise/commit/07418d7544ceecfef38257db8f59bf845a0b0769, the invoice PDF downloading was refactored to
bypass the `ir.actions.report` model, instead working directly via an
action on the invoice model. A side effect of this is that it broke
printing invoices via the IoT, as it relies on the report printing
action to function.
To fix this, this commit introduces an override in `pos_iot` for the
`account_move_service`, which will print the invoice PDF via the IoT
instead of downloading it directly (if a printer is associated with the
report).
task-5109814
Forward-Port-Of: odoo/enterprise#95689
Forward-Port-Of: odoo/enterprise#95586Customers renting products on the website will now see the correct stock warning when availability is limited. This helps prevent confusion during checkout and reduces the risk of orders being placed without clear availability information.
Original PR description
Introduced by 151349aeaf899a3b70534a0120a5f49882981d53, the `_set_shop_warning_stock` method was modified and is now supposed to return the applied warning. Forward-Port-Of: odoo/enterprise#95731
Fixed an issue that could cause an error when users viewed the General Ledger from the Trial Balance while working with multiple selected companies. This prevents interruptions for accounting users, especially when account codes are hidden and Developer Mode is enabled.
Original PR description
**Issue** When multiple companies are selected and Developer Mode is enabled, clicking "View General Ledger" for an account in the Trial Balance leads to a traceback. This affects accounts whose code is hidden. **Steps to Reproduce** 1. Go to Accounting > Reporting > Trial Balance. 2. Select multiple companies. 3. Click on an account where the account code is not visible. 4. From the three-dot menu, select "View General Ledger". 5. Observe the traceback error. **Root Cause** The error occurs because the `AccountReportSearchBar` component expects a string `initialQuery` prop, but in the multi-company scenario with developer mode enabled, the value passed can be `undefined` or non-string. Owl's strict prop validation then throws an `OwlError`, leading to the traceback. **Fix** Ensure that `initialQuery` is always a string when passed to `AccountReportSearchBar`. Opw-5050843 Forward-Port-Of: odoo/enterprise#94104
Peruvian electronic invoices now show the invoice currency for deducted down payments instead of defaulting to the company's currency. This prevents foreign-currency invoices from displaying PEN incorrectly, reducing compliance and customer-facing document errors.
Original PR description
#### Issue: - After invoicing a downpayment in a foreign currency, in the XMl of the total invoice, the currency_id on the prepaid tag is set to PEN instead of the right currency. #### Step to…
#### Issue: - After invoicing a downpayment in a foreign currency, in the XMl of the total invoice, the currency_id on the prepaid tag is set to PEN instead of the right currency. #### Step to reproduce: 1. Install l10n_pe_edi 2. Sell a product to "Comercial Constructora los Patitos" through the sales app and make sure you use USD (or a different currency than PEN). 3. Create a downpayment invoice, could be any percentage. 4. To make sure it works correctly, add a random document number on the invoice with the format ABC-01234567. 5. Confirm this invoice. 6. Now go back to the sale order and deliver your product. 7. Create the final invoice, where the downpayment will be deducted. Make sure it is also in USD (or whatever currency you chose). 8. Confirm the invoice. #### Current behavior: - Display "PEN" in the attribute currencyID of tag PaidAmount in a PrepaidPayment: <cbc:PaidAmount currencyID=PEN> #### Expected behavior: - The currency displayed should match the invoice currency #### Cause of the issue: - the currency of the company emitting the invoice was used instead of the currency of the invoice. opw-5061019 Forward-Port-Of: odoo/enterprise#93885
This fixes a remaining source of inconsistent automated test behavior in Web Studio's rename flow. It helps keep the development and release process stable by reducing false test failures, with no expected change for end users.
Original PR description
Similar to https://github.com/odoo/enterprise/commit/5574c52df8794b3f23d385a670cac8fb5355e229 There was still one indeterminism remaining runbot-232572 Forward-Port-Of: odoo/enterprise#95447
This update corrects an internal mismatch that caused a payroll test to fail for Indian localization fields. It ensures selected employee payroll fields remain consistently editable across employee records and their version history, reducing the risk of configuration issues.
Original PR description
The test `TestHrVersion.test_related_fields_on_version` was failing with:
(Readonly) Inconsistency between some employee fields and version ones.
for the following fields:
- l10n_in_medical_insurance_total
- l10n_in_provident_fund
- l10n_in_pf_employee_percentage
- l10n_in_pf_employer_percentage
- l10n_in_fixed_allowance
Cause:
- On `hr.employee`, these fields were defined as `related='version_id.<field>'` with `readonly=False`. On `hr.version`, the same fields were still implicitly readonly (due to being computed/related), creating a mismatch.
Solution:
- Explicitly set `readonly=False` on these fields on `hr.version` as well.
[RB-232577](https://runbot.odoo.com/odoo/error/232577)
Forward-Port-Of: odoo/enterprise#94914This fixes an error that could occur when generating tax return checks for a non-empty EC Sales List with VAT number verification enabled. Businesses can now use the VAT verification option without the process failing because of duplicate check entries.
Original PR description
Create tax return checks for a non-empty EC Sales List report when the option "Verify VAT Numbers" (vat_check_vies) is enabled implies to create 2 checks with the same code (check_partner_vies). This is forbidden and raises a traceback. opw-5079474 opw-5090602 opw-5094853 opw-5103611 Forward-Port-Of: odoo/enterprise#95551
The account reports area now uses the label “Type” instead of “Category” for account return types. This fixes naming so the field better matches its purpose and reduces confusion for users working with returns.
Original PR description
Forward-Port-Of: odoo/enterprise#95183
Mexican payroll employee fields are now only visible to authorized HR payroll users. This prevents non-HR internal users from encountering access errors when viewing employee profile data and keeps payroll-related information appropriately limited.
Original PR description
The test `test_employee_fields_groups` crashed with: `AccessError: The fields "l10n_mx_regime_type,l10n_mx_shift_type, l10n_mx_payment_periodicity", which you are trying to read, are not available for employee public profiles.` These fields exist without HR group restriction as a result, a non-HR internal user calling `.read([])` triggered the `AccessError`. This commit adds `groups="hr_payroll.group_hr_payroll_user"` to these fields so they are only accessible to HR users, resolving the error. [RB-231737](https://runbot.odoo.com/odoo/error/231737)
This update adjusts a payroll-related test so it uses the right user permissions during setup. It helps keep automated checks reliable and prevents false build failures without changing business functionality.
Original PR description
to bypass the access right restriction in test build_error-230682
A naming error prevented a Mexican localization validation from running correctly after a related core function was renamed. This fix aligns the localization with the corrected function name so the intended invoice checks are active again in Odoo 19.
Original PR description
In odoo, The standard function _check_move_constraints had a typo, as it was missing the last t (_check_move_constrains). When it was inherited in this module, the function was left with the typo. In version 19, this typo was fixed in the standard function, but the Mexican localization function was left as it was, so the function was useless as it attempts to inherit a method that does not exist. In this PR, this typo is corrected so that the functionality also exists in 19. Task-id: 5119381 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#95825
ESG account assignment now only allows accounts that are appropriate for emissions tracking, reducing confusion and incorrect data entry. If an account is changed to an unsupported type, users are warned and related ESG assignment or emission data is cleaned up to keep reports accurate.
Original PR description
Before this PR, it was possible to create on the fly an account from the assignation lines list view of another type than "Expense" or "Fixed Assets". This is not desired, as this type of account is not part of the domain of the `account_id` field of the `esg.emission.factor.line` model. We prevent creation of such accounts from ESG in general, to avoid confusion and ensure data integrity. Moreover, when changing the account type of an existing account, if this one is changed to a type other than "Expense" or "Fixed Assets", we verify if there are some assignation lines linked to this account and/or journal items linked to that account. If so, we raise a warning to the user and if he wants to proceed, we remove the assignation lines linked to this account and remove the emission factors of journal entries linked to that account. task-4859806 Forward-Port-Of: odoo/enterprise#95833 Forward-Port-Of: odoo/enterprise#87295
When a user deletes a message linked to an accounting report annotation, the related annotation is now removed as well. This keeps financial report notes accurate and avoids outdated comments remaining visible after the original message is deleted.
Original PR description
And improve a bit the tour to check the result to prevent cases where the tour would pass but something wouldn't be done right. Forward-Port-Of: odoo/enterprise#95750
Code cleanup and technical improvements
IoT box setup now keeps each connection token on a draft IoT Box record instead of using one shared system value. This lets businesses connect several IoT boxes in parallel more reliably, with added tests covering the new connection flow.
Original PR description
We rewrote the iot box/db shared token logic as storing it in as a system parameter didn't allow connecting multiple iot boxes at once. We now create a draft IoT Box record storing the token, that we update with new info once the iot box with the same token calls the setup controller. Task: 5085127
The planning calendar and related portal views were rebuilt using a newer internal interaction approach. This keeps the same business workflows while making the screens easier to maintain and reducing duplicated display logic across planning, forecasting, and sales planning.
Original PR description
continue working on the refactoring introduced by this commit: [1] [1]: https://github.com/odoo/odoo/commit/dd13994674d4ef4683f5a4d46a1f604650cfb92b task-4367641
13 changes
Enhancements to existing features
Point of Sale users can now manually retry kitchen receipt printing when a printer problem caused a failure. The retry action only sends the receipt to printers that failed before, avoiding duplicate prints on printers that already succeeded.
Original PR description
Before this commit: = - There was no option to retry printing kitchen receipts if a printer failed. After this commit: = - Users can now manually retry printing kitchen receipts that failed due to printer issues. - The `Retry` button targets only the printers that previously failed, ensuring other successful prints are not repeated. Task: 4717776 Forward-Port-Of: odoo/odoo#228783 Forward-Port-Of: odoo/odoo#206432
Resolved issues and error corrections
Store pickup checkout now checks the total quantity of the same product across all cart lines, even when different units of measure are used. This prevents customers from completing checkout without a warning when a store does not have enough stock overall.
Original PR description
Steps to reproduce: 1. Enable Pickup in Store in eCommerce. 2. Create a product with multiple UoMs (e.g., Unit, Pack of Six). 3. Add the product to the cart using different UoMs in separate lines. 4. Select a store with insufficient total stock but enough for individual lines. 5. Proceed to checkout → No warning is shown. After this commit, all order lines will be taken into account when checking available stock. opw-5108294
This fixes access handling for AI tools so they run under the appropriate system-level permissions. It prevents regular users from being blocked by missing access rights when AI features rely on internal server actions.
Original PR description
Tools are server actions to which normal users don't have access. (runbot.build.error/231672)
This fix updates India-specific GST reporting methods after a prior refactor so they no longer interfere with other localizations. It helps keep Indian GST returns, e-invoicing, and related point-of-sale reporting working correctly while reducing the risk of cross-country reporting side effects.
Original PR description
Following the refactor-https://github.com/odoo/enterprise/commit/3722e9255647254a078166c5ea9696cbf7818147 and removal of `l10n_in.gst.return.period` and adapting the `account.report` since it's no longer an Indian Localisation model the method names not renamed to the localisation specific in this commit we fix that so other localisation are aren't affected
Self-order and kiosk orders paid online now appear on the preparation display only after payment is confirmed. This prevents staff from preparing unpaid orders while still ensuring paid orders reach the display even if customers leave the payment flow through an exit route.
Original PR description
pos_*= pos_online_payment_self_order_preparation_display, pos_self_order_iot Before this commit, if an online payment method was assigned to a self or a kiosk, the order was displayed on the preparation display before the payment was confirmed. After this commit, the order is no longer displayed on the preparation display until the payment confirmation. Community PR: https://github.com/odoo/enterprise/pull/87173 Backport of https://github.com/odoo/odoo/pull/87173, with additional logic to ensure the order is correctly sent to the preparation display even if an exit route is used in the payment portal Forward-Port-Of: odoo/enterprise#95583 Forward-Port-Of: odoo/enterprise#95312
The web interface no longer sends an extra date value when retrieving currency rates because the system already determines the correct date on the server. This avoids creating new cached records every day, helping control disk usage without changing user workflows.
Original PR description
The date parameter used for currency_rates fetches is removed since it is always computed server-side by default. This prevents unnecessary growth of the disk cache, which previously added at least one new entry every day.
Self-order and kiosk orders paid online now appear on the preparation display only after payment is confirmed. This prevents staff from preparing unpaid orders while still ensuring confirmed orders are sent correctly, including when customers leave through the payment portal exit flow.
Original PR description
pos_*= pos_online_payment, pos_online_payment_self_order, pos_self_order Before this commit, if an online payment method was assigned to a self or a kiosk, the order was displayed on the preparation display before the payment was confirmed. After this commit, the order is no longer displayed on the preparation display until the payment confirmation. Enterprise PR: https://github.com/odoo/enterprise/pull/95312 Backport of https://github.com/odoo/odoo/pull/213493, with additional logic to ensure the order is correctly sent to the preparation display even if an exit route is used in the payment portal --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228687 Forward-Port-Of: odoo/odoo#228189
The Spanish Mod 349 tax report now correctly shows the detailed entries behind the intra-community operations summary line during audit. This helps accounting users verify reported amounts and reduces confusion when checking EU transaction declarations.
Original PR description
Steps to reproduce: - With an ES company setup - Create 1 invoice to an EU partner - Make sure Mod349 Invoice Type is set - Go to Accounting / Reporting / Statement Reports / Tax Report - Select Tax Report (Mod 349) (ES) - Audit line 'Importe de las operaciones intracomunitarias' Issue: No line will be shown This occurs because the system will allow auditing the line, since the report line is defined as aggregation of sublines, however those sublines are all custom so we should provide a custom domain to retrieve the relevant lines opw-4752813 Forward-Port-Of: odoo/enterprise#84633
This fixes a case where resetting a Google Calendar account could fail because calendar event permission checks were still triggered. Account resets should now complete more reliably without unexpected validation errors.
Original PR description
This commit adds the last context key "skip_event_permission" to the remaining writes done to `calendar.event` records at the reset of google_calendar account, created at odoo/odoo#227991. By adding it, we'll no longer face any possibility of triggering a ValidationError during account resets of google_calendar. task-5103918 Forward-Port-Of: odoo/odoo#228520
The account reports area now labels account return types as “Type” instead of “Category.” This fixes wording so users see clearer, more accurate terminology when working with returns.
Fixes an issue where changing a website theme color from the palette could trigger an error when saving. This helps users customize website colors more reliably without interruptions.
Original PR description
This PR resolves a traceback that occurred when changing the theme color from the color palette and pressing the save button. This was due to an unhandled promise rejection. task-3919146 Forward-Port-Of: odoo/odoo#227946
This change fixes the classification of Spanish chart of accounts entry 411 so it is treated as a current liability. This helps Spanish accounting reports and bookkeeping use the correct financial category.
Original PR description
Account 411 should be of 'liability_current' type --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Closed self-ordering point-of-sale sessions now remove an unused database sequence once it is no longer needed. This helps prevent unnecessary buildup in the database and keeps maintenance lighter without changing the customer-facing checkout experience.
Original PR description
to avoid having too many postgres sequences, this make sure the sequence used by the pos session is cleaned up after being closed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229069 Forward-Port-Of: odoo/odoo#223758
9 changes
New functionality added to Odoo
Adds support for key Turkish e-invoice scenarios including withholding VAT, tax-exempt invoices, export invoices, and public sector invoices. This helps Turkish businesses meet local legal requirements and improves the invoice data sent through Nilvera, including required tax office details.
Original PR description
[ADD] l10n_tr_nilvera_einvoice_extended: Adding Nilvera E-Invoice Extension [ADD] l10n_tr_nilvera_einvoice_extended: Adding Tax Offices --- ### Description of the issue/feature this PR addresses: We…
[ADD] l10n_tr_nilvera_einvoice_extended: Adding Nilvera E-Invoice Extension [ADD] l10n_tr_nilvera_einvoice_extended: Adding Tax Offices --- ### Description of the issue/feature this PR addresses: We do not support Withholding VAT (KDV Tevkifatı), Exemption Invoices, and Export Invoices (İhracat Faturaları) with our current e-invoicing solution in Türkiye. Those invoice types are legally important and required for both domestic and international sales for businesses. In addition, the inclusion of the Tax office in our current XML we send to Nilvera, both for `<cac:AccountingSupplierParty>` and `<cac:AccountingCustomerParty>`, is required by law. This PR adds an extension module for Nilvera E-Invoicing. The purpose of this module is to extend the existing E-Invoicing functionality to support additional invoice types and scenarios to be compliant with the TR legal requirements. --- ### Invoice Scenario: **Basic** Invoice Type: - Sales - Withholding - Tax Exempt - Registered for Export **Export** Invoice Type: - Tax Exempt **Public** Invoice Type: - Sales - Withholding - Tax Exempt - Registered for Export --- ### Current behavior before PR: We don't support a scenario-based system to comply with TR legal requirements. --- ### Desired behavior after PR is merged: We support a scenario-based system to comply with TR legal requirements. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Draft restaurant bills no longer show a misleading change amount before any payment has been made. This keeps early printed bills accurate for staff and customers and avoids confusion during service.
Original PR description
steps to reproduce: ------------------ 1. Install pos_restaurant 2. Go to Settings of the Restaurant and activate Early Receipt Printing 3. Go to dashboard > open restaurant > create an order 4.…
steps to reproduce:
------------------
1. Install pos_restaurant
2. Go to Settings of the Restaurant and activate Early Receipt Printing
3. Go to dashboard > open restaurant > create an order
4. Click on Actions > Bill > Print
issue:
------
The "CHANGE" line appears on the bill print even without a payment transaction.
cause of the issue:
--------------------
The condition:
https://github.com/odoo/odoo/blob/76757158c0ce4a29883c3c52c3378218ea755a8f/addons/point_of_sale/static/src/app/models/pos_order.js#L264 is responsible to display of "CHANGE" regardless of the order state, leading to incorrect printing while the order is still in DRAFT state.
solution:
---------
Add a check to ensure the order is not in DRAFT state before printing the bill.
**NOTE:** The issue no longer exists in later versions, as it was [resolved](https://github.com/odoo/odoo/commit/e11a3489a78334ad5d3395fd405b870fa1aa218b#diff-5f6173b111795dcdfe25b1fb26d55d27e1ce9c334eabe838d413fc35c5084d1aR1034-R1036) in commit e11a348.
<details>
<summary>Click here to see:</summary>
Before fix:
<img src="https://github.com/user-attachments/assets/4acd2322-ecae-4ff8-8421-234a9d00af86"/>
After fix:
<img src="https://github.com/user-attachments/assets/02edc28b-b1c1-40aa-b478-7a3419f2e736"/>
</details>
opw-5078803
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prUsers in a newly created company without a configured warehouse will no longer hit an error when opening a product's inventory diagram. Instead, Odoo shows a clear warehouse setup warning so the user can correct the configuration and continue.
Original PR description
Currently, if a user creates a new company without configuring its warehouse, clicking 'View Diagram' raises an error. **Steps to Reproduce:** 1) Install sale_stock module.(with Demo Data) 2)…
Currently, if a user creates a new company without configuring its warehouse, clicking 'View Diagram' raises an error. **Steps to Reproduce:** 1) Install sale_stock module.(with Demo Data) 2) Navigate to Inventory>Configuration>Warehouses and create a new Warehouse. 3) Create a new company and switch to that company. 4) Navigate to Inventory>Products>Products 5) Open any product and click on 'View Diagram' in the 'inventory tab'. **Error:** `AttributeError: 'bool' object has no attribute 'origin'` **Root Cause:** On following above steps, `default_get` method is called. At [1], it attempts to fetch the ID of the warehouse. Because Odoo does not create a default warehouse for a newly created company, the value received by `res` at [2] looks like `[(6, 0, ['False'])]` which causes an error during further computation. **Fix:** Raise a `Redirect Warehouse Warning` when clicking 'View Diagram' if no warehouse is found. [1]- https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/stock/wizard/stock_rules_report.py#L35 [2]- https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/stock/wizard/stock_rules_report.py#L36 **Note**: not adding a test case, as the issue is not reproducible in test mode as default warehouse is created for a company in the test mode https://github.com/odoo/odoo/blob/de264d99c22283390d18beb7c7c62c29824f72b3/addons/stock/models/res_company.py#L197-L198 sentry-6575082178
The Partner Ledger now keeps partner names and expand arrows neatly aligned on phones and tablets. This makes the report easier to read and use on smaller devices without changing its functionality.
Original PR description
Problem: On smaller screens (phone or tablet) the center alignment between the partner name and the little arrow is broken. Cause: This happened because the little arrow has btn class, which gets larger on smaller screens (to make it easier to click). The larger button causes the center alignment to be lost, as it grows alone inside the table row. Fix: This commit fixes this issue by ensuring that the content of line_name and line_cell are vertically aligned to the middle, and that items in their sub-containers are aligned to the center. task-5106889 Forward-Port-Of: odoo/enterprise#95317
This fixes a problem where Discuss could crash if an update arrived for a call session that had already been removed. It improves reliability for users by safely ignoring outdated session updates instead of showing an error.
Original PR description
Before this commit, since a regression introduced in https://github.com/odoo/odoo/pull/228601 A traceback could occur when updating a session that does not exist. For example if the event is received after the session is removed.
The CRM periodic digest now states the correct number of free lead generation credits. This avoids misleading users by showing 20 credits instead of the incorrect 200 credits.
Original PR description
## Versions 17.0+ ## Issue The Periodic Digest contains wrong information in a tip. 20 credits are given for specific target lead generation, not 200. opw-5114252 Forward-Port-Of: odoo/odoo#228791
Customers can now choose in-store pickup for products that are out of stock when the product is configured to keep selling anyway. This prevents valid checkout options from being blocked and keeps pickup behavior aligned with store inventory settings.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Publish the "Pickup in store" delivery method; 2. have an out-of-stock product with "Continue selling" enabled; 3. go to the product's shop page; 4. add to cart; 5. try to check out using "Pickup in store" delivery method. Issue ----- Delivery method cannot be selected. Cause ----- The `website_sale_collect` module currently only checks whether the product is in stock, and not whether the product is allowed to sell when it's out of stock. Solution -------- Check the `allow_out_of_stock_order` in `_get_unavailable_order_lines` and `format_product_stock_values`, so that the `in_stock` value used to check availability is `True` iff the products are in stock or have `allow_out_of_stock_order` enabled. opw-5080295
The point of sale preparation display now shows free-text details entered on order line attributes. This helps kitchen or preparation staff see customer-specific instructions directly on the order line, reducing missed customizations.
Original PR description
draft to be updated
Customers and site editors can now press Enter while choosing or editing a product size on the shop page without triggering an error. This prevents an unexpected checkout browsing interruption and makes product option selection more reliable.
Original PR description
Before this commit: Pressing the Enter key while selecting a product size option on the /shop page crashed. After this commit: This fix ensures the Enter key is properly handled and prevents unexpected crashes during product option selection. task-4795501