Monday, July 21, 2025
12 changes · saas-18.4
Enhancements to existing features
The ticket screen now shows the scheduled date as well as the time for future takeaway orders, helping staff identify when orders are due. It also improves time slot visibility in dark mode so current takeaway times are easier to read.
Original PR description
Commit 1 - add date for future orders on ticket screen ----------------- ### Before this commit: - On the ticket screen, only the preset time (e.g., 12:00) was shown for all orders, including future ones. ### After this commit: - For future orders (e.g., Takeaway scheduled for tomorrow), the ticket screen now shows the date above the time. Commit 2 - visibility of time slot on ticket screen for takeaway ---------------------------------------- ### Before this commit: - If we made a Takeaway order and selected the current time as a slot, the time was not clearly visible in dark mode.  ### After this commit: - The current time slot is now clearly visible on the ticket screen, even in dark mode.  Task-4916474 Forward-Port-Of: odoo/odoo#217518
Posted Saudi invoice PDFs can no longer be deleted once generated and submitted, helping preserve audit records required by ZATCA. The update also handles previously rejected Saudi e-invoices so outdated PDFs can be removed after successful resubmission when appropriate.
Original PR description
Task ID: 4730762 Description of the issue/feature this PR addresses: - As per ZATCA's auditability principles (clause 3 sub-heading C, paragraph 2): The Compliant E-Invoice solution must be able to…
Task ID: 4730762 Description of the issue/feature this PR addresses: - As per ZATCA's auditability principles (clause 3 sub-heading C, paragraph 2): The Compliant E-Invoice solution must be able to protect the generated Electronic Invoices and Electronic Notes from alteration or deletion. - This PR aims to restrict the deletion of valid invoice PDFs once the invoice has been generated & sent to ZATCA. Current Behavior before PR: - Invoice PDF attachments were allowed to be deleted in l10n_sa, even when the invoice is posted. - For l10n_sa_edi, if and invoice PDF is generated during a rejected state, it is kept there unless you reset to draft. Desired behavior after PR is merged: - in l10n_sa, deleting an attached invoice PDF raises a user error (reset to draft is required to detach the invoice first) - For l10n_sa_edi, if the invoice PDF is generated during a rejected state, but the invoice is resubmtited to ZATCA and accepted. The creation & write dates of the attachment linked & edi_documents respectively are compared and the deletion of the pdf attachment is allowed to be deleted in the case where the creation date was less than the write date. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218648 Forward-Port-Of: odoo/odoo#211192
Resolved issues and error corrections
Discuss now continues to load inbox and history messages even when a notification refers to a record that has since been deleted. This prevents users from seeing a generic fetch error and keeps message access reliable after related records are removed.
Original PR description
Before this commit, when a message notification from inbox or history has its related record deleted, the user couldn't load inbox or history. Steps to reproduce: - Have mitchell admin receive…
Before this commit, when a message notification from inbox or history has its related record deleted, the user couldn't load inbox or history. Steps to reproduce: - Have mitchell admin receive notification in Odoo - Install `mail_group` - Wait a few seconds to receive following user_notification from mail group: ``` on My Company News Hello, You have messages to moderate, please go for the proceedings. ``` - Go to related record then delete it - Go back to inbox or history => One of them show `An error occurred while fetching messages.` This happens because the related record is not a `mail.thread`, but still creates some `mail.message` to send user notifications. `mail.thread` cascade delete the messages in message list, but threadless records do not. Because the related record is deleted, these messages are attempted to be displayed in mailbox, but due to related record having no `display_name` by non-existing, the fetch data of inbox/history crashes with: ``` MissingError: Record does not exist or has been deleted ``` This commit fixes the issue by doing its best to show message even when the related record has been deleted. opw-4546920 Before  After  Forward-Port-Of: odoo/odoo#219795 Forward-Port-Of: odoo/odoo#219758
This fix corrects how Mexican DIOT report tax columns are tagged and calculated so they show the intended tax amounts instead of mixing in base amounts or multiple tax types. This improves the accuracy of VAT-related reporting for Mexican localization users.
Original PR description
Description of the issue/feature this PR addresses: The language used in the DIOT documentation was confusing and even though we had the exact same description for two columns it turns out they were different, so we need to change the logic of a few columns to make it work as needed. Current behavior before PR: In the DIOT, the columns Paid 8% N, Paid 8% s, Paid 16%, Importation 16% and Intangible imports 16% are sums of taxes paid with this type of tax. Desired behavior after PR is merged: Taxes now have a correction in their tags so that the columns in the DIOT report are calculated correctly. Likewise, the way of computing the columns Paid 8% N, Paid 8% s, Paid 16%, Importation 16% and Intangible imports 16% has been simplified. Now it no longer adds up different types of taxes, but only one type. opw-4920577 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218707 Forward-Port-Of: odoo/odoo#217441
Users can now open their inbox and message history even when a notification refers to a record that has since been deleted. This prevents message loading errors in Discuss and helps ensure important notifications remain accessible.
Original PR description
Before this commit, when a message notification from inbox or history has its related record deleted, the user couldn't load inbox or history. Steps to reproduce: - Have mitchell admin receive…
Before this commit, when a message notification from inbox or history has its related record deleted, the user couldn't load inbox or history. Steps to reproduce: - Have mitchell admin receive notification in Odoo - Install `mail_group` - Wait a few seconds to receive following user_notification from mail group: ``` on My Company News Hello, You have messages to moderate, please go for the proceedings. ``` - Go to related record then delete it - Go back to inbox or history => One of them show `An error occurred while fetching messages.` This happens because the related record is not a `mail.thread`, but still creates some `mail.message` to send user notifications. `mail.thread` cascade delete the messages in message list, but threadless records do not. Because the related record is deleted, these messages are attempted to be displayed in mailbox, but due to related record having no `display_name` by non-existing, the fetch data of inbox/history crashes with: ``` MissingError: Record does not exist or has been deleted ``` This commit fixes the issue by doing its best to show message even when the related record has been deleted. opw-4546920
Indian e-invoicing setup now shows the detailed error message and code returned when authentication fails. This helps users and support teams understand the reason for failed authorization faster and resolve configuration or service issues with less back-and-forth.
Original PR description
Previously, the `UserError` raised on authentication failure did not include the error message returned by the IAP server.
In this commit:
---
- Added logic to extract and include detailed error messages with code from the IAP response in the `UserError` during authentication for e-invoicing.
Related Tickets:
---
opw-4908388
opw-4942744
opw-4946339
opw-4946193
opw-4933833
Forward-Port-Of: odoo/odoo#219443
Forward-Port-Of: odoo/odoo#219277Vietnamese Viettel e-invoice data now aligns with updated local address rules by no longer sending a buyer district. The buyer city can now use either the city or state information, reducing failed or incorrect invoice submissions when customer address details are incomplete.
Original PR description
* Problem: Since what has been described in https://github.com/odoo/odoo/pull/214134 and https://thuvienphapluat.vn/chinh-sach-phap-luat-moi/vn/ho-tro-phap-luat/chinh-sach-moi/82581/tu-ngay-01-7-2025-ca-nuoc-se-khong-con-quan-huyen Vietnam no longer have district and city in city no more (Before in Vietnam we will have Thu Duc City belong to Ho Chi Minh State or Thuy Nguyen City belong to Hai Phong), Therefore we need to update Sinvoice data for this to. * This commit remove BuyerDistrict parameter , beside using state in the district is totally wrong and for 'buyerCityName' accept city or state field because odoo user might leave the city empty and just input state 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#218984
This fix updates the Mexican DIOT report so it uses the latest column definitions from related accounting changes. It helps ensure DIOT tax report values are calculated and shown in the correct places, reducing confusion and reporting errors.
Original PR description
Description of the issue/feature this PR addresses: The language used in the DIOT documentation was confusing and even though we had the exact same description for two columns it turns out they were…
Description of the issue/feature this PR addresses: The language used in the DIOT documentation was confusing and even though we had the exact same description for two columns it turns out they were different, so we need to change the logic of a few columns to make it work as needed. This issue was addressed in PR: https://github.com/odoo/odoo/pull/217441, but a small adjustment still needs to be made in the l10n_mx_reports module. Current behavior before PR: The l10n_mx_diot_get_values function uses references to the old account.report.expression that were removed in the pr mentioned above. Desired behavior after PR is merged: The l10n_mx_diot_get_values function uses the new references to account.report.expression that were introduced in the pr of the community repo. opw-[4920577](https://www.odoo.com/odoo/my-tasks/4920577) "I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr" Forward-Port-Of: odoo/enterprise#90119 Forward-Port-Of: odoo/enterprise#89481
The rental schedule's "To Do Today" filter now correctly accounts for each user's local timezone before checking today's rentals. This prevents rental orders from appearing too early or being missed for users outside UTC.
Original PR description
__Issue:__ The "To Do Today" filter used the user's local date to build a datetime range but treated it as if it were already in UTC. This caused incorrect filtering in non-UTC timezones __Fix:__ - Convert those datetimes to UTC using `.to_utc()` in the filter domain opw-4886069 Forward-Port-Of: odoo/enterprise#90358 Forward-Port-Of: odoo/enterprise#89718
Signed documents now correctly show the option chosen in selection fields after validation. This ensures completed agreements accurately display all signer-provided information when reopened or reviewed.
Original PR description
Steps to reproduce: 1. Install the sign module 2. Sign > template menu 3. Create a template with a signature and a selection field. 4. Sign the document and select a value in the selection field. 5. Validate the document 6. Reopen the signed document Issue: - The selected value was not shown after signing. Cause: - The display logic for the selected value was missing. - Logic was removed by this commit https://github.com/odoo/enterprise/commit/0cd6b4d08af0c9be5c74f6aee30d8fe890fc7c1 Solution: - Added code to render the selected value in signed documents. opw-4908385 Forward-Port-Of: odoo/enterprise#89380
Advance payments now correctly generate invoices for the next subscription period when an order includes both recurring and one-time products. This prevents missed billing after the first period and helps ensure subscription revenue is invoiced on schedule.
Original PR description
Steps to Reproduce: 1. create a subscription with a recurring & non-recurring product(select monthly cleaning quatation) 2. Pay for the first period. 3. Now, try to pay the advance payment for the second period. The invoice is not generated for the second duration Issue: - The invoice is not generated for the second period. Cause: - The _get_partial_payment_subscription_transaction method incorrectly compares the sum of authorized, uninvoiced transactions with the total order amount. Solution: - Update the _get_partial_payment_subscription_transaction method to compare the sum of authorized, uninvoiced transaction amounts with the next billing period’s total instead of the full order total task-4780971 Forward-Port-Of: odoo/enterprise#90453 Forward-Port-Of: odoo/enterprise#85114
Intrastat reports no longer preselect journal filters, helping ensure credit notes are included automatically. This reduces the risk of incomplete arrivals reporting and gives customers more reliable Intrastat declarations.
Original PR description
- Before this PR: Customers often miss credit notes in Intrastat arrivals due to filtering on purchase journals only, which results in incomplete reports. - After this PR: Journal filters are now unticked by default in both root and variant Intrastat reports. - Task ID: 4936349 Forward-Port-Of: odoo/enterprise#90415 Forward-Port-Of: odoo/enterprise#90131