Daily updates from Odoo
Sunday, April 19, 2026
45 changes
11 changes
Resolved issues and error corrections
Customers booking appointments or events will now see a simpler checkout by default, without having to re-enter full billing address details. This improves the buying experience and avoids asking for information that usually isn’t needed for these services.
Original PR description
Forward-Port-Of: odoo/enterprise#114098 Forward-Port-Of: odoo/enterprise#113575
This change brings back a simpler checkout experience for event tickets and similar service products by default, so customers are not asked to re-enter full billing details when they are not needed. It improves the buying flow and reduces friction, while still allowing businesses to require full address details through a system setting if needed.
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 Forward-Port-Of: odoo/odoo#259692 Forward-Port-Of: odoo/odoo#258347
This update fixes a bug that prevented messages from being sent through the portal when an opportunity was assigned to a company partner instead of a specific contact. The change improved the system's ability to correctly identify and authorize access to chatter, ensuring seamless communication within the Odoo CRM.
Original PR description
Steps to reproduce: 1) Create a partner contact form 2) Create a child contact for this partner, and grant it portal access 3) Create a customer contact form 4) Create an opportunity for the customer, with the previously created partner as "assigned partner" 5) Connect on the portal account of the partner 6) Send a message from an opportunity When a company partner is assigned to an opportunity (instead of a specific contact person), posting a message in the chatter raised a 404 NotFound error. _mail_get_operation_for_mail_message_operation was using a strict equality check (partner_assigned_id == user.partner_id), which fails when the assigned partner is the company and the user is a child contact under it. Replace the equality check with a child_of domain filter on commercial_partner_id, consistent with the logic already used in _assert_portal_write_access. Forward-Port-Of: odoo/odoo#252854
This update fixes an issue where calendar synchronization was incorrectly sending invitation emails for past events. The fix ensures that notifications aren't triggered when attendees are added to historical events, streamlining communication and reducing unnecessary emails. Further investigation is needed to understand the root cause.
Original PR description
## Problem: Calendar synchronization (Google/Outlook) is retroactively adding attendees to historical events. This triggers Odoo's default invitation logic, sending unnecessary emails to partners for…
## Problem: Calendar synchronization (Google/Outlook) is retroactively adding attendees to historical events. This triggers Odoo's default invitation logic, sending unnecessary emails to partners for meetings that occurred in the past. It is not yet clear why this is happening (needs more investigation), but we quick fix this by correctly checking that an attendee is not part of an event on an past date before triggering emails during the `write`. ## Steps to reproduce the bug: 1. Create an new event in the past and save 2. Add a new attendee (partner) to the event SHOULD NOT create a notification email (but it does) ## Remarks: - readapting existing unit test for `test_event_creation_mail`, but a proper new unit test might be needed in a proper refactor. As of now we were never testing if emails are triggered when adding new attendees on an event in past - giving this, this bug might be affecting previous versions. Might need to be backported and tested if needed - added time freeze to `test_event_creation_internal_user_invitation_ics` to account for the fact that implicitly the tested event was in the past - `freeze_time` for certain tests using the class event, which has hard coded dates OPW-6125052 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259844
This update resolves an issue where entering an invalid Taiwan VAT number (like '1234567A') would cause the invoicing system to crash. The fix adds validation to ensure the VAT number contains only digits, preventing the error and providing a clear warning message to the user.
Original PR description
**Steps to reproduce:** - Install the `base_vat` module. - Navigate to Invoicing > Customers. - Create a new contact and set the country to `Taiwan`. - Enter `1234567A` as the `Tax ID` and try to `save`. **Error:** `ValueError: invalid literal for int() with base 10: 'A'` **Root cause:** At [1], `check_vat_tw` is missing validation to ensure that the VAT number (without the country code) contains only digits, which causes an error when calling the `int()` method on the VAT number. **Fix:** This commit prevents errors and ensures users receive a `clear warning message`. [1]: https://github.com/odoo/odoo/blob/23398d24e108875b2838715d4b366df265d53234/addons/base_vat/models/res_partner.py#L929-L958 **No task Id** Forward-Port-Of: odoo/odoo#259936 Forward-Port-Of: odoo/odoo#259847
This update fixes a potential issue where Odoo would attempt to run a monitoring function during the shutdown process, when the necessary system resources were no longer available. This change ensures that the system gracefully handles shutdown, preventing errors and maintaining stability.
Original PR description
Odoo registers a callback function to track how much time is spent in garbage collection. But while the Python interpreter is shutting down and clearing out global modules and variables to free up memory and the Garbage Collector triggers one last time, the callback function `_timing_gc_callback` tries to run, but the function it depends on (like time.thread_time_ns) have already been set to None by the interpreter. Forward-Port-Of: odoo/odoo#259328
This update fixes a recent issue where generated invoice PDFs were displaying company information incorrectly. The change reverses the order of issuer and receiver addresses, improving the document's clarity and presentation. Switching to a simpler internal layout ensures the PDF clearly identifies it as an Odoo-generated document.
Original PR description
When an invoice is received through Peppol, it may not contain an embed PDF. If no, we create one. However, due to several complaints, this commit exchange the place of the issuer and receiver addresses and information. Company information were rendered in the header of the document through the external_layout. Switching to the internal layer avoid doing so. opw-5980655 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259578 Forward-Port-Of: odoo/odoo#254693
This update ensures that Odoo's module uninstall process clears all relevant data caches, preventing issues with incorrect tracking of related fields and relationships. Previously, outdated references lingered, causing potential problems with subsequent operations. This change enhances the reliability and stability of module uninstalls.
Original PR description
When uninstalling a module, the ORM may replace field objects in the registry via a prefetch patch to avoid fetching deleted fields. The previous code only called lazy_property.reset_all(), which resets lazy-property caches, but left _field_trigger_trees and _is_modifying_relations intact. Those structures still held references to the old field objects, and could be consulted by subsequent ORM operations, leading to incorrect trigger resolution or relation tracking. Clear both caches whenever a shared field has been patched so all registry state stays consistent with the new field objects. runbot-242251 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#259941 Forward-Port-Of: odoo/odoo#259820
This update resolves a bug where the Avatax integration in the checkout process caused the confirmation button to become unresponsive. The previous implementation unnecessarily called external tax APIs, leading to errors. This fix removes the problematic API call, ensuring a smoother checkout experience.
Original PR description
Issue: --- The extra external_tax call introduced in odoo/enterprise#101579 is causing multiple issues: 1- It doesn't catch errors while `_get_and_set_external_taxes_on_eligible_records` easily raises errors, causing uncatch errors in `website_sale`. 2- Extra unnecessary external api call in non-express checkout methods which is not desirable. Steps to reproduce: --- 1- Install l10n_br_avatax_sale, website_sale 2- Using a public user, add a product to cart and got to checkout. 3- In the address form, use CPF identification type. Outcome: The confirm button is unresponsive. Cause: --- This is due to uncatch error raised by external tax call, while it was not necessary at this step of this flow to call external tax api. opw-6005767 Forward-Port-Of: odoo/odoo#259728 Forward-Port-Of: odoo/odoo#256692
This update resolves an issue where the checkout process became unresponsive when using the Avatax module with CPF identification types. The previous implementation was unnecessarily calling external tax APIs, leading to errors that blocked the confirmation step. This fix removes the unnecessary API call, restoring normal checkout functionality.
Original PR description
Issue: --- The extra external_tax call introduced in odoo/enterprise#101579 is causing multiple issues: 1- It doesn't catch errors while `_get_and_set_external_taxes_on_eligible_records` easily raises errors, causing uncatch errors in `website_sale`. 2- Extra unnecessary external api call in non-express checkout methods which is not desirable. Steps to reproduce: --- 1- Install l10n_br_avatax_sale, website_sale 2- Using a public user, add a product to cart and got to checkout. 3- In the address form, use CPF identification type. Outcome: The confirm button is unresponsive. Cause: --- This is due to uncatch error raised by external tax call, while it was not necessary at this step of this flow to call external tax api. opw-6005767 Forward-Port-Of: odoo/enterprise#114109 Forward-Port-Of: odoo/enterprise#112515
This update resolves an issue where invoices could fail to process correctly with the Peppol system. The fix involved a minor adjustment to how the system handles invoice status updates, preventing a key error that was causing the process to halt. This ensures invoices are properly tracked and updated within the Peppol network.
Original PR description
1. Send an invoice that will return an error when send to IAP 2. Send the invoice 3. Click "Fetch Peppol Invoice status" on the dashboard 4. There is a traceback (see the bottom of this message) To…
1. Send an invoice that will return an error when send to IAP
2. Send the invoice
3. Click "Fetch Peppol Invoice status" on the dashboard
4. There is a traceback (see the bottom of this message)
To create an invoice that will return an error I locally removed the EndpointID from the UBL generation (and the constraint to check that during the genreation).
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/odoo/http.py", line 2167, in _transactioning
return service_model.retrying(func, env=self.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/service/model.py", line 157, in retrying
result = func()
^^^^^^
File "/home/odoo/src/odoo/odoo/http.py", line 2134, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/http.py", line 2382, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_http.py", line 333, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/http.py", line 754, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/addons/web/controllers/dataset.py", line 42, in call_button
action = call_kw(request.env[model], method, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/api.py", line 535, in call_kw
result = getattr(recs, name)(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/addons/account_peppol/models/account_journal.py", line 34, in peppol_get_message_status
edi_users._peppol_get_message_status()
File "/home/odoo/src/odoo/addons/account_peppol/models/account_edi_proxy_user.py", line 287, in _peppol_get_message_status
processed_message_uuids = edi_user._peppol_process_messages_status(messages_to_process, uuid_to_record)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/addons/account_peppol_response/models/account_edi_proxy_user.py", line 180, in _peppol_process_messages_status
peppol_response = uuid_to_record[uuid]
^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: 'document_type'
```
task-None
Forward-Port-Of: odoo/odoo#2598344 changes
Resolved issues and error corrections
Survey invitation emails are now sent in the correct language for each person, even when a batch includes recipients with different language preferences. This avoids confusion and helps ensure a better experience for international audiences.
Original PR description
When sending survey invitations to a group of recipients with different language preferences, some recipients would receive the invitation in the incorrect language. ### Steps to reproduce 1. Install…
When sending survey invitations to a group of recipients with different language preferences, some recipients would receive the invitation in the incorrect language. ### Steps to reproduce 1. Install the "Surveys" module and activate a second language (e.g., Dutch). 2. Create a survey and ensure its invitation template has translations for both languages. 3. Create two contacts: one with English as their language and another with Dutch. 4. On the survey, click "Share" and add both contacts as recipients. 5. Send the invitations. 6. The contact with Dutch preferred language receives the email in English. ### Cause By default, the wizard uses a single language for every email in a batch. While it can switch this language if everyone in the group speaks the same tongue, it fails to do so for mixed-language groups. Adding compute_lang=True fixes this by telling the system to look up and use the correct language for each recipient one by one. opw-5868581 Forward-Port-Of: odoo/odoo#255677 Forward-Port-Of: odoo/odoo#246778
This change fixes an error that could prevent portal users from posting messages on opportunities when the opportunity was assigned to their company contact instead of their exact person record. It aligns the access check with existing portal rules, so related contacts can now use chatter messaging without hitting a 404 error.
Original PR description
Steps to reproduce: 1) Create a partner contact form 2) Create a child contact for this partner, and grant it portal access 3) Create a customer contact form 4) Create an opportunity for the customer, with the previously created partner as "assigned partner" 5) Connect on the portal account of the partner 6) Send a message from an opportunity When a company partner is assigned to an opportunity (instead of a specific contact person), posting a message in the chatter raised a 404 NotFound error. _mail_get_operation_for_mail_message_operation was using a strict equality check (partner_assigned_id == user.partner_id), which fails when the assigned partner is the company and the user is a child contact under it. Replace the equality check with a child_of domain filter on commercial_partner_id, consistent with the logic already used in _assert_portal_write_access. Forward-Port-Of: odoo/odoo#252854
This fix prevents Odoo from creating a refund entry when a Stripe payment is voided before it has actually been captured. It ensures the accounting records match the real payment status, avoiding confusing or incorrect refund entries.
Original PR description
When an uncaptured Stripe payment is voided, the system will still generate the refund payment entry. Steps to reproduce: - Configure the Stripe payment provider - enable "Capture Manually" - generate webhook - Create a sales order - Generate a payment link and pay with Card - Back to the SO, click 'Void Transaction' Issue: Refund payment entry will be created even if no payment has been collected for the transaction. opw-5866924 Forward-Port-Of: odoo/odoo#259945 Forward-Port-Of: odoo/odoo#259230
Fixed an issue where subscription payments could be recorded successfully but the related invoice still showed as unpaid. This ensures invoices are automatically reconciled after payment, so users no longer need to manually fix the payment status.
Original PR description
Currently, when a subscription payment is processed through a provider configured to use as outstanding account the bank default account, the resulting invoice may remain in an 'open' state even…
Currently, when a subscription payment is processed through a provider configured to use as outstanding account the bank default account, the resulting invoice may remain in an 'open' state even though the payment transaction is 'done'. This type of configuration is usually done when users want to skip the bank reconciliation process, and just create payments without the need to reconcile the payments with transactions. Steps to reproduce: - In Settings, under Sales > Invoicing, disable Automatic Invoice - Activate demo payment method - In the main Bank account add the default account as outstanding account for demo payment method. - Create a sales order with a subscription product - Open Preview - Pay - Go back to the sales order and open the created invoice Issue: The invoice is created and the payment is registered, but the invoice remains 'Not Paid'. Analysis: The invoice and the payment move lines are not automatically reconciled during the post-processing of the transaction, leaving the invoice unbalanced. opw-5869303 Forward-Port-Of: odoo/enterprise#110656
3 changes
Resolved issues and error corrections
Credit notes could fail to post when an automatic currency exchange adjustment was created without the required analytic information. This fix allows those system-generated exchange lines to bypass the analytic requirement, so the credit note can be posted successfully.
Original PR description
**Issue:** When a user posts a credit note with a currency exchange difference relative to the reversed move, the resulting exchange move lines lack the mandatory analytic distribution. This triggers…
**Issue:** When a user posts a credit note with a currency exchange difference relative to the reversed move, the resulting exchange move lines lack the mandatory analytic distribution. This triggers a validation error, preventing the credit note from being posted. **Steps to reproduce:** - Set "mandatory" applicability on any analytic plan. - Set two different currency rates on two different dates for any foreign currency. - Create and post an invoice on the first date (ensure the mandatory analytic distribution is set). - Create a credit note from that invoice using the second date. - Click on the post button on the credit note. Result: A validation error occurs even though the credit note itself has the mandatory analytic plan set, because the auto-generated exchange move does not. **Fix:** Since the context key validate_analytic is set to True by the post button action, it must be manually set to False during the automatic creation of exchange difference moves to bypass the mandatory plan check. OPW-6081632 Forward-Port-Of: odoo/odoo#259624 Forward-Port-Of: odoo/odoo#259381
This change corrects a spelling mistake in a warning related to database constraints. It does not change how the product works, but it makes the message clearer and more professional for users and developers reviewing logs.
Original PR description
In this commit: --------------- - Corrected a typo in the SQL constraint warning message, updated `model.Constraint` to `models.constraint`. Forward-Port-Of: odoo/odoo#259867
The Dutch ICP report now uses the same rounding-down rule as the exported figures. This keeps the reported amounts aligned with what users send to the tax authority and avoids confusing mismatches.
Original PR description
Description of the issue this commit addresses: The Dutch tax authority lets ICP amounts be rounded down which is the behavior of the exports but not of the report itself meaning the values to not match and is quite confusing. --- Desired habevior after this commit is merged: The integer rounding DOWN is added on the ICP report to restore matching values --- task-6065382 Forward-Port-Of: odoo/enterprise#112953
1 change
Resolved issues and error corrections
The Dutch ICP report now uses the same round-down method as the export, so the amounts shown in the report match the values submitted. This avoids confusion when comparing the report with the official filing data.
Original PR description
Description of the issue this commit addresses: The Dutch tax authority lets ICP amounts be rounded down which is the behavior of the exports but not of the report itself meaning the values to not match and is quite confusing. --- Desired habevior after this commit is merged: The integer rounding DOWN is added on the ICP report to restore matching values --- task-6065382 Forward-Port-Of: odoo/enterprise#112953
21 changes
Resolved issues and error corrections
This update restores the vendor bill auto-complete feature in the Odoo Enterprise accounting module. It reverses a previous change that removed this functionality, ensuring users can quickly and easily find and select vendor bills. This improves efficiency and reduces the time spent entering purchase data.
Original PR description
This reverts commit https://github.com/odoo-dev/enterprise/commit/509ca37eef3a6dc9d148f0a11f350d41704eb02f. Community PR: https://github.com/odoo/odoo/pull/259168 task-6119762 Forward-Port-Of: odoo/enterprise#113827
This update corrects a bug where the date filter in account reports was incorrectly displaying calendar year-end dates when using custom fiscal periods. The fix ensures the report accurately reflects the user-defined fiscal year, improving reporting accuracy and consistency.
Original PR description
To reproduce, we set a fiscal year in the settings for instance(31 March). Next, we open the balance sheet and in the report settings, disable use_fiscal_periods. Then back on the report, we open the date filter and set a custom date to the fiscal year end. This would show the calendar year end. This is because when we are in a custom period, we try to infer a period from the user input. Forward-Port-Of: odoo/enterprise#114071
This update fixes a calculation error in the Luxembourg tax reports, specifically for invoices using tax grid '226'. The report was incorrectly displaying a negative value for credited amounts. The fix involves a simple formula change to ensure accurate tax reporting, aligning with recent tax updates.
Original PR description
Steps to reproduce: - Install `l10n_lu` module - Switch to `LU Company` - Create a invoice and in journal items use tax grid `226` - Open the Tax Report and check the line `226 - Supplies carried out within the scope of the special arrangement of art. 56sexies` - The value appears negative instead of positive. Cause: This issue is caused by the major tax revamp introduced in version 19 [commit]. The credited amount is currently displayed as a negative value, which is incorrect, it should be shown as positive. Solution: To resolve this issue, the formula has been modified from `226` to `-226`. [commit]: https://github.com/odoo/odoo/commit/17a6117ed88c29b5bc4db0c872bcdbc109a7d98b#diff-3441c5d05315ec0562923797f973eae66488452a6772d23e198998c1890aa06c opw-6050665 Forward-Port-Of: odoo/enterprise#113952
This update improves balance sheet reports for consolidated companies with multiple currencies. It adds a 'Cumulative Translation Adjustments' line to accurately reflect currency conversion differences based on account type (historical, average, or closing rates). This ensures more precise financial reporting and avoids discrepancies.
Original PR description
In reports, when consolidating two companies with different currencies, the conversion rate differs according to the type of account: * **BS accounts**: Closing rate → taken at the last day of the…
In reports, when consolidating two companies with different currencies, the conversion rate differs according to the type of account: * **BS accounts**: Closing rate → taken at the last day of the fiscal year * **P&L accounts** and **equity_unaffected**: Average rate → average over the fiscal year * **Equity**: Historical rate → taken the day of the creation of the journal item We are adding a line to the Balance Sheet, Trial Balance and General Ledger reports to correct the gap caused by the difference of rates: the **Cumulative Translation Adjustments**. This line is calculated by summing the differences of the converted balances using the right rate, and the converted balance at the closing rate of the report. By 'right rate', we mean the rate used according to the account: * historical for equity accounts * average for income_\*, expense_\* and equity_unaffected accounts We have, for equity accounts: cta_value = balance * rate_historical - balance * rate_closing for income_\*, expense_\*, equity_unaffected accounts: cta_value = balance * rate_average - balance * rate_closing The rate_closing corresponds to the rate observed the last day of the report period. task-5424428
This update enhances appointment tracking by asynchronously recording visitor activity using JavaScript. A key fix ensures visitor records are always created when an appointment is made, resolving a previous issue with sales person assignment. Additionally, tracking is now enabled by default, simplifying view configurations.
Original PR description
In the corresponding community PR, a new tracking route is introduced to record visitors and page visits asynchronously using js. In certain cases, there might be tours which need this write to occur earlier. Fixes include: appointment: tour which fails to assign the same sales person as the visitor.track record is not created. Fix: Force the creation of the visitor when an appointment is made. Task-4939052
This update fixes an issue where subscription invoices were being incorrectly set to a future date due to upsell orders. The change prevents the system from considering upsell order dates when calculating the next invoice date, ensuring accurate billing.
Original PR description
When we compute the next invoice date of a subscription, we are checking all account move lines of the invoices linked to the subscription. But if we have an upsell with a deffered date higher than the next invoice date that should be calculated, it will set a too high next invoice date. To avoid this issue, we don't take into account the invoice lines linked to upsell to compute the next invoice date Forward-Port-Of: odoo/enterprise#113170
This update fixes an issue where invoice periods were incorrectly calculated when subscriptions were set to align with their start date. The change ensures invoices accurately reflect the subscription's billing cycle, displaying the correct month and dates. This improves invoice accuracy and reduces potential billing discrepancies.
Original PR description
Steps to reproduce: ------------------------------------- 1. Install the Subscription module. 2. Go to Subscription > Configuration > Recurring Plans. * Open a Monthly recurring plan and enable Align…
Steps to reproduce: ------------------------------------- 1. Install the Subscription module. 2. Go to Subscription > Configuration > Recurring Plans. * Open a Monthly recurring plan and enable Align to Period Start. 3. Create a new Subscription: * Select the configured monthly plan. * Add any subscription product. * In the Other Info tab, set a Start Date in the past on the 1st day of a month (e.g., 01/11/2025). 4. Confirm the subscription. 5. Create a draft invoice. Observation: ----------------------------------- In the invoice line, you see the message: `61 days 11/01/2025 to 12/31/2025` It should be: `1 Month 11/01/2025 to 11/30/2025` Issue: ----------------------------------- https://github.com/odoo/enterprise/blob/a5a76de5f25483afa5432ed333c48d78832f128c/sale_subscription/models/sale_order_line.py#L376-L378 In `_get_invoice_line_parameters`, the computation attempts to find the next 1st day of the month However, `new_period_stop` already includes the billing period. When `new_period_stop` is in the past, an extra month is added through `new_period_stop + relativedelta(months=1)`, resulting in an incorrect period range Solution: ----------------------------------- Use `new_period_start` as the anchor point for period computation. Ensure the billing period ends on the last day of the starting month when Align to Period Start is enabled For upsell orders, the fix is NOT applied because for upsells, `new_period_stop` is already set to the parent subscription's `next_invoice_date`, which represents the correct billing boundary. opw-5920036 Forward-Port-Of: odoo/enterprise#107407
This update resolves a technical issue preventing the correct processing of DTE XML files received via the fetchmail server. Specifically, when a purchase journal isn't configured for LATAM document usage, an error occurs, preventing proper account move calculations. This fix ensures DTE XML processing functions as intended.
Original PR description
Currently, when receiving a DTE XML fetched by the fetchmail server, if there is no purchase journal with `l10n_latam_use_documents` enabled, an empty recordset (account.journal()) is set in the default context values. This prevents the proper computation of the field and raises an error, since the `journal_id` is mandatory on account moves. Steps to reproduce: - Ensure you have no purchase journal with `l10n_latam_use_documents` enabled - Simulate the reception of a DTE XML via the fetchmail server - Observe the error: "NotNullViolation: null value in column 'journal_id'" opw-5950116 opw-6111041 Forward-Port-Of: odoo/enterprise#112168
This update resolves a stability issue in the AI composer by ensuring focus events are correctly passed to the base handler. Previously, a patch prevented this, leading to crashes when the AI composer triggered focus. This change maintains the expected behavior and prevents disruptions to the mail composer.
Original PR description
**Purpose of this PR:** The AI composer patch overrides `Composer.onFocusin()` but did not forward the focus event to the base handler. This used to be harmless while the base mail composer focus handler did not use the event. Since odoo/odoo#258974, the mail composer now uses the event to stop `focusin` propagation, so dropping it makes the base handler crash when AI composer focus is triggered. This commit fixes the AI composer patch by forwarding the focus event to the base handler, preserving the expected handler contract. Related: odoo/odoo#258974 Task-5954657 Forward-Port-Of: odoo/enterprise#114013 Forward-Port-Of: odoo/enterprise#113763
This update resolves an error that occurred when creating appointments without a designated organizer. The fix prevents a template rendering issue that arose when the system incorrectly expected a user ID, ensuring appointments can now be saved successfully.
Original PR description
Currently an error is generated when the user tries to save an appointment as follows: - Install the appointment_google_calendar module without demo data - Create a new appointment as below: - Remove…
Currently an error is generated when the user tries to save an
appointment as follows:
- Install the appointment_google_calendar module without demo data
- Create a new appointment as below:
- Remove Organizer (user_id)
- Set the Google Meet link inside VideocallURL, e.g., https://meet.google.com/aaa-aaa-aaa
- An error occurs in the log and a message is shown to the user when save the record
- Also, an error occurs when trying to preview `Appointment: Attendee Invitation`
after creating appointment as follows:
- Set the Google Meet link inside Videocall URL > save
- Remove Organizer (user_id)
Error:
```
test odoo.addons.mail.models.mail_render_mixin: Failed to render QWeb template for Mail Template: 'Appointment: Appointment Booked' (ID: 12) - Context language:en_US
Target Model: calendar.event
Error: Error while render the template
ValueError: Expected singleton: res.users()
```
This is because the method `is_google_calendar_synced` expected a single
record, but since we removed `user_id` from the event (appointment),
it will generate a singleton error.
This commit will fix the above issue by not calling `is_google_calendar_synced`
when the event does not have `user_id`.
sentry-7393595716
Forward-Port-Of: odoo/enterprise#113966This update resolves an issue where the checkout process became unresponsive when using the Avatax module for Brazilian taxes. The previous implementation was causing unnecessary external API calls and unhandled errors, disrupting the order confirmation flow. This fix removes the problematic external tax call when not required, restoring normal checkout functionality.
Original PR description
Issue: --- The extra external_tax call introduced in odoo/enterprise#101579 is causing multiple issues: 1- It doesn't catch errors while `_get_and_set_external_taxes_on_eligible_records` easily raises errors, causing uncatch errors in `website_sale`. 2- Extra unnecessary external api call in non-express checkout methods which is not desirable. Steps to reproduce: --- 1- Install l10n_br_avatax_sale, website_sale 2- Using a public user, add a product to cart and got to checkout. 3- In the address form, use CPF identification type. Outcome: The confirm button is unresponsive. Cause: --- This is due to uncatch error raised by external tax call, while it was not necessary at this step of this flow to call external tax api. opw-6005767 Forward-Port-Of: odoo/enterprise#114109 Forward-Port-Of: odoo/enterprise#112515
This update resolves a crash that occurred when confirming rental orders with kit products using multiple pick locations. The change utilizes a safer method to handle multiple pick transfers, preventing a 'singleton error' and ensuring smooth order confirmation. This improves the reliability of rental order processing.
Original PR description
Problem: When you confirm a rental order that has a kit product whose components use two different pack locations Odoo crashes with a singleton error. You get this singleton error because Odoo tries…
Problem: When you confirm a rental order that has a kit product whose components use two different pack locations Odoo crashes with a singleton error. You get this singleton error because Odoo tries to assign both picks as the `return_id` because they share the same `sale.order.line` here: https://github.com/odoo/enterprise/blob/2212b3f3f3d90894dd6351defe0d3ca090584955/sale_stock_renting/models/sale_order_line.py#L404
Purpose: Use [:1] to safely handle the case where multiple pick transfers are created, avoiding a crash when assigning return_id which expects a single record.
Steps to Reproduce on Runbot:
1. Enable mutli-step routes and rental transfers.
2. Set the warehouse to 3-step delivery.
3. Copy the existing packing location.
4. Copy the existing pick operation type and set the destination location to the new packing location.
5. Create a new route.
6. Create new rules on this new route with the following configurations:
1. Rule 1
1. Action: Pull
2. Source location: WH/Stock
3. Destination location: Partners/Customers
4. Operation type: The new pick operation type
2. Rule 2
1. Action: Push
2. Source location: New pack location
3. Destination location: WH/Output
4. Operation type: Pack
3. Rule 3
1. Action: Push
2. Source location: WH/Output
3. Destination location: Partners/Customers
4. Operation type: Delivery
7. Create 2 component products tracked by inventory, and apply the new route on one of the component products.
8. Create a new rental product with a kit, which has the 2 component products.
9. Create a new rental order for the kit product and confirm it.
opw-6026918
Forward-Port-Of: odoo/enterprise#114020
Forward-Port-Of: odoo/enterprise#112543This update resolves a minor issue that could occasionally cause the Gantt chart to become unresponsive during drag-and-drop operations. The fix ensures that invalid drag attempts are properly prevented, enhancing the overall stability and usability of the chart. This improves the user experience when managing project timelines.
Original PR description
This commit fixes an oversight introduced in https://github.com/odoo/enterprise/pull/106130 regarding the pill dragging safeguard. Previously, the validation check in `onWillStartDrag` correctly halted the drag initialization logic when no valid target was found, but it failed to actually cancel the drag action itself. This commit ensures the failing scenario is virtually impossible so that the fail-safe can be removed. Forward-Port-Of: odoo/enterprise#113438
This update ensures that planning times displayed in the UI and when printed match, resolving a visual inconsistency. Previously, the planning report used a 24-hour format, which has now been corrected to align with the user interface. This improves the clarity and accuracy of planning reports.
Original PR description
Steps to reproduce: - Install the Planning module - Open the Planning app - Click the Print action Issue: Planning slots display in 12-hour format in the UI but print in 24-hour format. Cause: A hard-coded time format was used when printing planning slots. Fix: Remove the explicit format and rely on the locale aware short time format. task-5462276 Forward-Port-Of: odoo/enterprise#113544 Forward-Port-Of: odoo/enterprise#103359
This update resolves an issue where negative numbers in accounting reports (like customer statements) were incorrectly formatted, splitting the minus sign and amount across lines. This ensures that all financial data is displayed accurately and consistently when printing reports, preventing confusion and improving report readability. The fix improves the presentation of financial information.
Original PR description
When printing accounting reports such as customer statements, a negative number may be split across two lines, leaving the minus sign on the first line and the amount on the second. Steps to reproduce: - Make an invoice for [Partner] with a total of 10.0 - Make another invoice for [Partner] with a total of 100.0 - Create a credit note for this last invoice - Open the customer statement report for [Partner] - Print PDF Issue: The first line of the partner section has fewer digits than the amounts of the subsequent journal items. On pdf, the column width is based on the smaller line, causing the longer negative strings to wrap and separate the minus sign from the amount. opw-5951300 Forward-Port-Of: odoo/enterprise#113727
This update resolves an issue where dropdowns within knowledge articles weren't closing when clicking outside the embedded view. The fix adjusts the way the system detects clicks, ensuring dropdowns close as expected. This improves the user experience when working with knowledge articles and list views.
Original PR description
Steps to reproduce: - Go to knowledge - Type "/view" in the article -> add a list view - Open a dropdown in that list view (e.g. the cog icon next to "New") - Click outside the list view (e.g. first…
Steps to reproduce: - Go to knowledge - Type "/view" in the article -> add a list view - Open a dropdown in that list view (e.g. the cog icon next to "New") - Click outside the list view (e.g. first paragraph of the knowledge article that contains the list view) => The dropdown does not close Commit [1] removed the `activeEl` param of `popoverCloseOnClickAway`, and inverted the need for the knowledge patch added at [2] (before, it was needed to be able to close dropdowns by clicking inside knowledge embedded views, it is now needed to be able to close them by clicking outside the embedded views). In 19.2, this patch could be removed entirely as [3] made a generic solution for this to work (it will probably be done once this reaches master though). [1]: https://github.com/odoo/odoo/commit/1fb00045c6826ee7c8a7581ff4ab9b3eb2e83478 [2]: https://github.com/odoo/enterprise/commit/97c600ca35ae0513860467e572d587b977617d36 [3]: https://github.com/odoo/odoo/commit/48be3442b2b022c18d9e5d4fc8b9631563094d8e Forward-Port-Of: odoo/enterprise#114082
This update corrects a bug where customers could incorrectly edit boolean properties within shift worksheets accessed through the Odoo portal. The fix ensures these fields are read-only, preventing unintended data changes and maintaining data integrity. This resolves a visual inconsistency and improves the reliability of portal data.
Original PR description
view of shifts Currently, when a shift with a worksheet template is completed and the customer access its portal view of the shift, if a boolean property was present on the worksheet template then the portal user is able to edit that property. It is only a visual effect, the value is not updated in the db. This commit fix this issue and set the field in readonly mode. Forward-Port-Of: odoo/enterprise#113524
This update resolves an issue with the 'Current Year Retained Earnings' line on the Swiss Balance Sheet. The change adjusts the reporting date range to accurately reflect the fiscal year, ensuring financial reports align with Swiss accounting standards. This improves the reliability of financial data for Swiss clients.
Original PR description
The "Current Year Retained Earnings" (CH_299_A) line on the Swiss Balance Sheet was using the default `strict_range` date scope. This commit forces the `date_scope` to `from_fiscalyear`. task-6119493 Forward-Port-Of: odoo/enterprise#114145 Forward-Port-Of: odoo/enterprise#113920
A technical error was causing reports to fail to display correctly when a custom worksheet was included. This update adds a required 'readonly' attribute to checkbox fields in worksheets, ensuring proper rendering and preventing report errors. This improves the reliability of maintenance reports.
Original PR description
Step to reproduce - install maintenance app with demo - go to settings and enable custom worksheet - open default worksheet and add a the checkbox property field - open a maintenance request, add this worksheet in worksheet field - notice, worksheet is visible in notebook - print maintenance report Observation: - we get a traceback ``` odoo.addons.base.models.ir_qweb.QWebError: Error while rendering the template: KeyError: 'readonly' Template: worksheet.worksheet_template_properties_display ``` Cause: - when rendering checkbox, xml props needs `readonly` key for template "worksheet_template_properties_display" but it is not provided by `format_props` of worksheet module or `_get_props_formatted` of `maintenance_worksheet` module. Fix: - we add readonly attribute (default = False) for all boolean prop opw-6079837 Forward-Port-Of: odoo/enterprise#112661
This update resolves an issue where reports were displayed with an incorrect zoom level, particularly for Swiss Locales. The changes to the report data file have corrected the layout, ensuring accurate and properly scaled reports for users in Switzerland. This improves the user experience and data accuracy.
Original PR description
The reports appear to be zoomed in. Fix the reports layout. task-6053938
This update restores the ability to assign analytic distributions directly when creating write-offs during reconciliation, a feature removed in Odoo 16.3. Previously, users had to manually reset and repost entries, which is now simplified by adding a dedicated field for analytic distribution at the write-off creation stage.
Original PR description
Since 16.3, it is no longer possible to define an analytic distribution when creating a write-off during reconciliation. Earlier, the reconciliation widget allowed assigning an analytic distribution directly to the write-off journal item. With the introduction of the reconciliation wizard in SaaS-16.3, this capability was lost, requiring users to reset the entry to draft, manually set the analytic, and repost it. This commit reintroduces this feature by adding an Analytic Distribution field to the write-off flow, allowing users to define it at creation time, restoring the previous behavior. task-4642990
4 changes
Resolved issues and error corrections
The Dutch ICP report now uses downward rounding for integer amounts, matching the behavior of the export files. This removes confusing differences between the report and exported figures, making the totals easier to trust and reconcile.
Original PR description
Description of the issue this commit addresses: The Dutch tax authority lets ICP amounts be rounded down which is the behavior of the exports but not of the report itself meaning the values to not match and is quite confusing. --- Desired habevior after this commit is merged: The integer rounding DOWN is added on the ICP report to restore matching values --- task-6065382 Forward-Port-Of: odoo/enterprise#112953
This update resolves an issue where copying a user also duplicated their assigned tasks, leading to shared task assignments. The fix ensures that new users have independent task assignments, preventing conflicts and simplifying task management. This improves data consistency and reduces potential errors.
Original PR description
Duplicating a user also duplicates all their task assignments because task_ids on res.users is missing copy=False. The new user ends up sharing the same tasks in project_task_user_rel, so removing a task from either user affects both.
This update resolves an issue where menu visibility in the Timesheet module didn't immediately update after changing the 'Billing Rate Indicators' setting. The fix ensures that menu changes are reflected correctly, improving the user experience and eliminating the need to clear the cache or restart the server. This change is specific to version 19.0.
Original PR description
Steps to reproduce: - 1. Only install 'sale_timesheet_enterprise'. 2. Go to Timesheets > Configuration > Settings. 3. Toggle "Billing Rate Indicators" (timesheet_show_rates) on and off and save. 4.…
Steps to reproduce: - 1. Only install 'sale_timesheet_enterprise'. 2. Go to Timesheets > Configuration > Settings. 3. Toggle "Billing Rate Indicators" (timesheet_show_rates) on and off and save. 4. Check the menus. Issue: - Menu visibility does not update immediately after saving the setting. Menus that should appear (e.g., "Employee Billing Time Targets") remain hidden, or vice versa, until the cache is cleared or the server is restarted. Cause: - The load_menus method is decorated with @ormcache and stored in the Registry LRU cache. Menu visibility depends on timesheet_show_rates through _load_menus_blacklist. When this field is updated, the ORM does not automatically invalidate the cached load_menus result because timesheet_show_rates is not included in cache_invalidation_fields(). As a result, the stale old menu remains in memory. Fix: - Override cache_invalidation_fields in res.company to include timesheet_show_rates so that toggling this setting clears the Registry cache and forces recomputation of the menu. Note: - This fix is required only for 19.0. From saas-19.1, it will be solved in odoo/enterprise#106464. task-5428010
This update resolves an issue where dropdowns within knowledge articles weren't closing when clicking outside the embedded view. The fix adjusts the way the system detects clicks to ensure dropdowns close consistently, regardless of where the user clicks. This improves the overall usability of the knowledge article feature.
Original PR description
Steps to reproduce: - Go to knowledge - Type "/view" in the article -> add a list view - Open a dropdown in that list view (e.g. the cog icon next to "New") - Click outside the list view (e.g. first…
Steps to reproduce: - Go to knowledge - Type "/view" in the article -> add a list view - Open a dropdown in that list view (e.g. the cog icon next to "New") - Click outside the list view (e.g. first paragraph of the knowledge article that contains the list view) => The dropdown does not close Commit [1] removed the `activeEl` param of `popoverCloseOnClickAway`, and inverted the need for the knowledge patch added at [2] (before, it was needed to be able to close dropdowns by clicking inside knowledge embedded views, it is now needed to be able to close them by clicking outside the embedded views). In 19.2, this patch could be removed entirely as [3] made a generic solution for this to work (it will probably be done once this reaches master though). [1]: https://github.com/odoo/odoo/commit/1fb00045c6826ee7c8a7581ff4ab9b3eb2e83478 [2]: https://github.com/odoo/enterprise/commit/97c600ca35ae0513860467e572d587b977617d36 [3]: https://github.com/odoo/odoo/commit/48be3442b2b022c18d9e5d4fc8b9631563094d8e Forward-Port-Of: odoo/enterprise#114082
1 change
Resolved issues and error corrections
This update corrects a discrepancy in the Dutch Intrastat ICP report by implementing integer rounding down, aligning with the Dutch tax authority's requirements. Previously, the report values didn't match the exported data, causing confusion. This change ensures accurate reporting for Dutch customers.
Original PR description
Description of the issue this commit addresses: The Dutch tax authority lets ICP amounts be rounded down which is the behavior of the exports but not of the report itself meaning the values to not match and is quite confusing. --- Desired habevior after this commit is merged: The integer rounding DOWN is added on the ICP report to restore matching values --- task-6065382