Friday, April 24, 2026
24 changes · saas-19.3
Enhancements to existing features
This update enhances the visibility of tax return export files for users. Instead of attaching them to the record, the system now posts them to the chatter thread upon return validation, making them easily accessible for review and discussion. This simplifies the process of accessing and sharing these important documents.
Original PR description
The xml and pdf of export of the tax return are not so visible for the user, thus the change creates the files on the validation of the returns and exports them to the chatter where they would be pinned task: 5871091 Forward-Port-Of: odoo/enterprise#111769
This update enhances the Odoo Website Builder AI agent by granting it immediate access to image generation and web search tools. Previously, the agent wasn't aware of these tools at the start of a conversation, limiting its capabilities. Now, the agent can proactively utilize these features, improving user experience and efficiency.
Original PR description
__Before commit__ Since odoo/enterprise@be7cb24c, the AI topics are not loaded in the context from the start. Therefore, although the Website Builder AI topic has access to the image generation tool, the agent isn't necessarily aware of it at the start. Moreover, the Website Builder agent is currently unable to perform web searches. __After commit__ The Website Builder agent now has access to the image generation topic as well as the web search topic. It will therefore be aware of those tools from the start of the conversation. task-6143594
Resolved issues and error corrections
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 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 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 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 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 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 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
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 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 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 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#257522This 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#255263This 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 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