Friday, April 11, 2025
12 changes · 17.0
Resolved issues and error corrections
Updating or reloading a German accounting plan will no longer trigger an error when the relevant value has not actually changed. This prevents unnecessary interruptions during routine localization template updates while preserving validation when a meaningful change occurs.
Original PR description
Description of the issue/feature this PR addresses: If we try to reload the template, an error is raised. So, we will raise the error if the change has some meaning Current behavior before PR: an Error is raised when updating a German plan Desired behavior after PR is merged: no Error is raised @alialfie --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Updating a product's on-hand quantity no longer leaves the related inventory adjustment line incorrectly marked with a warning. This prevents unnecessary confusion for users reviewing stock adjustments while preserving the correct quantity behavior.
Original PR description
Before this PR, Setting the on-hand quantity from the product form would correctly set the product's quantity but also reset the inventory quantity to 0. While this behavior is correct,it caused a…
Before this PR, Setting the on-hand quantity from the product form would correctly set the product's quantity but also reset the inventory quantity to 0. While this behavior is correct,it caused a line decoration warning to appear in the Inventory Adjustment tree view. Steps to Reproduce =================== - Create a storable, non-tracked product. - Update its quantity by clicking the "Update Quantity" button, ensuring multi-location is disabled. - Go to Inventory Adjustment and locate the newly created product. The inventory quantity is correctly set to 0, but it is highlighted with a warning. Issue ====== Although the inventory quantity is correctly set to 0, the `inventory quantity set` field is not reverted, causing the line decoration warning to appear. This commit resolves the issue by using an existing method that clears the inventory quantity and sets the `inventory quantity set` field to false. task: [4579053](https://www.odoo.com/odoo/my-tasks/4579053)
This fixes validation for older Ivory Coast phone numbers so they are handled correctly. It helps prevent valid customer or contact numbers from being rejected in Odoo.
Original PR description
Work in progress, more info in task opw-4046869 task-[4314235](https://www.odoo.com/odoo/all-tasks/4314235) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a visual issue in the website editor where selecting a tab character could make the blue selection highlight spill outside its intended space. The change keeps the highlight aligned with the tab width, improving editing clarity without changing content or workflows.
Original PR description
Problem: The inner content (text) of `oe-tabs` can be larger than the `span` itself, causing the selection to visually overflow outside the tab. Solution: Set `tab-size` to match `width` for `oe-tabs` to prevent the selection overflow. Steps to reproduce: 1. Add a tab between some text in the editor. 2. Select only the tab. 3. Notice that the selection (blue highlight) visually overflows outside the tab. opw-4711458 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Website templates from the Subscriptions app are now properly included in the website translation loading process. This ensures customers see subscription-related website text in their selected language instead of untranslated content.
Original PR description
The `sale_subscription` module defines a template used on the website, but it was not marked as being a frontend module. Therefore the translations were not loaded on the website and the template was never translated. In this commit we add this module to the frontend modules, so its templates displayed on the website are properly translated.
Fixed a report layout issue where timesheets linked only to helpdesk tickets did not show ticket names, causing columns to appear misaligned. This makes printed timesheet reports clearer and more reliable when reviewing helpdesk-related work.
Original PR description
Steps to reproduce: - install helpdesk_timesheet - Go to `Timesheets` - Select ticket-linked timesheets only. - print report. Issue: - Tickets names are not rendered on the report, causing misalignment. Fix: - Updated condition to display table cell based on task, project, or ticket visibility task-4476391
Miscellaneous changes
country_code has to be defined. Required field from Adyen. Falling back to the company country code or NL if the partner country is empty. opw-4698444 Forward-Port-Of: odoo/odoo#205678
Original PR description
country_code has to be defined. Required field from Adyen. Falling back to the company country code or NL if the partner country is empty. opw-4698444 Forward-Port-Of: odoo/odoo#205678
Versions -------- - 16.0+ Steps ----- 1. Install `website_sale_loyalty` with default configuration; 2. add a payment provider; 3. as a public user, buy a gift card via eCommerce. Issue ----- No email is sent with the gift card's code to the provided email address. Cause ----- The email template doesn't have an `email_from` field added. Without this value, it falls back on the current user, but because we're Public User, this also doesn't have an `email` value. Additionally,
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Install `website_sale_loyalty` with default configuration; 2. add a payment provider; 3. as a public user, buy a gift card via eCommerce. Issue ----- No email is sent with the gift card's code to the provided email address. Cause ----- The email template doesn't have an `email_from` field added. Without this value, it falls back on the current user, but because we're Public User, this also doesn't have an `email` value. Additionally, if the order gets confirmed as a portal user, the email will be sent from the client's email address. Solution -------- Add a `_get_mail_author` hook to `loyalty.card`, which can be used when an email template lacks an `email_from` value. Mail author precedence for cards without an order: - current internal user > card's company > current company Mail author precedence for cards with an order: - salesperson > order's company opw-4687107 Forward-Port-Of: odoo/odoo#204644
Account 466 isn't in common template, it's only in full template but in Plan General Contable published by BOE (https://www.boe.es/biblioteca_juridica/publicacion.php?id=PUB-PB-2024-227) and also in the last update of Plan General Contable as of 12/21/2024 (https://www.boe.es/buscar/act.php?id=BOE-A-2007-19884&tn=1&p=20241221), the account 466 is inside normal models and abbreviated models. @moduon MT-9401 @rafaelbn @gelojr --- I confirm I have signed the CLA and read the PR guid
Original PR description
Account 466 isn't in common template, it's only in full template but in Plan General Contable published by BOE (https://www.boe.es/biblioteca_juridica/publicacion.php?id=PUB-PB-2024-227) and also in the last update of Plan General Contable as of 12/21/2024 (https://www.boe.es/buscar/act.php?id=BOE-A-2007-19884&tn=1&p=20241221), the account 466 is inside normal models and abbreviated models. @moduon MT-9401 @rafaelbn @gelojr --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202100
Previously, the round-off amount was not being included in the E-Way Bill request when sending invoices from Odoo. This caused inconsistencies between the generated invoice and the data sent to the E-Way Bill portal. This commit ensures that the round-off amount is properly accounted for in the request, maintaining consistency between the invoice and the E-Way Bill data. opw-4708955 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port
Original PR description
Previously, the round-off amount was not being included in the E-Way Bill request when sending invoices from Odoo. This caused inconsistencies between the generated invoice and the data sent to the E-Way Bill portal. This commit ensures that the round-off amount is properly accounted for in the request, maintaining consistency between the invoice and the E-Way Bill data. opw-4708955 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205522
Commits fc49984a and 2644a63b introduced changes to: - Prevent rejections for invoices older than 72 hours (error 301). - Use the correct partner/branch timezone when generating the CFDI. However, these changes also cause each re-stamping attempt to use the current timestamp, resulting in duplicates on the SAT if the first attempt times out or is lost (e.g., due to a disconnection). The PAC sees each request as a distinct CFDI if there is even a slight difference in the timestamp. This f
Original PR description
Commits fc49984a and 2644a63b introduced changes to: - Prevent rejections for invoices older than 72 hours (error 301). - Use the correct partner/branch timezone when generating the CFDI. However,…
Commits fc49984a and 2644a63b introduced changes to:
- Prevent rejections for invoices older than 72 hours (error 301).
- Use the correct partner/branch timezone when generating the CFDI.
However, these changes also cause each re-stamping attempt to use the current timestamp, resulting in duplicates on the SAT if the first attempt times out or is lost (e.g., due to a disconnection). The PAC sees each request as a distinct CFDI if there is even a slight difference in the timestamp.
This fix ensures that the same emission timestamp (stored in `l10n_mx_edi_post_time`) is reused for subsequent stamping attempts, producing an identical XML and preventing duplicates on the SAT.
Steps to reproduce the original issue:
1. Create and confirm an invoice.
2. Stamp the invoice.
3. Manually set the EDI status to “to_send”: ```python record.edi_document_ids.write({"state": "to_send"}) ```
4. Stamp again without persisting the emission timestamp => a new CFDI is generated.
Expected result after the fix:
- The system reuses the same emission timestamp (l10n_mx_edi_post_time) for each attempt, preventing duplicate CFDIs on the SAT.
According to the [SAT
documentation](http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Anexo_20_Guia_de_llenado_CFDI.pdf)
the attribute `Fecha` must be the expedition date.
Forward-Port-Of: odoo/enterprise#81882…e Sheet for Asociations Under the current legislation the account 466 must be in the report "Balance Abreviado". https://www.boe.es/buscar/act.php?id=BOE-A-2007-19884&tn=1&p=20210130 https://www.boe.es/buscar/act.php?id=BOE-A-2011-18458 https://www.odoo.com/es_ES/my/tasks/4318054 @moduon MT-8852 Forward-Port-Of: odoo/enterprise#80749
Original PR description
…e Sheet for Asociations Under the current legislation the account 466 must be in the report "Balance Abreviado". https://www.boe.es/buscar/act.php?id=BOE-A-2007-19884&tn=1&p=20210130 https://www.boe.es/buscar/act.php?id=BOE-A-2011-18458 https://www.odoo.com/es_ES/my/tasks/4318054 @moduon MT-8852 Forward-Port-Of: odoo/enterprise#80749