Thursday, January 29, 2026
15 changes · saas-18.4
Resolved issues and error corrections
Loyalty coupon barcodes printed on Point of Sale receipts are now wider. This makes next-order coupon receipts easier to scan, reducing checkout friction for staff and customers.
Original PR description
Step to reproduce; - install pos_loyalty - create a loyalty program of type "next order coupon" with minimum spend of 1$. - open pos and settle a order, see receipt. Issue: - currently bar-code is too narrow, making it difficult for to be scanned Fix: - increase the width of barcode, so it can be easily scanned. <table> <tr> <td> <b>Before</b> </td> <td> <b>After</b> </td> </tr> <tr> <td> <img width="451" height="508" alt="image" src="https://github.com/user-attachments/assets/a0d1e95e-0a9d-4552-977a-0ad9686867b8" /> </td> <td> <img width="456" height="517" alt="image" src="https://github.com/user-attachments/assets/40d04ac4-9ffc-4f81-a063-31b3ea26b4e1" /> </td> </tr> </table> opw-5363916 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244353 Forward-Port-Of: odoo/odoo#242469
This fix lets users duplicate existing skills in the HR Skills app without triggering a validation error. It removes a workflow blocker for HR teams maintaining or reusing skill records.
Original PR description
Version: - saas-18.2 Steps to reproduce: - Install the hr_skills module - Go to the Skills menu - Select a skill and click Duplicate Issue: - A validation error appears when duplicating a skill Solution: - Updated the copy_data method so skills can be duplicated without causing a validation error Task - 5481185 Forward-Port-Of: odoo/odoo#243227
This fix prevents the Point of Sale loyalty flow from crashing when a cashier cancels the setup of a configurable product after selecting a customer. It keeps the sales screen stable and avoids disruption during in-store transactions.
Original PR description
Steps to reproduce: = - Open a PoS with pos_loyalty - Set a customer - Open a configurable product - Click `Discard` button or press `ESC` key Issue: = - A traceback occurs with the error: `TypeError: Cannot read properties of undefined (reading 'product_id')` Reason: = - When a configurable product is discarded during variant selection, the flow continues and attempts to process an undefined product. Fix: = - Ensure if adding a configurable product is discarded while selecting variant it should not p[roccess futher. task-5481204 Forward-Port-Of: odoo/odoo#243996
This update adjusts an internal test for the PDF quote builder so it uses a realistic encrypted PDF file instead of placeholder data. This prevents unnecessary PDF warning messages during automated builds, helping keep release checks reliable without changing customer-facing functionality.
Original PR description
The `test_wrong_pdf` test fails on runbot in the `Nightly build` when executed under `Distro Builds > Testing distro PureTrixie without requirements for config Parallel testing`. **Steps to…
The `test_wrong_pdf` test fails on runbot in the `Nightly build` when executed under `Distro Builds > Testing distro PureTrixie without requirements for config Parallel testing`. **Steps to reproduce:** - Install `sale_pdf_quote_builder` module. - Run `test_wrong_pdf` (Make sure `PyPDF==5.4.0` is installed). - Observe `PyPDF` warnings in the logs. **Warnings:** ``` WARNING server pypdf._reader:435 invalid pdf header: b'test' WARNING server pypdf._reader:435 EOF marker not found WARNING server pypdf._reader:435 EOF marker not found ``` **Root cause:** Odoo officially supports the PyPDF version defined in requirements.txt [1]. The test passes with `PyPDF2`, but `PyPDF` is stricter and emits warnings when parsing arbitrary byte content. Because the test uses raw bytes instead of a structurally valid (but unsupported or encrypted) PDF, PyPDF logs warnings. **Fix:** This commit updates the test to use a real encrypted PDF instead of raw bytes, similar to [2]. This commit fixes test failures caused by [3]. **Note:** Refer to [4] for generating the encrypted file. [1]: https://github.com/odoo/odoo/blob/a6af7df429f9cd3bfb60347e9b30cc48fb5bfaff/requirements.txt#L63-L65 [2]: https://github.com/odoo/odoo/blob/0499dbd8944b4002883afab5d3ed76d8e55dab9c/addons/mail/tests/discuss/test_discuss_attachment_controller.py#L63-L75 [3]: https://github.com/odoo/odoo/pull/230712 [4]: https://colab.research.google.com/drive/1UfWSKDluObEkKxCg6eX-nHoe04_FGrEq#scrollTo=A5hO11Eh1qvV runbot-238399 Forward-Port-Of: odoo/odoo#246034
The signing flow now correctly prevents customers from accepting and signing a sales order when the Full Name field is empty or only spaces. This avoids incomplete signature submissions and makes the checkout/signature validation behave as expected.
Original PR description
**Steps to produce:** - Install `sale_management` module. - `Create a SO > Click on Preview > Sign and Pay`. - Remove all text from the Full Name`. **Issue:** - The `Accept & Sign` button remains…
**Steps to produce:** - Install `sale_management` module. - `Create a SO > Click on Preview > Sign and Pay`. - Remove all text from the Full Name`. **Issue:** - The `Accept & Sign` button remains enabled even when the Full Name field is empty. **Root cause:** - At [1], When the `drawCurrentName` method is called, it retrieves text using `getCleanedName`. This method returns an empty string when no name is provided - Despite this, the code still generates an image and passes it to `printImage`, which keeps the button enabled. **Solution:** - If the cleaned name is empty or contains only spaces, do not generate image. - Instead, immediately clear the signature pad so the button remains disabled. [1]https://github.com/odoo/odoo/blob/9dedf75810bd6b7a92fe5bd279bf6bae98834750/addons/web/static/src/core/signature/name_and_signature.js#L103-L109 **Before:** <img width="400" height="400" alt="before" src="https://github.com/user-attachments/assets/5ebdf852-4cba-4e1d-9ae4-7373e4b8b91d" /> **After:** <img width="400" height="400" alt="after" src="https://github.com/user-attachments/assets/9280aa66-4f22-40d6-8a22-326cec24378d" /> **opw-5361890** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238638
Purchase orders now show product attributes and values in the vendor's language when products are added through the variant grid, including attributes configured to never create variants. This avoids confusing untranslated product details on purchase documents for multilingual suppliers.
Original PR description
When adding a product with never variant, their name and values are not translated in the language of the partner. ### Steps to reproduce: * Activate the setting Variants and Variant Grid Entry. *…
When adding a product with never variant, their name and values are not translated in the language of the partner. ### Steps to reproduce: * Activate the setting Variants and Variant Grid Entry. * Create a product , add a translation for its name. * Create a attribute and a translation for its name, with variant creation set to never. * Create values for the attribute and add translation for their name. * Add the attribute and it's values to the product . * Create a contact and change it's language to the language of the translation. * Create a purchase order set the contact as the vendor * Add the product, and set the grid number to 1 -> the attribute and attribute value is not translated. ### Observation: When adding a product via the variant grid, the attribute and value names are added. For other attribute creation types, this information is retrieved directly from the product: https://github.com/odoo/odoo/blob/f95bcc097fd7e70af8d28a66c010ae9b9490f439/addons/purchase/models/purchase_order_line.py#L283-L288 But in case of never attribute, the name it retrieved after and we don't set the context: https://github.com/odoo/odoo/blob/f95bcc097fd7e70af8d28a66c010ae9b9490f439/addons/purchase_product_matrix/models/purchase.py#L173-L174 -> we retrieve the information but in the wrong language opw-5396058 Forward-Port-Of: odoo/odoo#242692
Updating shipping costs on a sales order now correctly opens the wizard with the existing shipping carrier already selected. This prevents confusion and extra manual selection for users managing delivery charges.
Original PR description
### Current behavior: When updating shipping costs on a Sales Order, the delivery wizard opens with an empty carrier field. This happens because a recordset is passed to the context instead of an integer ID, causing the web client to fail the auto-population. ### Expected behavior: The wizard should automatically select the Sales Order's current carrier as the default carrier_id ### Steps to reproduce: - Add a shipping method to a Sales Order. - Click "Update shipping cost". - Observe the carrier field in the wizard is empty. ### Fix: Pass `self.carrier_id.id `as an integer in the action context instead of the recordset object. Caused by this commit: https://github.com/odoo/odoo/pull/203955/changes/651dd4313cf23105675249d569affee7b756cd3c Backport of: https://github.com/odoo/odoo/pull/242867 opw-5890258
When a Peppol participant is reported as no longer available, the system now also archives the related proxy user during the reset. This prevents stale registration data from blocking the customer from registering again.
Original PR description
Currently, if the participant_status gets a client_gone, we call the _reset_peppol_configuration method. But while we reset, we don't archive the proxy_user. We should do so, so the user can re-register --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246261
Sending customer invoices through Peppol now reuses and updates existing invoice attachments instead of creating extra copies. This keeps the invoice chatter and attachment list cleaner, making it easier for users to find the right documents.
Original PR description
When sending a customer invoice via Peppol, the system creates duplicate attachments (4 instead of 2 expected), cluttering the chatter and the attachment sidebar. This commit: - Implements a search-and-update logic for attachments to ensure idempotency (updates existing instead of creating duplicates). task-5438951 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#245370 Forward-Port-Of: odoo/odoo#241130
This update fixes an unreliable automated check for the sales signature flow. It helps ensure the test runs consistently whether the signature page opens inside an embedded frame or directly on the page, reducing false failures in validation.
Original PR description
This commit fixes an indeterministic sign tour that could run either inside an iframe or directly in the main page. Since the execution context was unpredictable, both selectors were added to handle both cases reliably. runbot error-238443 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Manufacturing order cards now keep quantity and unit information readable even when product names are very long. This prevents important production details from being squeezed on the kanban view, improving day-to-day usability for manufacturing teams.
Original PR description
Description of the issue/feature this PR addresses: On MRP production kanban, if the name of the product is too long, `product_qty` and `product_uom_id` fields on the card shrink and become unreadable. This adds proper classes to keep those fields from shrinking no matter how long product's name is. Current behavior before PR: <img width="1561" height="303" alt="image" src="https://github.com/user-attachments/assets/08e299be-c6e2-4241-b289-aaa2fab9a94f" /> Desired behavior after PR is merged: - The size of the product's name should be fine no matter how long the name of the product is. - The `product_qty` and `product_uom_id` should not shrink if the name of the product is long. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245861
This fix makes automated website tests wait until page interactions are fully ready before running. It reduces false test failures around popup behavior, helping keep website changes safer and more predictable without changing the customer-facing product.
Original PR description
__Before commit__ Hoot tests using interactions inside the iframe may fail because we do not wait for the interaction service to be ready before executing the tests. In particular, the `SharedPopup` interaction is sometimes started after we trigger a click to display it in the test. Since it has not had time to register the proper listener, the `d-none` class is never removed from the popup, so the test is stuck waiting for it to appear. __Fix__ When the JavaScript assets are included inside the iframe, the attribute `is-ready` is added to the iframe body. In this case, we wait for it to appear instead of uselessly adding it artificially. Waiting for all interactions to load may take a bit of time, so a large timeout is set to wait for the `is-ready` attribute. The timeouts inside the tests are now removed since they were there to fix this bug without success. runbot-237554
This update corrects a technical issue preventing invoices from successfully validating with DIAN, Colombia's tax authority. The fix involves updating a specific tag format within the invoice XML files to match DIAN's requirements. This ensures invoices are properly processed and avoids validation errors.
Original PR description
Problem: When validating invoices with DIAN, an error is received. Cause: Incorrect tags are being used in the invoices. These tags are checked when invoices are validated with DIAN. Solution: Use the correct tags in the invoices. schemeName should be used instead of scheme_name. Steps to reproduce: - Install l10n_co_dian module - Choose a Colombian company - Activate DIAN service in Settings - Create an invoice and send it while making sure the DIAN checkbox is ticked - Download the generated zip file and uncompress - Open the XML file and check for scheme_name. It should be replaced by schemeName. opw-5829958 Forward-Port-Of: odoo/enterprise#105659
This update fixes a bug that prevented automatic reconciliation when an invoice's reference matched its payment reference. Previously, the system blocked the match, requiring manual intervention. Now, the system correctly identifies and automatically reconciles invoices with matching payment references, improving accounting efficiency.
Original PR description
The aim of this commit is to make the automatic reconciliation works in case of an obvious matching that was prevented because the reference of the invoice was also it's payment reference. It also…
The aim of this commit is to make the automatic reconciliation works in case of an obvious matching that was prevented because the reference of the invoice was also it's payment reference. It also modify a docstring of a test because it was lying about what it was really testing. The usecase it says it forbid is actually enforced by `test_matching_algorithm_for_multiple_invoices`. Before this commit: - functionally: The obvious matching was denied and the accountant had to manually make the match. - technically: The `aml.ref` and the `move.payment_reference` were the exact same and thus postgres regrouped the invoice (through aml) with itself as if there were 2 invoices matching the same word. After this commit: - functionally: The obvious match is made. - technically: The initial intend was to avoid having several invoices (proxy by amls) reported for a specific matching word preventing the system to take a difficult and arbitrary functional decision which might be wrong. In order to comply with that and to not block the match of an invoice that would be matched through several matching words, we don't gather twice the same aml for the same word. task-id: None (The issue arose on odoo.com and was brought by APFA) Forward-Port-Of: odoo/enterprise#105648
This update fixes a minor issue where payment links were sometimes displayed even when the subscription was expired and certain products were archived. Now, the 'Pay Now' link only appears if the advance payment section is visible, ensuring a cleaner and more accurate user experience for subscription renewals.
Original PR description
When the subscription is expired and has to be paid, only use an anchor for `Pay Now` if the advance payment section is displayed (it could be hidden for ex. if any of the product has been archived) Forward-Port-Of: odoo/enterprise#105802 Forward-Port-Of: odoo/enterprise#105480