Daily updates from Odoo
Navigate
Branch
Saturday, November 8, 2025
21 changes
4 changes
Resolved issues and error corrections
This update corrects how credit note amounts are prepared for Taiwan ECPay submissions. It prevents mismatches between the credit note total and the original invoice amount when the invoice has already been paid, avoiding API errors during sending.
Original PR description
When invoice is reconciled and credit note is issued, amount_residual_signed is not zero. By doing sale_amount += self.amount_residual_signed, TotalAmount is not match with the original sale amount and ECPay API returns error. task-5230384 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#234468
This fix ensures the printed Carta Porte uses the same CCP ID already sent and approved in the official CFDI document. As a result, the PDF and QR code stay consistent across printouts, avoiding confusion and compliance issues.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_mx_edi_stock_30 - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - In Accounting settings, select "Solucion Factible" as PAC - Create a…
**Steps to reproduce:** - Install Accounting and l10n_mx_edi_stock_30 - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - In Accounting settings, select "Solucion Factible" as PAC - Create a product: * Product Name: XYZ * Product Type: Storable Product * UNSPSC Category: 25101929 Mobile office van * Tariff Fraction: 0101299999 Los demás. * UMT Aduana: Units * Weight: 1.00 - Go to "Inventory / Operations / Transfers / Deliveries" - Create a delivery: * Delivery Address: [a Mexican contact] (e.g. INMOBILIARIA CVA) * Product: Product XYZ * Transport Type: Federal Transport * Vehicle Setup: [something] (e.g. [ABC123] DEMOPERMIT) * Gross Vehicle Weight: [anything] * Distance to Destination (KM): [anything] - Validate the delivery - Generate Delivery Guide => CFDI document should be created and signed by the government - Print Carta Porte **Issue:** The "CCP ID" in the PDF is different than the one in the CFDI sent to the government. Each time the Carta Porte is printed, a new "CCP ID" is generated and use in the PDF. This also leads to a different QR-code in each PDF. **Cause:** When the Carta Porte is printed, instead of fetching the data from the existing CFDI document, they are recomputed. The problem is that "l10n_mx_edi_idccp" field is a non-stored computed field and its value is a RFC 4122 identifier. Each time the compute method is called, a new identifier is generated. **Solution:** When printing the Carta Porte, retrieve "CCP ID" from the existing CFDI document. opw-5208648 Forward-Port-Of: odoo/enterprise#99034 Forward-Port-Of: odoo/enterprise#98920
This change corrects how Peppol verification updates are saved so related values are written together instead of separately. It prevents inconsistent partner data from being produced, avoiding validation errors during Peppol checks.
Original PR description
In some cases, when doing two consequent writes instead of one batch, the ORM will trigger the dependencies needlessly, and it can end up to discrepancies like: EAS=0208, endpoint=BE... which lead to a validation error. opw-5228670 opw-5225590 opw-5228716 opw-5229057 opw-5232276 Forward-Port-Of: odoo/odoo#234740 Forward-Port-Of: odoo/odoo#234290
This update prevents an error that could appear when a browser’s service worker for Odoo is manually removed and push notifications are re-enabled. It makes the notification setup more reliable so users are less likely to see a failure message when refreshing the page.
Original PR description
When you manually unregister the ServiceWorker linked to your Odoo,
you may receive a notification "Failed to enable push notifications".
This occurs because the ServiceWorker associated with the previous
subscription is gone and the browser has lost the link between the
subscription and the Odoo instance.
To handle this case, we ensure waiting the activated state of the
registration of the service worker before subscribing to the web push
notification.
Steps to reproduce:
- In Odoo, enable push notifications.
- Inside another tab, go to the internal Chrome URL:
chrome://serviceworker-internals/?devtools
- Unsubscribe the ServiceWorker linked to your Odoo instance.
- In the Odoo instance tab, press F5.
=> You will see an internal notification stating
"Failed to enable push notifications" => BUG.
Forward-Port-Of: odoo/odoo#235039
Forward-Port-Of: odoo/odoo#2349306 changes
Resolved issues and error corrections
This change fixes the printed Carta Porte so its CCP ID and QR code always match the official CFDI already sent to the government. It prevents a new identifier from being generated each time the document is printed, ensuring the printed copy stays consistent and reliable.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_mx_edi_stock_30 - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - In Accounting settings, select "Solucion Factible" as PAC - Create a…
**Steps to reproduce:** - Install Accounting and l10n_mx_edi_stock_30 - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - In Accounting settings, select "Solucion Factible" as PAC - Create a product: * Product Name: XYZ * Product Type: Storable Product * UNSPSC Category: 25101929 Mobile office van * Tariff Fraction: 0101299999 Los demás. * UMT Aduana: Units * Weight: 1.00 - Go to "Inventory / Operations / Transfers / Deliveries" - Create a delivery: * Delivery Address: [a Mexican contact] (e.g. INMOBILIARIA CVA) * Product: Product XYZ * Transport Type: Federal Transport * Vehicle Setup: [something] (e.g. [ABC123] DEMOPERMIT) * Gross Vehicle Weight: [anything] * Distance to Destination (KM): [anything] - Validate the delivery - Generate Delivery Guide => CFDI document should be created and signed by the government - Print Carta Porte **Issue:** The "CCP ID" in the PDF is different than the one in the CFDI sent to the government. Each time the Carta Porte is printed, a new "CCP ID" is generated and use in the PDF. This also leads to a different QR-code in each PDF. **Cause:** When the Carta Porte is printed, instead of fetching the data from the existing CFDI document, they are recomputed. The problem is that "l10n_mx_edi_idccp" field is a non-stored computed field and its value is a RFC 4122 identifier. Each time the compute method is called, a new identifier is generated. **Solution:** When printing the Carta Porte, retrieve "CCP ID" from the existing CFDI document. opw-5208648 Forward-Port-Of: odoo/enterprise#99034 Forward-Port-Of: odoo/enterprise#98920
This update corrects how credit note totals are prepared before being sent to ECPay. It prevents mismatched amounts when the original invoice has already been paid, avoiding API errors and ensuring credit notes can be transmitted successfully.
Original PR description
When invoice is reconciled and credit note is issued, amount_residual_signed is not zero. By doing sale_amount += self.amount_residual_signed, TotalAmount is not match with the original sale amount and ECPay API returns error. task-5230384 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#234468
This update fixes an issue where vendor credit notes could be rejected by MyInvois when the original bill had a custom reference. The system now uses the reference stored with the submitted e-invoice, helping ensure the reversal document matches what the tax authority expects.
Original PR description
Currently, customers get an error when trying to send the vendor credit note to MyInvoise if a reference has been set on the bill. ``` The validation failed with the following errors: The reference…
Currently, customers get an error when trying to send the vendor credit note to MyInvoise if a reference has been set on the bill. ``` The validation failed with the following errors: The reference document UUID [...] does not exist. The internal ID for DocumentUUID [...] does not match. ``` Steps to reproduce: - With an MY company setup - Create a bill and add a custom reference - Send Bill to MyInvois - Create credit note for the Bill - Send Credit note to MyInvoice Issue: Validation will fail because the reference does not match. In the reverse bill we always send the original bill name as original bill id, but also the reference could have been used. Analysis: A solution would be to send always the reference of the original vendor bill if present. However, the bill reference may be altered after submitting the e-invoice. A safer way is to retrieve the reference from the stored e-invoice. opw-5057050 Forward-Port-Of: odoo/odoo#234762 Forward-Port-Of: odoo/odoo#234199
This change prevents an internal error that could appear when a browser’s service worker for Odoo is manually removed. It makes push notifications reconnect more reliably, so users are less likely to see a failed notification message after refreshing the page.
Original PR description
When you manually unregister the ServiceWorker linked to your Odoo,
you may receive a notification "Failed to enable push notifications".
This occurs because the ServiceWorker associated with the previous
subscription is gone and the browser has lost the link between the
subscription and the Odoo instance.
To handle this case, we ensure waiting the activated state of the
registration of the service worker before subscribing to the web push
notification.
Steps to reproduce:
- In Odoo, enable push notifications.
- Inside another tab, go to the internal Chrome URL:
chrome://serviceworker-internals/?devtools
- Unsubscribe the ServiceWorker linked to your Odoo instance.
- In the Odoo instance tab, press F5.
=> You will see an internal notification stating
"Failed to enable push notifications" => BUG.
Forward-Port-Of: odoo/odoo#235005
Forward-Port-Of: odoo/odoo#234930This change corrects how Peppol verification updates are applied when several fields are written in sequence. It prevents inconsistent data from being temporarily created, which could otherwise cause validation errors for some partners.
Original PR description
In some cases, when doing two consequent writes instead of one batch, the ORM will trigger the dependencies needlessly, and it can end up to discrepancies like: EAS=0208, endpoint=BE... which lead to a validation error. opw-5228670 opw-5225590 opw-5228716 opw-5229057 opw-5232276 Forward-Port-Of: odoo/odoo#234581 Forward-Port-Of: odoo/odoo#234290
Editing a message with the ArrowUp shortcut now restores previously mentioned channels, just like using the Edit action. This keeps message edits consistent and helps prevent mentions from being accidentally lost.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ When editing a message via the ArrowUp shortcut, any previously mentioned channels (e.g., `#general`)…
**Description of the issue this PR addresses:** ------------------------------------------------ When editing a message via the ArrowUp shortcut, any previously mentioned channels (e.g., `#general`) were not restored in the composer. This happened because the logic to restore mentions was only applied in the `onClick()` handler of the Edit message action. **Current behavior before PR:** --------------------------------- - Editing a message using ArrowUp does not restore mentioned channels - Editing via the Edit message action still works correctly **Desired behavior after PR is merged:** ----------------------------------------- - Mentioned channels are restored when entering edit mode via ArrowUp - Behavior is consistent with editing through the Edit message action - No mentions are lost in any edit scenario **Important: This PR should only be merged for versions saas-18.2, saas-18.3, and saas-18.4.** **Backport of https://github.com/odoo/odoo/pull/229546/commits/5878e398615596adcf09eef8acbbe5aa739918f3** **Task:** 5133698 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231192
1 change
Resolved issues and error corrections
This update ensures the CCP ID shown in the printed Carta Porte stays the same as the one already submitted to the government. It prevents a new identifier and QR code from being generated each time the document is printed, avoiding confusion and mismatched records.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_mx_edi_stock_30 - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - In Accounting settings, select "Solucion Factible" as PAC - Create a…
**Steps to reproduce:** - Install Accounting and l10n_mx_edi_stock_30 - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - In Accounting settings, select "Solucion Factible" as PAC - Create a product: * Product Name: XYZ * Product Type: Storable Product * UNSPSC Category: 25101929 Mobile office van * Tariff Fraction: 0101299999 Los demás. * UMT Aduana: Units * Weight: 1.00 - Go to "Inventory / Operations / Transfers / Deliveries" - Create a delivery: * Delivery Address: [a Mexican contact] (e.g. INMOBILIARIA CVA) * Product: Product XYZ * Transport Type: Federal Transport * Vehicle Setup: [something] (e.g. [ABC123] DEMOPERMIT) * Gross Vehicle Weight: [anything] * Distance to Destination (KM): [anything] - Validate the delivery - Generate Delivery Guide => CFDI document should be created and signed by the government - Print Carta Porte **Issue:** The "CCP ID" in the PDF is different than the one in the CFDI sent to the government. Each time the Carta Porte is printed, a new "CCP ID" is generated and use in the PDF. This also leads to a different QR-code in each PDF. **Cause:** When the Carta Porte is printed, instead of fetching the data from the existing CFDI document, they are recomputed. The problem is that "l10n_mx_edi_idccp" field is a non-stored computed field and its value is a RFC 4122 identifier. Each time the compute method is called, a new identifier is generated. **Solution:** When printing the Carta Porte, retrieve "CCP ID" from the existing CFDI document. opw-5208648 Forward-Port-Of: odoo/enterprise#99034 Forward-Port-Of: odoo/enterprise#98920
1 change
Resolved issues and error corrections
Printing a Mexican Carta Porte now uses the CCP ID from the already signed government CFDI instead of generating a new one. This keeps the printed PDF and QR code consistent with the official document, reducing compliance confusion and reprint discrepancies.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_mx_edi_stock_30 - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - In Accounting settings, select "Solucion Factible" as PAC - Create a…
**Steps to reproduce:** - Install Accounting and l10n_mx_edi_stock_30 - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - In Accounting settings, select "Solucion Factible" as PAC - Create a product: * Product Name: XYZ * Product Type: Storable Product * UNSPSC Category: 25101929 Mobile office van * Tariff Fraction: 0101299999 Los demás. * UMT Aduana: Units * Weight: 1.00 - Go to "Inventory / Operations / Transfers / Deliveries" - Create a delivery: * Delivery Address: [a Mexican contact] (e.g. INMOBILIARIA CVA) * Product: Product XYZ * Transport Type: Federal Transport * Vehicle Setup: [something] (e.g. [ABC123] DEMOPERMIT) * Gross Vehicle Weight: [anything] * Distance to Destination (KM): [anything] - Validate the delivery - Generate Delivery Guide => CFDI document should be created and signed by the government - Print Carta Porte **Issue:** The "CCP ID" in the PDF is different than the one in the CFDI sent to the government. Each time the Carta Porte is printed, a new "CCP ID" is generated and use in the PDF. This also leads to a different QR-code in each PDF. **Cause:** When the Carta Porte is printed, instead of fetching the data from the existing CFDI document, they are recomputed. The problem is that "l10n_mx_edi_idccp" field is a non-stored computed field and its value is a RFC 4122 identifier. Each time the compute method is called, a new identifier is generated. **Solution:** When printing the Carta Porte, retrieve "CCP ID" from the existing CFDI document. opw-5208648 Forward-Port-Of: odoo/enterprise#99034 Forward-Port-Of: odoo/enterprise#98920
5 changes
Resolved issues and error corrections
This update corrects how credit notes are prepared for ECPay so the total amount matches the original invoice even after payment reconciliation. It prevents sending invalid data that could cause ECPay to reject the document.
Original PR description
When invoice is reconciled and credit note is issued, amount_residual_signed is not zero. By doing sale_amount += self.amount_residual_signed, TotalAmount is not match with the original sale amount and ECPay API returns error. task-5230384 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#234468
When incoming emails cannot be matched to an Odoo record, they are now still marked as read in the mailbox. This prevents the system from repeatedly reprocessing the same email, which saves time and helps ensure new messages are handled promptly.
Original PR description
# CONTEXT The refactor PR https://github.com/odoo/odoo/pull/191911 introduced a nice/needed refactor of the fetchmail methods. But in doing so a small logic error sneaked in. More specifically: This…
# CONTEXT The refactor PR https://github.com/odoo/odoo/pull/191911 introduced a nice/needed refactor of the fetchmail methods. But in doing so a small logic error sneaked in. More specifically: This try/except/else block https://github.com/odoo/odoo/blob/1f672b95a145b32d1ef2da9e83d82cd950045b5d/addons/mail/models/fetchmail.py#L305-L313 fails to account for the fact that in certain conditions a exception is expected while the `message_process` methods try to match the mail content with Odoo records. One example: If you fetch an email in the inbox that is addressed to an email address that is **not** an email alias in the database, it will raise a ValueError. Example: ``` ValueError: No possible route found for incoming message from "John Doe" <john@example.com> to "Josephine" <mon_amour@odoolove.com> (Message-Id <shrekislove@odoo.com>:). Create an appropriate mail.alias or force the destination model. ``` It follows that the `else` block is never triggered and `handled_message` will not be called, which would have marked the email in question as "READ". This means, that the next time the fetchmail CRON job runs, it will retry to refetch the same (failing) emails, which A) means lost time and processing time for a non relevant email B) if the backlog of failing emails is important enough, it will clog the mail fetching and we will never reach new emails. ## Proposed fix: Remove the else block, meaning that the `handled_message` get's called even after an exception. A this level of the stack we presume that any exception is either expected or the results of a misconfiguration (mail flows or Odoo configuration). So the mail was handled and should be marked a read in the mailbox being fetched. OPW-5122869 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230486
This fix ensures the printed Carta Porte uses the same CCP ID that was already sent and approved in the official CFDI document. As a result, the PDF and QR code now stay consistent across prints, avoiding mismatches that could cause confusion or rework.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_mx_edi_stock_30 - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - In Accounting settings, select "Solucion Factible" as PAC - Create a…
**Steps to reproduce:** - Install Accounting and l10n_mx_edi_stock_30 - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - In Accounting settings, select "Solucion Factible" as PAC - Create a product: * Product Name: XYZ * Product Type: Storable Product * UNSPSC Category: 25101929 Mobile office van * Tariff Fraction: 0101299999 Los demás. * UMT Aduana: Units * Weight: 1.00 - Go to "Inventory / Operations / Transfers / Deliveries" - Create a delivery: * Delivery Address: [a Mexican contact] (e.g. INMOBILIARIA CVA) * Product: Product XYZ * Transport Type: Federal Transport * Vehicle Setup: [something] (e.g. [ABC123] DEMOPERMIT) * Gross Vehicle Weight: [anything] * Distance to Destination (KM): [anything] - Validate the delivery - Generate Delivery Guide => CFDI document should be created and signed by the government - Print Carta Porte **Issue:** The "CCP ID" in the PDF is different than the one in the CFDI sent to the government. Each time the Carta Porte is printed, a new "CCP ID" is generated and use in the PDF. This also leads to a different QR-code in each PDF. **Cause:** When the Carta Porte is printed, instead of fetching the data from the existing CFDI document, they are recomputed. The problem is that "l10n_mx_edi_idccp" field is a non-stored computed field and its value is a RFC 4122 identifier. Each time the compute method is called, a new identifier is generated. **Solution:** When printing the Carta Porte, retrieve "CCP ID" from the existing CFDI document. opw-5208648 Forward-Port-Of: odoo/enterprise#99034 Forward-Port-Of: odoo/enterprise#98920
This update prevents an internal error that could appear when a browser’s service worker for Odoo was manually removed and push notifications were re-enabled. It makes the notification setup more reliable, so users are less likely to see a failed push notification message after refreshing the page.
Original PR description
When you manually unregister the ServiceWorker linked to your Odoo,
you may receive a notification "Failed to enable push notifications".
This occurs because the ServiceWorker associated with the previous
subscription is gone and the browser has lost the link between the
subscription and the Odoo instance.
To handle this case, we ensure waiting the activated state of the
registration of the service worker before subscribing to the web push
notification.
Steps to reproduce:
- In Odoo, enable push notifications.
- Inside another tab, go to the internal Chrome URL:
chrome://serviceworker-internals/?devtools
- Unsubscribe the ServiceWorker linked to your Odoo instance.
- In the Odoo instance tab, press F5.
=> You will see an internal notification stating
"Failed to enable push notifications" => BUG.
Forward-Port-Of: odoo/odoo#235039
Forward-Port-Of: odoo/odoo#234930This change corrects how Peppol verification updates are applied so related information is written together instead of in separate steps. It prevents mismatches in verification data that could otherwise cause validation errors for some partners.
Original PR description
In some cases, when doing two consequent writes instead of one batch, the ORM will trigger the dependencies needlessly, and it can end up to discrepancies like: EAS=0208, endpoint=BE... which lead to a validation error. opw-5228670 opw-5225590 opw-5228716 opw-5229057 opw-5232276 Forward-Port-Of: odoo/odoo#234740 Forward-Port-Of: odoo/odoo#234290
3 changes
New functionality added to Odoo
This change adds a new access group to control who can use certain estate-related features. It helps limit access to the right users and makes permission management clearer for businesses.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
This update improves the demo data for Argentine withholding taxes so it better matches how users actually work. It also fixes duplicated taxes so the withholding sequence is copied correctly, which helps keep tax setups consistent.
Original PR description
### FIX 1: copy withholding sequence when duplicating a tax Usually, when a user duplicate a tax, is to create a new one from the same type with a different rate. On this use case the sequence should be copied as well. Before this commit withholding sequence field was not copied ### FIX 2: better demo data Before this commit demo taxes being copied has name on their names.  After this commit taxes names relects what users are supposed to do.  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fix prevents an error that could appear when a browser’s service worker for Odoo is manually removed and then re-enabled. It helps push notifications turn back on smoothly instead of showing a failure message to the user.
Original PR description
When you manually unregister the ServiceWorker linked to your Odoo,
you may receive a notification "Failed to enable push notifications".
This occurs because the ServiceWorker associated with the previous
subscription is gone and the browser has lost the link between the
subscription and the Odoo instance.
To handle this case, we ensure waiting the activated state of the
registration of the service worker before subscribing to the web push
notification.
Steps to reproduce:
- In Odoo, enable push notifications.
- Inside another tab, go to the internal Chrome URL:
chrome://serviceworker-internals/?devtools
- Unsubscribe the ServiceWorker linked to your Odoo instance.
- In the Odoo instance tab, press F5.
=> You will see an internal notification stating
"Failed to enable push notifications" => BUG.
Forward-Port-Of: odoo/odoo#2349301 change
Resolved issues and error corrections
User avatars in the mail interface will now display with the correct crop and proportions, instead of appearing stretched or distorted. This small visual fix improves the consistency and polish of the chat and discussion areas in Odoo 17.0.
Original PR description
Before this commit, user avatars in the mail UI were not displayed using the `object-fit: cover` style, causing distorted or improperly scaled images. This issue is specific to version 17.0 — both versions 16.0 and 18.0 correctly apply the `cover` mode. After this commit, avatars are now rendered with `object-fit: cover` to ensure proper aspect ratio and consistent display across versions. ex bad ui before <img width="365" height="49" alt="Screenshot 2025-11-08 at 11 39 13 AM" src="https://github.com/user-attachments/assets/7195c594-12c3-4c67-8001-99d1b9e2eebb" /> after <img width="350" height="50" alt="Screenshot 2025-11-08 at 11 38 37 AM" src="https://github.com/user-attachments/assets/500c9f39-abd9-42b7-aba6-7a56e01cd6e2" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr