Friday, April 24, 2026
57 changes · saas-19.3
Resolved issues and error corrections
This update resolves an issue where automated tests, particularly those involving multiple modules, would fail due to incorrect test instance data. The fix ensures that test instances are properly initialized, allowing tests to run reliably. A more permanent solution is being considered to prevent this issue in the future.
Original PR description
Regenerating the test instance on retry works in most cases but fails when the test instance contains relevant data about what to test, which is the case for cross module tests and test params. Combined with an error while disabling autoretry this caused the hoot test to retry with an empty list. Fixing the issue by setting the relevant flags. This is a quick fix to reenable the test but a more robust solution would be to make sure ALL test instance existing attributes are properly copied before starting the test, or forbidding to set them on the instance before running them. Forward-Port-Of: odoo/odoo#261130
This update removes redundant and outdated usage of the 'tracking_disable' context keys within Odoo tests. The changes improve test clarity, reduce potential issues related to tracking, and streamline the testing process. This simplifies the codebase and makes tests more reliable.
Original PR description
When possible, avoid using context keys skipping the whole mail.thread stack. Since a few years various usage of those keys have been added through odoo addons quite often without clear purpose in…
When possible, avoid using context keys skipping the whole mail.thread stack. Since a few years various usage of those keys have been added through odoo addons quite often without clear purpose in mind when asked to authors or when reading commit messages. Partly because people tend to copy-paste code patterns without really understanding the purpose of those. See individual commits for more details. USAGE IN TESTS Lots of tests use the 'tracking_disable' or 'mail_notrack' context keys. However I bet most of those are there just because they were copy pasted, and without any thinking about the usage * it is used on non-thread models (which shows writer did not check what it was about); * it is copy-pasted in multiple unit tests creating one data each time (which shows performance are not the matter here as the writer could use a setupClass); * most usage is done when creating records, although there is no tracking at create time. And even if someday tracking at create comes back it would not be a performance issue on a test db compared to current test workload (too much tests, tours that are slow, ...). It also deactivates creation message log and initial follower (if not root) but those insert should be fast; * mail.thread is part of the real life stack and should be tested in functional addons. It notably has an impact on followers which means ACLs, partner_id field setup, field computation and invalidation, cache usage, ... Better remove most of them, and keep only relevant one (e.g. batch creation, simulating environment like Payroll, ...). Task-6094598 Followup of Task-3645865
This update prevents customers without a portal account from seeing the 'Pay Now' button in follow-up emails. This change avoids confusion and ensures customers aren't directed to a process that won't integrate with their invoices. It simplifies the customer experience by aligning the button's availability with their account status.
Original PR description
If a customer has no portal account, the pay now button added to follow-up emails won't allow them to access any invoices on the portal. Even if they register afterwards, a separate account will be created and they won't have access to those invoices. To avoid confusion, this commit hides the pay now button when the customer has no portal account. task-6075621 Forward-Port-Of: odoo/enterprise#114698 Forward-Port-Of: odoo/enterprise#112891
This update resolves an issue where the 'cancel' button within the spreadsheet functionality didn't trigger the expected confirmation dialog. Now, when a user clicks the cancel button, the confirmation process is correctly initiated, ensuring a smoother and more reliable user experience. This improves data integrity and user satisfaction.
Original PR description
The `cancel` callback of the `env.askConfirmation` method was not called when the user clicked on the cancel button. task-6074948 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#260061
This update resolves an issue where the 'cancel' button within the documents spreadsheet functionality wasn't properly triggering the cancellation process. The fix ensures that clicking the cancel button now correctly removes the user's changes and returns them to the previous state. This improves the user experience and data integrity.
Original PR description
The `cancel` callback of the `env.askConfirmation` method was not called when the user clicked on the cancel button. task-6074948 Forward-Port-Of: odoo/enterprise#112987 Forward-Port-Of: odoo/enterprise#112304
This update fixes a bug that occurred when rescheduling work orders in the Gantt view. Specifically, the issue arose when dependent operations lacked start or end dates. The fix ensures that date comparisons are handled correctly, preventing a 'TypeError' and allowing for smooth rescheduling functionality.
Original PR description
Currently, an error occurs when rescheduling work orders in the Gantt view if a dependent operation has no start or end date. **Steps to Reproduce:** - Install the MRP module (with demo data). -…
Currently, an error occurs when rescheduling work orders in the Gantt view if a dependent operation has no start or end date. **Steps to Reproduce:** - Install the MRP module (with demo data). - Activate "**Custom Work Order Dependencies**". - Create a new MO for the _Drawer_ product with _SEC-ASSEM_ BoM. - Confirm and plan the MO. - Remove both start and end dates of any dependent operation. - Manufacturing > Planning > Work Orders > Gantt - Enable **Auto-Reschedule (Keep Buffer)** and reschedule the first operation (in 'Drill 1'). **Error:** `TypeError - '>' not supported between instances of 'bool' and 'datetime.datetime'` **Cause:** At [1], `date_start` and `date_finished` can both be set to False because a condition that bypasses the UserError when both dates are empty (unlike earlier versions). As a result, during rescheduling, a False value is compared with a datetime, leading to a TypeError at [2]. Fix: This commit adds a condition before date comparisons to ensure the dates are defined. [1]: https://github.com/odoo/odoo/blob/3f256437a7e6c124affca8d5304476a67375753f/addons/mrp/models/mrp_workorder.py#L281-L284 [2]: https://github.com/odoo/enterprise/blob/ef2efe113684104032d798b5aa237c67a3bc240a/web_gantt/models/models.py#L484-L491 sentry-7377739830 Forward-Port-Of: odoo/enterprise#112729
This update corrects a bug in how depreciation is calculated for companies with non-standard fiscal years (e.g., May-December). Previously, the system incorrectly skipped months during depreciation, leading to inaccurate asset valuations. The fix ensures accurate depreciation calculations for all fiscal year types.
Original PR description
When a company has a shortened fiscal year defined via account.fiscal.year (e.g. May-December), the depreciation board computation for degressive assets incorrectly computes the start of the next…
When a company has a shortened fiscal year defined via account.fiscal.year (e.g. May-December), the depreciation board computation for degressive assets incorrectly computes the start of the next fiscal year using `date_from + 1 year` instead of querying the actual next fiscal year. This causes entries for the months between the wrong and correct FY start (e.g. January-April) to be skipped entirely. Step to reproduce: - Create a company with a fiscal year starting in May (e.g. May 1st 2025 to 31st December 2025) - Create an asset with a start date in the 1 December 2025, with a 24 months duration and degressive method - Compute the board and observe that entries from January to April 2026 are missing Fix the FY boundary detection in _recompute_board to query the fiscal year containing the day after the current period end, revert the effective_start_date logic in _compute_board_amount that was masking the root cause, and move the prorata date clamping to _create_move_before_date where it is needed for disposal. opw-6016834 Forward-Port-Of: odoo/enterprise#113895 Forward-Port-Of: odoo/enterprise#113521
This update prevents employees in Mexico from receiving early, unstamped payslip emails. Previously, a first email contained an incomplete payslip, followed by a second email with the finalized, stamped version – creating confusion. Now, emails are only sent with the stamped payslip after the CFDI is generated.
Original PR description
Currently, when a user confirms a payslip batch (hr.payslip.run), the base payroll module queues the PDF generation and sends an email to the employee with their payslip immediately. For Mexican payslips, this means the employee receives the email with an unstamped payslip (without CFDI UUID). Later, when the CFDI is generated, a second email is sent with the stamped version, confusing the employee. This commit prevents the email from being sent for Mexican payslips if the CFDI has not been generated yet, ensuring only the stamped payslip is emailed. Forward-Port-Of: odoo/enterprise#114731
This update resolves an issue where users would encounter an error when trying to open unassigned opportunities linked to a team. The fix removes unnecessary whitespace from the context string used to open the opportunity, preventing a parsing error. This ensures a smoother experience for users managing unassigned leads.
Original PR description
Currently, an error occurs when user tries to open unassigned opportunities assigned to a team. Steps to replicate: - Install `crm` with demo. - Open `CRM > Sales > Teams` and click `Sales` team. -…
Currently, an error occurs when user tries to open unassigned opportunities assigned to a team.
Steps to replicate:
- Install `crm` with demo.
- Open `CRM > Sales > Teams` and click `Sales` team.
- Remove the `salesperson` from any lead, then return to `Teams` via breadcrumbs.
- On the kanban card for Sales, click “Unassigned Leads”.
Error:
```
File '/home/odoo/src/odoo/saas-19.2/addons/crm/models/crm_team.py', line 728, in action_open_unassigned_opportunities
context = self.env['crm.lead']._evaluate_context_from_action(action)
File '/home/odoo/src/odoo/saas-19.2/addons/crm/models/crm_lead.py', line 727, in _evaluate_context_from_action
return literal_eval(context_str)
File '/home/odoo/src/odoo/saas-19.2/odoo/_monkeypatches/ast.py', line 28, in literal_eval
return orig_literal_eval(expr)
File 'ast.py', line 66, in literal_eval
node_or_string = parse(node_or_string.lstrip(' \t'), mode='eval')
File 'ast.py', line 52, in parse
return compile(source, filename, mode, flags,
IndentationError: unexpected indent (<unknown>, line 8)
```
Cause:
- Error occurs after a recent [PR].
- As we called `literal_eval()` on the context string that we passed on to the `act_window` [1], it tries to parse the string using python like rules, the context is received as this:
```
"{\n 'search_default_team_id': [False],
\n'default_team_id': False,
\n'default_type': 'opportunity',
\n'default_user_id': 2,
\n'show_lead_gen_button': True
}\n "
^^^^^^^
```
- The extra whitespace/indentation (coming from the `act_window` context definition) makes the string invalid for strict parsing, causing `literal_eval()` to fail.
- Additionally, in the above given context string the `search_default_team_id` and `default_team_id`are both `False` because we called `_evaluate_context_from_action()` method on an empty recordset and when we try to [substitute] `active_id` with `self.id`(which is False because we dont have any record) we get another JS Error that is caused by not receiving any results for the search default on team.
Solution:
- Using `strip()` function removed the extra whitespaces.
- Passed the `team_id` through context (as we cant add new parameters to a function in stable) and assigned it in place of `active_id`.
[1]: https://github.com/odoo/odoo/blob/746ea418da2af2a6d36daea4dc544bdf3bc28495/addons/crm/views/crm_team_views.xml#L41-L48
[PR]: https://github.com/odoo/odoo/pull/240202/changes#diff-595d3dbbabdc4f766a380a320c1c1a43b143385bc7487c7275e80f76a9fbabc2R724
[substitute]: https://github.com/odoo/odoo/blob/e00dd21880c3c4e5c22d65567c700e02541f7259/addons/crm/models/crm_lead.py#L726
sentry-7404817458
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#259288This update resolves an issue where shared helpdesk ticket links would fail when the user who originally sent the message had been removed. The fix ensures that the link generation process handles deleted users gracefully, preventing errors and improving the reliability of shared links. This ensures a smoother experience for users sharing and accessing helpdesk tickets.
Original PR description
Currently, an error occurs when opening a shared helpdesk ticket link if the message author has been deleted. **Steps to Reproduce:(v19.2)** - Install Contacts and Helpdesk modules (with demo data). - Log in as "**Marc Demo**". - Create a helpdesk ticket and send a message via the chatter. - Log in as **Admin**. - Delete the demo user and the related partner from Contacts. - Go to Helpdesk > All Tickets and open the created ticket. - Click "**Share Ticket**" and open the generated link in another browser. Error: `ValueError - Expected singleton: res.partner()` **Cause:** When the partner linked to `message.author_id` is deleted, the recordset becomes empty, which raises a singleton error. Fix: This commit ensures that the author details are only included when the message author exists. sentry-7337698605 Forward-Port-Of: odoo/odoo#260767 Forward-Port-Of: odoo/odoo#254175
This update resolves an issue where deleting a document from a sign request would cause the page to crash. The fix now gracefully handles deleted documents by redirecting the user to a safe view, ensuring a stable user experience. This improves reliability and prevents data loss.
Original PR description
Steps to reproduce: - Open a sign request - Go to Details - Delete the document from the form view - The UI tries to reload the document Issue: The system tries to load a document that has already been deleted. Current behavior: An error is shown and the page crashes when trying to reload the deleted document. Expected behavior: The system should handle the missing document gracefully and redirect the user to a safe view. Fix: Handled the deleted document case properly by returning a valid response and redirecting the user instead of trying to load the removed document. task id- 6095120 Forward-Port-Of: odoo/enterprise#113094
This update fixes an issue where VAT reports were incorrectly using the company's VAT number instead of the fiscal position's foreign VAT ID. The change ensures that VAT reports accurately reflect the correct tax identification number for each country, improving tax reporting accuracy. This resolves a discrepancy impacting financial reporting.
Original PR description
### Issue: When a fiscal position defines a `foreign_vat`, tax reports generated for that country still use the company's VAT number instead For example, with a Belgian fiscal position using…
### Issue: When a fiscal position defines a `foreign_vat`, tax reports generated for that country still use the company's VAT number instead For example, with a Belgian fiscal position using `BE010203040`, the generated BE VAT report uses the company VAT instead of `010203040` ### Cause: The report generation did not check whether there is a fiscal position with a `foreign_vat` matching the country of the report ### Note: The example above uses a Belgian fiscal position to reproduce the issue Starting from 19.0, this specific flow is blocked because Intervat is enabled in production mode by default A related fix makes the Intervat settings available in that case Until then, the issue can be reproduced by temporarily commenting out: https://github.com/odoo/enterprise/blob/5fb58a9b7b3ae89f87e84d4ba1fa3a16237d80ac/l10n_be_intervat/models/account_return.py#L15 ### Steps to reproduce: - Disable demo data and install `accountant` - Create a Fiscal Position "Belgium" (Country: Belgium, Foreign Tax ID: BE010203040) - Click the alert to install the Belgian taxes - Create and confirm an invoice for a Belgian customer: - Fiscal Position: Belgium - Any product with a Belgian tax - Invoice Date: 01/01/2026 - Open the Tax Report and select `VAT Return (BE)` for January - Click `Returns` and select the full year - Mark the December return as Completed from the three-dot menu - Review January and fill the missing company data (TIN: 1111111, phone and email) - Click `Validate -> Lock -> Submit` ### Before the fix: The generated XML uses the company VAT number (`1111111`) instead of the fiscal position foreign VAT (`010203040`). opw-6076540 Forward-Port-Of: odoo/enterprise#112610
This update addresses a critical issue where Odoo would crash when attempting to download a URL document alongside a spreadsheet. The fix ensures stable downloads of combined documents, improving user experience and preventing data loss. This resolves a reported bug impacting users accessing and sharing documents.
Original PR description
Try to download a url document along with a spreadsheet. `onDownload` crash when trying to download a url document. Task: 5485662 Forward-Port-Of: odoo/enterprise#113645 Forward-Port-Of: odoo/enterprise#112513
This update corrects an issue where E-invoice filenames weren't being properly recorded during the import process from SDI documents. Previously, this caused problems when exporting invoices, as the system couldn't find the associated file. This change ensures the correct filename is now stored, resolving potential export errors and maintaining data integrity.
Original PR description
PR #212726 removed a Many2One field and replaced it with an existing binary field (`l10n_it_edi_attachment_file`) and a new Char field (`l10n_it_edi_attachment_name`) to store E-invoice files as…
PR #212726 removed a Many2One field and replaced it with an existing binary field (`l10n_it_edi_attachment_file`) and a new Char field (`l10n_it_edi_attachment_name`) to store E-invoice files as XMLs. This change was made for security reasons. This pre-existing binary field was already used for importing SDI documents, which caused errors resolved in PR #252806. The new char field was not set during the SDI import process in PR #212726. This can cause errors when exporting invoice documents, as our code sees content in the binary field and expects the name to also be present. See [`_get_invoice_legal_documents()`](https://github.com/odoo/odoo/blob/f48f221c91b8d123bcaf1c4d8ed6c7dfba763ae6/addons/l10n_it_edi/models/account_move.py#L411). This commit ensures that the name of an imported SDI document is set in the move's `l10n_it_edi_attachment_name` field. opw-6023263 [link](https://www.odoo.com/odoo/my-tasks/6023263) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258882 Forward-Port-Of: odoo/odoo#257586
This update fixes a display issue where invoices and bills created in time zones ahead of UTC (like GMT-12) were not appearing correctly in reports. The change ensures that dates are accurately reflected, resolving a discrepancy that prevented timely reporting. This improves the accuracy of financial data.
Original PR description
Why this commit: When loading the 'bills to receive' or 'Invoices to be Issued' The time zones ahead of UTC will face the discrepancy in the view. e.g. etc/GMT-12 timezone is 12 hours ahead of UTC,…
Why this commit: When loading the 'bills to receive' or 'Invoices to be Issued' The time zones ahead of UTC will face the discrepancy in the view. e.g. etc/GMT-12 timezone is 12 hours ahead of UTC, So 12 AM UTC is 12 PM etc/GMT-12. So report view will not include the invoices/bill with order_date of current day till its 12 AM[next day] IN UTC, Meaning etc/GMT-12 will be seeing today's bills/invoices after 12 PM. After this commit: To resolve this discrepancy we use the context_today date to get the user local date. Which is required by the [domain sanitizer](https://github.com/odoo/odoo/blob/8bff78853f6ab8dc2cc951c03bb30181c0745834/odoo/orm/domains.py#L1572-L1574) too. Steps to reproduce (Possible in runbot) : 1. Select etc/GMT-12 timezone in preferences [when UTC is between 13:00-24:00 ~ 1:00-12:00 GMT-12(of next day)] 2. Create a PO and Validate the quantity received. 3. Go to accounting>review>bills to receive. 4. the newly created PO won't be listed here. OPW: 6083526 Forward-Port-Of: odoo/enterprise#114763
This update simplifies how the system processes XML data for Slovak reports, reducing unnecessary complexity and improving performance. By using the standard XML parsing library, we've eliminated a custom configuration that was causing overhead. This change ensures more efficient report generation.
Original PR description
Removes the custom XMLParser configuration in favor of the default etree parser. This reduces unnecessary overhead and ensures we are using the standard library's recommended defaults for processing XML content. Forward-Port-Of: odoo/enterprise#114828
This update resolves an issue where images from CORS-protected sources weren't being optimized to WebP. By fixing this, the system now automatically converts multiple images, including those with CORS restrictions, to WebP, leading to faster loading times and reduced bandwidth usage for our users. This enhancement improves the overall performance and efficiency of the platform.
Original PR description
Since [1], when users select multiple images through the media dialog, subsequent images of a CORS protected image are not converted to webp. This commit fixes that issue. Related to task-5405262 [1]: https://github.com/odoo/odoo/commit/422b073bcc6406c76339a1ccaa0c40dc3f42801c Forward-Port-Of: odoo/odoo#261055
This update corrects an issue where emails sent from the applicant refusal wizard in the HR recruitment module were not populating with the correct applicant details. The fix ensures that the email subject and body now accurately reflect the chosen template and the specific applicant information, improving communication and accuracy in the recruitment process.
Original PR description
Issue: ---------------------------------------- The `applicant.get.refuse.reason` wizard displays the mail body with the placeholders, not the values actually sent. Steps to reproduce: ---------------------------------------- - Open Recruitments and go to an applicant form view - Click "Refuse" - Select the template "Job already fulfilled" - The subject and the mail body have placeholder values Cause: ---------------------------------------- We don't render the body for the wizard, only when we send the mails. Solution: ---------------------------------------- Render the body when we get it from the template. This only works if `applicant_ids` have one value. Otherwise, we display the placeholders because the values can be different from an applicant to another. opw-6082883 Forward-Port-Of: odoo/odoo#258874
This update resolves an issue where users without 'write' access to products couldn't print labels. The fix adds necessary permissions to allow read-only users to generate product and variant labels, improving usability for a wider range of users. This ensures consistent label printing functionality.
Original PR description
Users who do not have the "write" access on `product.template` and `product.product` cannot print product labels and product variant labels Steps to reproduce: 1. Install Sales 2. Log in as Marc Demo…
Users who do not have the "write" access on `product.template` and `product.product` cannot print product labels and product variant labels Steps to reproduce: 1. Install Sales 2. Log in as Marc Demo 3. In Sales > Products > Products, open a product and click Print Labels from the cogwheel menu 4. An access error is raised Same issue happens for Product Variants Issue: https://github.com/odoo/odoo/commit/95ace0a694eaf83329b50e6b89f774f0c59fec5e removed Products-related rights from the `base.group_user`. This made a difference in terms of access rights, as the `IrActionServe.run` method checks for the "write" access by calling `_can_execute_action_on_records`: https://github.com/odoo/odoo/blob/d15685304f479541879fabd55ea1cae4252a2a90/odoo/addons/base/models/ir_actions.py#L1230-L1239 Solution: Add `group_user` to the `group_ids` of the relevant actions to prevent the check on the "write" access from being performed This is a backport of https://github.com/odoo/odoo/commit/6c2c353f30db05579f5e8b7a6752ec2d1ae365b2 opw-6111333 Forward-Port-Of: odoo/odoo#260513 Forward-Port-Of: odoo/odoo#260342
This update resolves a technical issue preventing the settings view tests from running correctly. The change ensures the tests wait for the search debounce timer to complete, allowing the tests to pass reliably. This improves the stability of the settings view.
Original PR description
Before this commit, the settings view tests were failing because a 500ms debounce was added to the search functionality in 1. This commit ensures that the test waits for the debounce timer to finish before continuing with the assertions. [1] https://github.com/odoo/odoo/commit/2c246214e62a9bd2ee7bd372cac99b55ed565a83
This update resolves an issue where the Odoo system couldn't correctly handle the Turkey timezone after a recent software update. The fix adds a fallback mechanism to ensure accurate timezone calculations, preventing errors during database upgrades. This ensures proper event scheduling and data processing.
Original PR description
**[FIX] handle Turkey timezone when tzdata-legacy not installed** In #236660 we switched from pytz to zoneinfo. The library `pytz` has `Turkey` in **pytz.all_timezones_set**. On the other hand…
**[FIX] handle Turkey timezone when tzdata-legacy not installed**
In #236660 we switched from pytz to zoneinfo.
The library `pytz` has `Turkey` in **pytz.all_timezones_set**.
On the other hand starting from ubuntu 24.04 as tzdata was split and `Turkey` was [moved](https://documentation.ubuntu.com/release-notes/24.04/#tzdata-package-split) out of tzdata to tzdata-legacy.
If we run a db which has reference to `Turkey` timezone, on a server which is ubuntu 24.04 and tzdata-legacy not installed, we will get an error as we did not have fallback for `Turkey` while we have for `Türkiye`. Because zoneinfo will not have `Turkey` in `zoneinfo.available_timezones()`
Issue was discovered during upgrade of db which has res.partners with timezone=`Turkey` from 19.0 to saas~19.1. The upgrading docker container was nobel and it did not have tzdata-legacy.
For fixing the issue we added fallback for `Turkey`.
Tbh I do not think we need a fallback for `Türkiye` but I wanted to not change the old behaviour.
###
**[FIX] handle America/{Catamarca,Godthab} timezones**
As we moved from `pytz` to `zoneinfo` in **saas~19.1**
we have 2 more timezones which were existing in `pytz`
but not in `tzdata` adn we do not have fallback for them.
They are in `tzdata-legacy`:
- America/Catamarca
- America/Godthab
We added fallback for them.
We already have a failing upgrade request because of
America/Catamarca.
Turkey:
```
File "/home/odoo/src/odoo/saas-19.1/addons/calendar/models/calendar_event.py", line 742, in _compute_field_value
return super()._compute_field_value(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/addons/mail/models/mail_thread.py", line 495, in _compute_field_value
return super()._compute_field_value(field)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 4271, in _compute_field_value
determine(field.compute, self)
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 83, in determine
return needle(*args)
^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/addons/calendar/models/calendar_event.py", line 503, in _compute_recurrence
event_values = event._get_recurrence_params()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/addons/calendar/models/calendar_event.py", line 1341, in _get_recurrence_params
event_date = self._get_start_date()
^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/addons/calendar/models/calendar_event.py", line 1573, in _get_start_date
return start.replace(tzinfo=UTC).astimezone(ZoneInfo(self.event_tz)).date()
^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/odoo/_monkeypatches/zoneinfo.py", line 130, in __new__
z = super().__new__(cls, key)
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/zoneinfo/_common.py", line 24, in load_tzdata
raise ZoneInfoNotFoundError(f"No time zone found with key {key}")
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key Turkey'
```
Catamarca:
```
Traceback (most recent call last):
File "/tmp/tmpm0v0h90i/migrations/base/tests/test_mock_crawl.py", line 335, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpm0v0h90i/migrations/base/tests/test_mock_crawl.py", line 348, in mock_action
return self.mock_act_window(action)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/tmp/tmpm0v0h90i/migrations/base/tests/test_mock_crawl.py", line 508, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpm0v0h90i/migrations/base/tests/test_mock_crawl.py", line 541, in mock_view_form
[data] = record.read(fields_list)
^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 2735, in read
self._origin.fetch(fields)
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 3067, in fetch
fetched.mapped(field_name)
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 5479, in mapped
return [getter(record) for record in records]
^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 1794, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 1965, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py", line 4271, in _compute_field_value
determine(field.compute, self)
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 83, in determine
return needle(*args)
^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/odoo/addons/base/models/res_users.py", line 455, in _compute_tz_offset
user.tz_offset = datetime.datetime.now(ZoneInfo(user.tz or 'UTC')).strftime('%z')
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/odoo/_monkeypatches/zoneinfo.py", line 130, in __new__
z = super().__new__(cls, key)
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.12/zoneinfo/_common.py", line 24, in load_tzdata
raise ZoneInfoNotFoundError(f"No time zone found with key {key}")
zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key America/Catamarca'
```
tbg-2529
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#256821This update resolves an error that occurred when generating W2 reports without specifying an end date. The fix ensures the system defaults to the current year when no end date is provided, preventing a file generation failure. This ensures users can consistently create W2 reports without encountering this issue.
Original PR description
Currently, an error occurs when user tries to create a csv for w2 form with no end date defined. Steps to replicate: - Install `l10n_us_hr_payroll`. - Open Payroll > Reporting > W2 Report. - Click…
Currently, an error occurs when user tries to create a csv for w2 form with no end date defined.
Steps to replicate:
- Install `l10n_us_hr_payroll`.
- Open Payroll > Reporting > W2 Report.
- Click `New` > Remove value from `End Date` and click Generate.
Error:
```
File '/home/odoo/odoo19/enterprise/l10n_us_hr_payroll/models/l10n_us_w2.py', line 249, in action_generate_csv
self.csv_filename = f'form_w2_{self.date_end.year or date.today().year}.csv'
^^^^^^^^^^^^^^^^^^
AttributeError: 'bool' object has no attribute 'year'
```
Cause:
- As the user did not give any value for `End Date`, False was passed and when the execution flow reached [here] `self.end_date` is False and attempting to access `self.end_date.year` results in this error.
Solution:
- If we do not receive the `self.end_date` while generating the CSV, we will use the current year to generate the CSV file name.
[here]: https://github.com/odoo/enterprise/blob/01be8d6e9384bcb340559847d529b4887e073519/l10n_us_hr_payroll/models/l10n_us_w2.py#L248
No ID
Forward-Port-Of: odoo/enterprise#114363
Forward-Port-Of: odoo/enterprise#113408This update resolves a bug where deleting a button within the HTML editor would unexpectedly remove the entire editor. The fix ensures that after deleting a button, the editor correctly clears the block and adds a line break, preventing the editor from being removed entirely. This improves the user experience and stability of the HTML editor.
Original PR description
### Steps to reproduce: - Create a button, set its URL to #, and click Apply. - Place the cursor right after the link. - Press Backspace until the button/link is removed. - Entire editor also gets…
### Steps to reproduce: - Create a button, set its URL to #, and click Apply. - Place the cursor right after the link. - Press Backspace until the button/link is removed. - Entire editor also gets removed. ### In previous version: - Issue is due to [1](https://github.com/odoo/odoo/commit/7685e562b1036d08724ba91ed5064b6fe20c2ce2 ) change in `isEmptyBlock` (because of `isButton`). - When we had `<a>#[]</a>` and pressed backspace, `deleteRange` was called. - Then `fillShrunkBlocks` ran and `isEmptyBlock` returned true (no isButton). - So `<br>` was added and block never became fully empty. ### In current version: - Because of `isButton` condition, some empty blocks are not treated as empty. - So `<br>` is not added & block stays actually empty. Then `removeFEFF` runs & `nodeSize` becomes false & `cleanEmptyAncestors` removes parent even editable. ### After this PR: - Case like `<a>[]</a>`, backspace is handled by override which directly removes `<a>`. Since this skips `deleteRange`, manually call `fillShrunkBlocks` there. - Now after removing `<a>`, block is properly detected as empty and `<br>` gets added. task-6109145 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259055
A recent update to receipt printing caused fiscal data for Swedish blackbox receipts to disappear. This fix corrects the receipt template and data generation process, ensuring that all required fiscal information is now correctly printed on Swedish receipts, both in the frontend and backend.
Original PR description
Since the receipt printing refactor that allowed printing receipts from either the frontend or backend, the fiscal data for Swedish blackbox receipts has been broken. In the frontend, the receipt prints but the blackbox data is missing from the footer. In the backend, attempting to print the receipt gives a 500 error. This commit fixes both these issues by correcting the receipt template and data generation. Community - https://github.com/odoo/odoo/pull/260587 Forward-Port-Of: odoo/enterprise#114579
This update fixes a problem where newly created events would unexpectedly have their website visibility turned off. The issue stemmed from an internal system process incorrectly resetting the website publication status, even when it should have been automatically managed. This change ensures the website visibility is correctly set upon event creation.
Original PR description
If you create a new event, and immediately toggle "website_published" before it is saved, the UI will toggle it off on its own. The reason is technical. As event tracks this field, it is read everytime the record is written to. In parallel `_finalize_publication` invalidates the website_published field even when it is protected. As the field is protected, the orm does not recompute the field when it is read but does fill in the cache with `False` even though it would have evaluated to `True` if computed. The issue here lies in invalidating a protected field, as `Environment.protecting` normally guarantees that the field will not be invalidated. We now stop invalidating protected records. task-6102144 Forward-Port-Of: odoo/odoo#257826
This update corrects a reporting error that incorrectly showed planned hours on public holiday days. The fix ensures that public holidays, regardless of their calendar association, are accurately excluded from time sheet forecasts, resolving inconsistencies in reporting. This improves the accuracy of time tracking data.
Original PR description
### Steps to reproduce: - Install project_timesheet_forecast module - Configure your database to have a far timezone (Montevideo/Uruguay in my case) - Create a public holiday starts from 12AM to…
### Steps to reproduce: - Install project_timesheet_forecast module - Configure your database to have a far timezone (Montevideo/Uruguay in my case) - Create a public holiday starts from 12AM to 11:59PM with a calendar - Create a planning slot for a resource that overlap with the public holiday - Check the Timesheets / Planning analysis report - Group by employees > day **- Check the date of the public holiday and notice there are still planned hours shown** - Remove the calendar from the public holidays that we created previously - Check the report once again **- Notice the day of the public holiday and the day after has no planned hours** ### Cause: In the query we are using to exclude the leave days from the report we only exclude the ones that has calendar_id assigned, not taking into consideration that some of the public holiday are general and is not applied to just one working schedule. Also if we have a leave starting midnight to 11:59PM since we store dates in database as UTC for timezone like Uruguay's one it will shift the end with one day which will introduce inconsistencies ### Fix: We check if the calendar_id is null on the resource_calendar_leaves and make sure we take timezone of the resource into account when checking the dates of the leaves. opw-5027070 Forward-Port-Of: odoo/enterprise#114757 Forward-Port-Of: odoo/enterprise#111846
This update fixes an issue where child contacts of German companies were incorrectly flagged as companies by l10n_de_reports. The change ensures that only companies with their own distinct commercial entities are recognized as such, improving the accuracy of German tax reporting. This resolves a potential reporting discrepancy.
Original PR description
Problem: When l10n_de_reports is installed, child contacts of a German company are incorrectly considered as companies as well. Steps to reproduce: 1. Install l10n_de_reports. 2. Create a company with a German VAT number (e.g. DE123456789). 3. Create a child contact under that company. 4. The child contact will be incorrectly considered as a company. Cause: If l10n_de_reports is installed, any partner with a German VAT number (DE + 9 digits) is considered as a company. Since child contacts share the same VAT as their company, they would be considered as companies as well, which is not correct. However, a partner should only be considered as a company if they are their own commercial entity. https://github.com/odoo/odoo/blob/e6bd6b106c376336594edd868c09505032008ac1/odoo/addons/base/models/res_partner.py#L819 Forward-Port-Of: odoo/enterprise#114600
This update fixes an issue where product names on the Replenishment dashboard were being cut off, leading to a poor user experience. The pull request adjusts column widths to ensure product names are fully visible, enhancing usability and clarity for users managing stock replenishment.
Original PR description
Purpose: the name of the product in the replenishment dashboard often gets truncated which is bad for UX. Adjust column widths to make better use of space. task-5097352 Forward-Port-Of: odoo/odoo#259259 Forward-Port-Of: odoo/odoo#253384
This fix resolves an issue where updating a manufacturing order (MO) after changing a product's design or variant could cause a system error. The change prevents users from making these updates to confirmed MOs, ensuring accurate material reservations and preventing potential operational disruptions. This improves stability and avoids data inconsistencies.
Original PR description
Currently, an error occurs if a user changes the product in a BoM, updates the manufacturing order (MO) based on that BoM, and then attempts to unbuild the order. ## Steps to replicate: - Install…
Currently, an error occurs if a user changes the product in a BoM, updates the manufacturing order (MO) based on that BoM, and then attempts to unbuild the order.
## Steps to replicate:
- Install Manufacturing without demo data
- Settings > Enable Variants
- Create the following products:
- Car with (Red and Blue Color attributes)
- Red Paint
- Create a BoM for Car and product variant set to Red Car and have Red paint as the component.
- Create and Confirm manufacturing order for Red Car
- Click on Bill of Material > Set Paint required to 2 > Save
- Set product variant in BoM to Blue and save again.
- Go back to MO > Update BoM > Produce All
- Unbuild qty 1 > Confirm
## Observed Behavior:
ZeroDivisionError: float division by zero
## Root cause:
This issue occurs because the Update BoM button remains visible on the Manufacturing Order (MO) even after the product has been changed.
The problem starts when a user initially updates the required paint quantity from 1 to 2. At that point, the function [1] marks the BoM as outdated for all linked MOs, which makes the Update BoM button appear. However, if the user later changes the product template or variant, the BoM is still considered outdated. This incorrectly allows the user to update the MO using a BoM that no longer matches the selected product.
**Why this causes a traceback when unbuilding?**
When the user clicks Update BoM, it triggers the `action_update_bom function` [2], which calls `_link_bom`. This process recomputes several fields to align the MO with the updated BoM. One of the methods triggered during this recomputation is `_compute_move_finished_ids` [3]. Since the production is already confirmed, the logic skips adding the production to `production_with_move_finished_ids_to_unlink_ids`, meaning no new finished moves are created for that updated product.
As a result, although the MO is updated, its finished product (`move_finished_ids.product_id`) still refers to the original product (for example, Red Car), instead of the newly selected one.
Later, when the user attempts to unbuild the product, the `action_unbuild` function [4] is executed, which calls `_generate_consume_moves` [5] During this step, the system tries to compute a factor that depends on `unbuild.mo_id.quantity_produced`.
However, because the finished moves still reference the old product and do not match the MO’s current product, the computed total becomes zero at [6] This leads to a division by zero error at [5], which ultimately causes the traceback.
[1]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_bom.py#L432-L447 [2]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_production.py#L1044-L1048 [3]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_production.py#L771-L800
[4]:
https://github.com/odoo/odoo/blob/97b60952d59a57aba12b048cb4da4f41d85d2ea2/addons/mrp/models/mrp_unbuild.py#L153-L164
[5]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_unbuild.py#L225-L232 [6]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_production.py#L641-L647
## Solution:
This change prevents users from updating a Bill of Materials (BoM) after the main product or its template has been modified, by ensuring the BoM is not marked as outdated.
This approach make sense because, once a manufacturing order (MO) is confirmed, all raw materials are physically reserved before production begins. While it makes sense to update BoM components in response to an Engineering Change Order (ECO) or last-minute specification changes, it does not make sense to allow changes to the final product itself on existing confirmed MOs. Doing so could lead to operational errors, since materials have already been procured and reserved for a specific product.
This fix ensures that if the product variant or product template is updated in the BoM, users cannot update the MO based on that BoM. This also prevents potential divide-by-zero errors when attempting to unbuild the product in the MO.
Reference commit which also suggests this behavior for the `Update BoM` button: [commit](https://github.com/odoo/odoo/commit/d7392829c769ef50456a7bc93d4482072b329463#:~:text=An%20exception%20however%3A%20if%20the%20MO%20is%20confirmed%20and%20the%20BoM%27s%20product%20was%0Achanged%2C%20the%20MO%20shouldn%27t%20have%20the%20%22Update%20BoM%22%20button%20displayed.%0AOtherwise%2C%20it%20would%20change%20the%20finished%20product%20of%20a%20confirmed%20MO.)
opw-6044754
Forward-Port-Of: odoo/odoo#260639
Forward-Port-Of: odoo/odoo#255981This update addresses an issue where the delivery confirmation email wasn't being sent correctly due to missing tracking information from Easypost. The fix prevents errors when tracking data is unavailable, ensuring accurate picking validation and correct shipping creation in Easypost. Easypost support suggested a slight delay between order placement and data retrieval as a potential workaround.
Original PR description
Problem: 'tracker' object in response from GET /orders/:id request can sometimes be null. This means that when the mail template 'mail_template_data_delivery_confirmation' is sent, a traceback occurs…
Problem: 'tracker' object in response from GET /orders/:id request can sometimes be null. This means that when the mail template 'mail_template_data_delivery_confirmation' is sent, a traceback occurs with error: TypeError: 'NoneType' object is not subscriptable. As a result the picking is not validated in odoo but a shipping has succesfully been created in the easypost backend. Solution: Prevent traceback form happening, picking gets correctly validated and carrier_tracking_url field is empty. Transcript from Easypost support: << I'm also seeing the tracker showing as null when reviewing the response. I'll go ahead and create a ticket for the engineering team to investigate. I can see that the tracking code is being returned in the request, but the full tracking object is not. Since this appears to be happening on a case-by-case basis, you may want to allow more time between the BUY and the GET requests, as I noticed they are being triggered very close together. I'm not certain if that's related, but it may be worth trying as a troubleshooting step while we have this under review. >> opw-5402415 Forward-Port-Of: odoo/enterprise#113231 Forward-Port-Of: odoo/enterprise#111833
A recent update to a test within the 'web' module caused a previous merge to fail. This commit corrects the test, ensuring future updates to the 'web' module are properly validated. This prevents potential issues with the module's functionality.
Original PR description
PR [1] added a record in the test data, which made an existing test fail. The PR should have never been merged as is, but due to a runbot issue, failing tests were ignored by the mergebot and the PRs were merged anyway. This commit fixes the failing test. [1] https://github.com/odoo/odoo/pull/256621 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
This update fixes an issue where taxes automatically replacing themselves were being hidden from account move reports. The change ensures that all relevant taxes, including those that self-replace, are accurately displayed, improving financial reporting accuracy. This ensures compliance and provides a more complete view of financial transactions.
Original PR description
If a tax replaces itself, it's not redundant and must appear on account moves. This commit solves this issue by including self-replacing taxes in the name_search. task-6147767 Forward-Port-Of: odoo/odoo#261044 Forward-Port-Of: odoo/odoo#260616
This update resolves a technical issue that prevented a key test from running correctly, ensuring the stability of our account reporting features. The change ensures proper setup of the necessary environment within tests, preventing errors and improving the reliability of our automated testing process. This contributes to a more robust and dependable Odoo Enterprise system.
Original PR description
This test, when run alone, raised an error telling assigning directly self.env.companies was not the right way of doing this, and it was better to create a new env. For some reason, it didn't raise when run together with other tests ; so, runbot didn't see the issue. This commit aims at soothing the ire of Odoo's mighty tests spirits \o/ Forward-Port-Of: odoo/enterprise#114248
This update corrects a bug where the 'Update Payment' button remained visible after processing batch payments for Mexican CFDI invoices. The fix ensures the button only appears for invoices with specific payment policies, preventing incorrect display when batch payments are involved. This ensures accurate invoice management for our Mexican clients.
Original PR description
- Create one invoice with the PUE payment policy. - Create another invoice with the PDD payment policy. - Send both invoices to the CFDI. - Create a batch payment for both and reconcile. - Click on Update Payment on one of the invoices. The Update Payment button does not disappear. In the method _l10n_mx_edi_cfdi_invoice_get_payments_diff, we compare the current UUIDs and the previous UUIDs to determine if the button should be shown. However, when there is a batch payment, the current UUID list includes the UUIDs of all invoices in the batch, including the PUE payment (which should normally be filtered out by the continue). The previous UUID list includes only the UUID of the PDD payment. opw-6055781 Forward-Port-Of: odoo/enterprise#114261 Forward-Port-Of: odoo/enterprise#112520
This update ensures that custom fields used in Odoo's related field functionality are correctly recognized. Previously, a field needed to be searchable to be usable in this way. This change streamlines the process by directly checking the field's properties, preventing issues and ensuring consistent behavior across the system. This update avoids potential blocking of upgrades.
Original PR description
Following up on #259309. A field must be searchable to be used in the related path. To know it, we must go into the instantiated field on the model to read that property, as being stored is not necessary. This mixes two different levels of abstraction but is necessary to have more consistent behaviour and not to block valid related field going through searchable fields. We also do this check only when the registry is ready to avoid blocking upgrades. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260585
This update ensures that links within documents added through the website builder's 'replace media' feature are correctly translated. Previously, a different upload process didn't apply the necessary translation, leading to broken links. This change corrects this issue, improving the functionality of the website builder.
Original PR description
[FIX] website: translate links inline on media replacement On the website builder, files added through the `/file` command would go through the domPlugin `insert` method, which would call…
[FIX] website: translate links inline on media replacement
On the website builder, files added through the `/file` command would go
through the domPlugin `insert` method, which would call
`before_insert_processors` and apply `.o_translate_inline` as expected.
But there is another flow to add a document on the page: replace an
image (or video, or icon), then select the "Documents" tab and upload
a file. With this flow, `insert` is not called, so we have to add the
class through some other resource.
[FIX] html_editor: target documents with right class
The class `.o_image` was still associated with documents (in the context
of the file selector) and the expected tag of a document was `A`, in
spite of it not being true in `html_editor` since the introduction of
the file box in [1].
This has also been updated in the website builder since the introduction
of the `html_builder` module in 18.4, which swapped uses of `web_editor`
components for `html_editor`.
As a side-effect, in website, a double click on a file did not open the
media dialog on the "document" tab, unlike other media (images, videos,
icons). In such a case, the file was also not shown as already selected
in the media dialog (because it targetted the wrong tag name). Both of
those behaviors were lost as we used the new file box design in 18.4.
[1]: https://github.com/odoo/odoo/commit/7f9afa21dffba2f74f9fb8a68809db4af6c7c225
task-5876278
Forward-Port-Of: odoo/odoo#261015
Forward-Port-Of: odoo/odoo#245904This update fixes an issue where the forecast report incorrectly grouped purchase orders with different receipt dates for the same product. The fix ensures that each unique receipt date is accurately reflected in the forecast details, providing a more precise view of inventory availability. This improves the reliability of inventory planning.
Original PR description
If you make a purchase order with 2 quantity of the same product, and set 2 different receipt date. The forecast report details would incorrectly group them as the same line. Steps to reproduce: ------------------- * Create a purchase order * Add 2 lines with the same product * Change the receipt date for one of the 2 lines * Go to the forecast report of the product > Observation: In the forecast details there is only one line for the first receipt date. Why the fix: ------------ We add a condition in the `_sameDocument` function to check that the 2 documents being compared have the same receipt date opw-5361583 Forward-Port-Of: odoo/odoo#254170
This update corrects a display issue in the Odoo Enterprise portal. Previously, running subscriptions showed the total subscription amount in the sidebar title. Now, it accurately displays the next billing amount, providing users with clearer information about their upcoming payments. This improves transparency and simplifies subscription management.
Original PR description
Running subscriptions were showing the total amount in the portal sidebar title instead of the next billing amount. Display the next billing amount for running subscriptions. task-6125080 Forward-Port-Of: odoo/enterprise#114083
This update resolves a technical test failure within the Enterprise version of Odoo's timesheet feature. The fix ensures that the correct system calls are executed when leaderboard settings are enabled in the timesheet grid, improving the stability and reliability of the feature. This change primarily impacts internal testing and development.
Original PR description
This commit checks the steps expected once the leaderboard settings in timesheet grid is enabled to make sure the RPCs called are correctly done as expected. runbot-error-243315 Forward-Port-Of: odoo/enterprise#115029
This update clarifies the helpdesk stage Kanban view by removing the confusing "Days to rot" number display. Previously, users couldn't understand the meaning of this value. This change improves usability and reduces potential confusion for support staff.
Original PR description
Currently, only the “Days to rot” number is displayed, so users cannot understand what the number represents. In this commit, it hide from the helpdesk stage kanban view. task-5485507 Forward-Port-Of: odoo/enterprise#114880 Forward-Port-Of: odoo/enterprise#114781
This update resolves an issue where the original product name was incorrectly prepended to product descriptions on invoices and RFQs when editing. The fix ensures that only translated names and descriptions are displayed, improving invoice clarity and accuracy for users working with multiple languages. This change impacts invoicing and purchasing workflows.
Original PR description
Steps to reproduce: 1- Install invoicing app 2- Add French language in the settings 3- Create a customer with language set as French 4- Create a product and define french translations of the name and…
Steps to reproduce: 1- Install invoicing app 2- Add French language in the settings 3- Create a customer with language set as French 4- Create a product and define french translations of the name and the description in Sales tab 5- Create an invoice for that customer and choose the product you created 6- You will find the translated product name and description under the product name 7- Edit the description, save and preview the invoice 8- The invoice line will contain [Product Name EN] [Product Name FR] [Product Description FR] Description of the issue: When creating an invoice for a customer whose language differs from the user's account language, manually editing the product description on an invoice line causes the original product name to be prepended to the description. The same issue happens in a RFQ in Purchase. Expected behaviour: User can edit the product description in the invoice line and the output in the invoice should only be the translated name and description, without the original product name. Why this happens? 1- When the product is selected in the invoice line, the label is loaded from _compute_name method in account_move_line, which holds the translated name and description. 2- After editing the description and escaping the field (clicking outside it), the parseLabel method is called, which prepends the original name to the label, making the invoice output as [original name] [translated name] [translated desc.] Fix: Use the product name returned in the label for trimming and concatenation to handle both original/translated text scenarios. References: original PR: #248401 partial revert: #254158 opw-5480494 Forward-Port-Of: odoo/odoo#256837
This update fixes a minor issue where the company logo wasn't appearing on the journal audit export template. The fix ensures the necessary CSS class ('o_content') is included in the template, correctly applying the logo and improving the visual presentation of reports. This resolves a cosmetic problem impacting user experience.
Original PR description
before this commit, the export template of the journal audit was missing the o_content and so the company logo class was not applied opw-6128819 Forward-Port-Of: odoo/enterprise#114782
This update fixes an issue where self-billed invoices received through Peppol were sometimes incorrectly assigned to the wrong company within a multi-company database. The system has been updated to accurately filter invoices based on the current company's details, ensuring correct accounting and reporting. This improves the reliability of Peppol invoice processing.
Original PR description
Currently, if a database has multiple companies registered on Peppol, receiving a self-billed invoice may assign it to the wrong company. The system was searching the journal using a domain that included all companies (in self), instead of filtering by the correct current company. Steps to reproduce: - Create a database with 2 companies, both on Peppol - Receive a self-billed invoice from a random other company on Peppol - The received invoice will potentially be assigned to the wrong company This is only a test forward-port of #257380 opw-6045669 Forward-Port-Of: odoo/odoo#259524 Forward-Port-Of: odoo/odoo#259072
This update resolves a problem where validating deliveries for kit products could trigger errors. The code was adjusted to correctly handle kit explosions during delivery validation, preventing tracebacks and ensuring accurate stock accounting. This ensures deliveries of kit products can be processed without interruption.
Original PR description
**Issue**: Making a product a kit could prevent confirming deliveries. **Steps to reproduce**: - Make sure the account application is installed - Create a product P without kit - Create a SO and…
**Issue**: Making a product a kit could prevent confirming deliveries. **Steps to reproduce**: - Make sure the account application is installed - Create a product P without kit - Create a SO and confirm it - Make the product P a kit - Validate the delivery associated to the SO -> A traceback occurs: the record does not exist anymore **Cause**: While confirming the delivery: https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/stock_account/models/stock_move.py#L168 It first filters which moves are out (`moves_out`). On the move associated with product P, since the kit is not exploded yet: https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/stock_account/models/stock_move.py#L172 Then explodes the kit: https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/stock_account/models/stock_move.py#L174 https://github.com/odoo/odoo/blob/ea18f34a48d61350f80c79894bef66bf02840bfc/addons/mrp/models/stock_move.py#L357-L361 By doing so, the original move associated to the product P are deleted: https://github.com/odoo/odoo/blob/ea18f34a48d61350f80c79894bef66bf02840bfc/addons/mrp/models/stock_move.py#L399 Thus, `moves_out` contains moves that no longer exist, and eventually, and eventually while accessing `product_id`: https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/stock_account/models/stock_move.py#L179 A traceback is thrown **Aditionnal information** Validating a delivery of a kit product whose moves were not exploded will trigger their explosion and require a second validation. Therefore, no stock valuation errors will be created. opw-6063602 Forward-Port-Of: odoo/odoo#260844 Forward-Port-Of: odoo/odoo#258403
This update fixes a bug where the shipping address wasn't appearing on Purchase Order and Request for Quotation (PO/RFQ) reports. The change involves updating how address information is passed within the Odoo system, ensuring that customer shipping addresses are now correctly displayed in these reports. This improves the accuracy of purchase order data.
Original PR description
Version: ---------- - saas-19.2+ Steps to reproduce: ---------------------- 1. Install `stock_dropshipping` and `sale_management` modules. 2. Create a Customer (res.partner) with a proper address…
Version:
----------
- saas-19.2+
Steps to reproduce:
----------------------
1. Install `stock_dropshipping` and `sale_management` modules.
2. Create a Customer (res.partner) with a proper address block.
3. Create a dropship product (route: Dropship).
4. Create a Sales Order for the created customer.
5. Add the dropship product.
6. Confirm the Sales Order to generate a Purchase Order.
7. Open the generated PO/RFQ and print the report.
Issue:
------
The shipping address is missing in the printed PO/RFQ report.
Cause:
--------
The `t-call` syntax is updated to use the new semantic, which passes
values *as attributes/parameters* on the `<t>` (with `t-call`) tag itself,
instead of relying on nested `t-set` directive.
- Old (Deprecated): Used nested `<t t-set='var_name' t-value='x'/>` tags
inside the calling element to define variables.
- New: Variables are passed as attributes directly on the element where
the `t-call` is located (e.g., `<t t-call='module.template' var_name='x'/>`).
A warning is added to alert developers when using the old deprecated
syntax.
see Reference: https://github.com/odoo/odoo/pull/197296
<details>
<summary>Click here to see the results:</summary>
<p><strong>Before:</strong></p>
<div class="image-row">
<img src="https://github.com/user-attachments/assets/c6892b30-10d6-4fb4-881c-1433d4fe07a0" />
</div>
<p><strong>After:</strong></p>
<div class="image-row">
<img src="https://github.com/user-attachments/assets/6109fcc3-5773-44a8-b07b-6566ed855d3f" />
</div>
</details>
> NOTE: We can also move test into `purchase_stock`
----
opw-6075017
---
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#257522A bug was causing night shift templates to incorrectly span an extra day. This update corrects a calculation error within the shift planning process, ensuring that night shift durations are accurately reflected. This fix prevents over-extended shifts and improves the reliability of our scheduling functionality.
Original PR description
Issue: ---------------------------------------- Creating a night shift from a template produces a shift spanning over one additional day. Steps to reproduce: ----------------------------------------…
Issue: ---------------------------------------- Creating a night shift from a template produces a shift spanning over one additional day. Steps to reproduce: ---------------------------------------- - Create a planning shift template form 23h to 1h the next day (2h) - It must have a span over 2 working days - Create a shift and use this template - The shift spans over one more day Cause: ---------------------------------------- In `_calculate_start_end_dates()`, we call `plan_days()` with `start` having the hours specified. So in `plan_days()` when retrieving the worked days, the first day is ignored because the resource is not supposed to be working from 23h to 1h (considering their calendar). Then we count two days, and so the end date is offset by one day. Solution: ---------------------------------------- We should call `plan_days()` without the hour specified so we make sure the first day is included in the count. opw-6134844 Forward-Port-Of: odoo/enterprise#114825 Forward-Port-Of: odoo/enterprise#114616
This update fixes a bug preventing calendar organizers (like administrators) from receiving reminder notifications. The issue stemmed from an outdated filtering method for identifying internal users, now corrected to ensure all organizers receive timely alerts. This improves meeting management and communication.
Original PR description
Steps to reproduce: --------------------------------- 1. Install Calendar module with demo 2. For both Users: User > Preferences > Notifications > In Odoo 3. Log in through Admin > Calendar > New…
Steps to reproduce:
---------------------------------
1. Install Calendar module with demo
2. For both Users: User > Preferences > Notifications > In Odoo
3. Log in through Admin > Calendar > New meeting
4. Set a start time in the near future
5. Add Marc Demo as an attendee
6. Under Options > Reminders, add a reminder that triggers shortly before the meeting (e.g., 15 minutes)
7. Save the meeting
8. Log in as Marc Demo in another browser window
9. Wait until the reminder time is reached
Observation:
---------------------------------
The reminder notification is displayed for Marc Demo. The Administrator (Mitchell Admin) does not receive any notification.
Issue:
---------------------------------
In `_notify_next_alarm`, the domain
`('group_ids', 'in', self.env.ref('base.group_user').ids)`
was used to filter internal users. However, the admin user does not have
`base.group_user` directly in their `group_ids`, it is only present in `group_ids.all_implied_ids` (inherited through group hierarchy). This caused the admin user to be excluded from the user search, so no bus alarm notification was sent to them.
Solution:
---------------------------------
The `share` field on `res.users` correctly identifies internal users (`share=False`) vs portal/public users (`share=True`) by checking the full group hierarchy, including implied groups. This ensures the admin (and all internal users) receive alarm notifications while still excluding portal and public users.
https://github.com/odoo/odoo/blob/b261223c8e15c412a06a0d938d217bdf0ab9f9ff/odoo/addons/base/models/res_users.py#L459-L464
opw-6010337
Forward-Port-Of: odoo/odoo#255263A recent update introduced a failing test in the web interface related to data limits. This commit resolves the underlying issue, ensuring the test now passes correctly. This prevents potential disruptions to the user experience.
Original PR description
PR [1] introduced a count limit test in v18, which was forward-ported to master/19.3. However, the forward-port was merged despite a silent failure caused by CSS changes in PR [2]. This commit fixes the failing test. [1] #259562 [2] #255332
This update resolves an issue preventing the AI's graph view feature from working correctly. The fix ensures that AI-generated groupings are processed properly, preventing a crash and allowing users to successfully generate and view data visualizations through the 'Ask AI' tool. This improves the usability of the AI-powered insights.
Original PR description
Steps to reproduce:
1. Install `crm`, `sale_management`.
2. Navigate to a list view (e.g. Sales > Orders).
3. Open the "Ask AI" chatbox from the system bar.
4. Ask: "graph view of opportunities per month".
5. [ISSUE] Client traceback after the agent loop tries to open the graph view with groupbys.
The pivot and graph AI tools emitted `rowGroupBys` / `groupBys`, but `search_model_patch` relies on `selectedGroupBys` (the key already used by the list/kanban tools). As a result, groupbys bypassed `applyAISearch` and, for graph, landed as raw `{field_name, intervals}` dicts in `modelParams.groupBy`, where `_normalize` crashed.
Rename the keys to `selectedGroupBys` so pivot/graph go through `applyAISearch` like list/kanban.
Task-ID: 6148879This update streamlines the handling of 'Unreachable' project tags by utilizing a pre-defined XML record instead of dynamic creation. This change improves stability and efficiency, ensuring consistent tag management within the Odoo Enterprise system. The old method has been removed and replaced with a more reliable approach.
Original PR description
Replace dynamic creation of the "Unreachable" tag with a static XML record `project_tag_db_unreachable` and use `env.ref()`. Remove the old helper method `_get_unreachable_tag_id()` and update tests accordingly.
This update corrects a technical issue that was causing some automated tests to fail in the Odoo timesheet module. The problem stemmed from a recent change in how floating-point numbers were formatted, specifically the removal of trailing zeros. This fix ensures that the tests accurately reflect the current functionality and prevents future test failures.
Original PR description
Before this commit, some hoot tests in hr_timesheet module failed because the formatting of float field in timesheet uom widget now removes the trailing zeros since the merge of #256621 This commit adapts the hoot tests.
This update corrects a technical issue where a duplicate record was incorrectly introduced in the French reporting module (l10n_fr_reports). This fix ensures data integrity and prevents potential reporting errors related to audit returns. The change is a minor correction to the existing system.
Original PR description
this forward port wrongly introduced an already existing record https://github.com/odoo/enterprise/pull/114739
This update fixes a technical issue where a key event wasn't being properly sent during a process, causing test failures. The change ensures the necessary parameters are included in the `BUS:OUTDATED` event, improving the stability and reliability of the Odoo system. This resolves a reported bug and confirms the system's continued functionality.
Original PR description
Since [1], the `BUS:OUTDATED` should be sent with the `unregisterMultiTab` parameter. But a call site doesn't send it, leading to test failures. [1]: https://github.com/odoo/odoo/pull/260380 fixes runbot-243238,243240,243239 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
This update corrects a UI issue that occurred when sign templates included roles with assigned users. A technical problem with how binary data was being handled caused errors and a broken user interface. The fix converts binary data to a standard base64 format, ensuring proper rendering and preventing errors during template loading.
Original PR description
Version: - saas-19.3 Steps to reproduce: - Create sign template with one role. - Set 'assign to' value to that role. - Try to refresh the page or again open the template. Issue: - sign item and roles are not render on template properly and UI get broken. - ConnectionLostError occurs when loading sign template with 'assign to' value on role. Cause: - After recent changes, Binary fields (avatar_128/avatar_1920) now return BinaryValue objects instead of base64 strings. - These objects are not JSON serializable and cause UnicodeDecodeError during RPC response serialization. Solution: - Convert BinaryValue to base64 string using .to_base64() before returning in get_template_items_roles_info. task-6122941
This update fixes an issue where users were incorrectly prompted with a zero-demand warning during immediate receipt validation via barcode scanning. The change bypasses this warning for immediate transfers, streamlining the process and preventing unnecessary interruptions. This ensures accurate and efficient receipt processing.
Original PR description
Issue before this commit: ========================= When validating an immediate receipt, the user gets a zero-demand warning wizard, even though quantities are actually being received. Steps to Reproduce: ========================= - Install the stock_barcode module - Create an immediate receipt. - Validate it. - The zero-demand warning wizard appears. Cause of the issue: ========================= This behaviour was introduced in a [PR](https://github.com/odoo/odoo/pull/241646/changes/0238ff2cdd58524da1d7fccb411a94d2bce73094) to warn users when confirming/validating a picking with zero-demand moves. However, for immediate transfers, demand (product_uom_qty) is always 0, so the condition is always true and the wizard is always shown, even when quantities are being processed. With This Commit: ========================= Avoid showing the zero-demand warning wizard when validating an immediate picking from the barcode interface.
This update corrects a display issue where the tip amount was incorrectly formatted (showing '415' instead of '4,15') when users overpaid in certain locales. The fix ensures the tip amount is correctly displayed based on the user's selected decimal separator, improving the user experience and accuracy of tip calculations.
Original PR description
Steps to reproduce 1. Set language decimal separator to "," and thousands separator to "." 2. Open PoS, create an order (e.g. total 17.85) 3. Pay more than the total (e.g. 22) 4. Open the Tip popup —…
Steps to reproduce
1. Set language decimal separator to "," and thousands separator to "."
2. Open PoS, create an order (e.g. total 17.85)
3. Pay more than the total (e.g. 22)
4. Open the Tip popup — it shows 415 instead of 4,15
5. Confirm — tip is set to 415
Issue
When overpaying, the change is passed as `startingValue` to the NumberPopup via
`String(amount)` (https://github.com/odoo/odoo/blob/b3d78644bc873b3b22f3fd5f8fc0cd27ce38999f/addons/point_of_sale/static/src/app/screens/payment_screen/payment_screen.js#L232),
which always uses "." as decimal separator. This value is used directly as the
display buffer in NumberPopup
(https://github.com/odoo/odoo/blob/b3d78644bc873b3b22f3fd5f8fc0cd27ce38999f/addons/point_of_sale/static/src/app/components/popups/number_popup/number_popup.js#L53),
so the user already sees "415" instead of "4,15" when the popup opens. When the
user confirms, `computeNewTip` parses this value with the locale-aware `parseFloat`
from `@web/views/fields/parsers`
(https://github.com/odoo/odoo/blob/b3d78644bc873b3b22f3fd5f8fc0cd27ce38999f/addons/point_of_sale/static/src/app/screens/payment_screen/payment_screen.js#L279
and https://github.com/odoo/odoo/blob/b3d78644bc873b3b22f3fd5f8fc0cd27ce38999f/addons/web/static/src/views/fields/parsers.js#L73-L83),
which uses `localization.thousandsSep` and `localization.decimalPoint` to interpret
the string. With "," as decimal separator and "." as thousands separator,
`parseFloat("4.15")` treats the "." as a thousands separator, strips it, and
returns 415 instead of 4.15.
opw-5895622
Forward-Port-Of: odoo/odoo#255273A technical issue preventing the 'Gelato: Order status update' email template from saving correctly has been resolved. The fix addresses a browser normalization problem that incorrectly rendered HTML, causing an error. This ensures the email template functions as expected.
Original PR description
**Steps to reproduce:**
- Go to Technical > Email > Email Templates
- Try to edit and save "Gelato: Order status update"
- QWebError is raised: `KeyError: 'tracking_data'`
**Issue:**
Browser html normalization silently move block elements such as `<ul>` outside `<p>` when rendering the template body_html as it is invalid html. This moved the `t-foreach="ctx['tracking_data']"` evaluation outside the surrounding `<t t-if="ctx.get('tracking_data')">` which triggered the error.
**Fix:**
Removed `p` element to use the outer `div` and avoid the issue for now.
related: https://github.com/odoo/odoo/commit/b24974d64c3afe5febdad9abff9cb23a333f1ada
similar: https://github.com/odoo/odoo/pull/256605
opw-6114223
Forward-Port-Of: odoo/odoo#259548