Thursday, March 20, 2025
24 changes · 18.0
Resolved issues and error corrections
Odoo Discuss now consistently dims conversation names when they are muted, whether muting is applied globally or to a specific thread. This makes it easier for users to distinguish muted conversations while keeping inactive threads visible in the sidebar.
Original PR description
Description of the issue/feature this PR addresses: The goals of the PR are multiple: - The thread names in the discuss app are not muted when "mute all conversations" is enabled or when the specific thread is muted. - The threads with no new messages are invisible when the parent thread is muted Current behavior before PR: see above Desired behavior after PR is merged: The thread opacity is set to 50 whenever the thread is muted (by any of the two ways) task-4607160 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures payment references are generated correctly when a customer pays a single overdue invoice. It helps keep payment records accurate and easier to reconcile, reducing confusion for accounting teams.
Original PR description
computed by dedicated method _compute_reference when a single invoice is overdue.
The mail interface now hides the individual 'mute conversation' button when the user has already enabled 'mute all conversations'. This avoids showing an unnecessary option and makes notification settings clearer for users.
Original PR description
**Current behavior before PR**: The 'mute conversation' button was always visible, even when 'mute all conversations' was enabled. **Desired behavior after PR is merged**: The 'mute conversation' button is hidden when 'mute all conversations' is enabled task-[4630970](https://www.odoo.com/odoo/project/1519/tasks/4630970) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes how employee work entries are generated when a contract uses a fully flexible schedule. Time off is no longer calculated from a non-existent working schedule, helping avoid incorrect work entry records for affected employees.
Original PR description
In case of fully flexible working schedules, the leaves must not be computed from the working schedule (as there is none). The test for this bug is in the following related PR: https://github.com/odoo/enterprise/pull/80785 task-4623219
This fix preserves whether the chatter panel was open when users move between to-dos, including when opening a to-do from the activity view. It makes the To-Do app behave more consistently and avoids extra clicks for users who rely on the chatter.
Original PR description
Steps to reproduce: - Open To-Do app - Open a todo and click on chatter - Go back and open another todo - The chatter is closed by default Issue: - The chatter should be opened if opened earlier - If todo opened from activity view chatter is not opened Reason: - No logic to preserve the state if chatter. Solution: - Using local storage to store the state of the chatter and thus apply changes accordingly. task-4592501
The stock replenishment flow now warns users when they try to snooze an automatically created replenishment rule that cannot keep the snooze setting after refresh. This prevents confusion where an item appears hidden at first but reappears because the snooze date was not preserved.
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”
- Go to Operations > Replenishment:
- An orderpoint is created for “P1”
- Click on the Snooze button:
- Snooze for 1 day
- Snooze date: today
- The orderpoint for "P1" becomes invisible thanks to the “Snooze” filter
- Refresh the page
Problem:
The snooze filter is correctly applied, but an orderpoint for "P1" is still visible. This happens because the old snoozed orderpoint was unlinked, and a new one was created without the snoozed_until field set.
https://github.com/odoo/odoo/blob/18.0/addons/stock/models/stock_orderpoint.py#L596-L599
opw-4628611Forum page links used for search and sharing metadata now include the correct language setting and handle redirected URLs more reliably. This helps visitors and search engines land on the right localized forum content, including reply links with page anchors.
Original PR description
Previously, the `lang` parameter was missing from the URL, and URLs were not correctly updated when a 308 redirect was present. This commit ensures that the `lang` parameter is added and that URLs are properly converted after a 308 redirect.
A test in the website tour tooling has been temporarily skipped because it was producing inconsistent results. This helps keep automated checks reliable while the team redesigns a better way to detect this type of issue.
Original PR description
We're skipping the unit test to check for indeterminisms with mutations. Indeed, the strategy for detecting this kind of indeterminism needs to be rethought, and for the moment, this test is failing in an indeterministic way (lol) in master. 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 fixes a problem where some invoice pages could fail to load when installment information was unavailable. The invoice template now handles missing or empty installment status safely, improving reliability for customers viewing invoices online.
Original PR description
Previously, when installment_state was None,
the template raised an error because None in ('next', 'overdue') is not a valid operation.
This change ensures safe access to installment_state using .get(), preventing potential errors when
the key is missing or its value is None.
**Description of the issue/feature this PR addresses:**
The invoice template was raising an error when installment_state was None, as the condition None in ('next', 'overdue') is invalid.
**Current behavior before PR:**
If installment_state is None, the template crashes due to an invalid comparison.
**Desired behavior after PR is merged:**
The template now safely retrieves installment_state using .get(), preventing errors when the key is missing or its value is None.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prKanban card footers now display multiple items on additional lines instead of spilling into neighboring cards. This keeps card content readable and prevents visual overlap when many footer items are shown.
Original PR description
Before this commit, when the footer had many items, those were not wrapped so, the overflew under the next card. After this commit, elements inside the footer are wrapped, and they overflow on a next line. task-4609581 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
Documents kanban cards once again display tags that have no assigned color, preserving the experience users already expect. The update also includes internal cleanup and test modernization for the Documents area, helping keep future changes safer without changing day-to-day workflows.
Original PR description
Even though it's been commonplace in Odoo for a while, tags (or more precisely facets) with index-0/False color where still shown on Documents kanban cards. This should remain the case functionally as users are not expected to go and change the color of all their tags, nor can we decide for them at upgrade (and it'd be too late for many as well). Task-4645015 Also, cleaning up some test stuff for hoot. See details in individual commits. Task-3861500
This update fixes internal tests for Project Enterprise scheduling so they no longer incorrectly depend on the timesheet feature being present. It helps keep quality checks stable and reduces the chance of false failures during development or releases.
Original PR description
Same logic as: https://github.com/odoo/enterprise/pull/79947 rb-145524 rb-145525
Invoice reports now display the authorized signatory image without stretching it to full width. This preserves the signature’s original proportions, making printed or shared invoices look more professional and accurate.
Original PR description
The authorized signatory image is resized and loses it's aspect ratio. To fix, the w-100 (100% width) class is removed. OPW-4586108
Code cleanup and technical improvements
This update cleans up how automated tests define views across several Odoo Enterprise apps. It is an internal maintenance change that helps keep test code easier to maintain without changing customer-facing functionality.
Miscellaneous changes
In order to avoid locking for longer periods, we want to put the sequence assignment as late as possible in the SQL transaction. In order to do that, we flush everything before assigning the number so that the ORM doesn't have to flush it implicitly before committing. We also reuse the same savepoint to avoid messing with the memory of Postgres Forward-Port-Of: odoo/odoo#201673 Forward-Port-Of: odoo/odoo#201171
Original PR description
In order to avoid locking for longer periods, we want to put the sequence assignment as late as possible in the SQL transaction. In order to do that, we flush everything before assigning the number so that the ORM doesn't have to flush it implicitly before committing. We also reuse the same savepoint to avoid messing with the memory of Postgres Forward-Port-Of: odoo/odoo#201673 Forward-Port-Of: odoo/odoo#201171
Original PR description
## Pull Request HOOT (PRHOOT) 29 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Community: https://github.com/odoo/odoo/pull/199461 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
[FIX] account: default_account_id removal from context when reversing analytic distribution When accessing journal items from a report, the context often includes default_account_id. When changing the account of a journal item, new analytic items are created, inheriting an account_id field. If account_id is False, it is automatically populated from default_account_id, which is sourced from account.account instead of account.analytic.account. This mismatch leads to the error: ```The operatio
Original PR description
[FIX] account: default_account_id removal from context when reversing analytic distribution When accessing journal items from a report, the context often includes default_account_id. When changing the account of a journal item, new analytic items are created, inheriting an account_id field. If account_id is False, it is automatically populated from default_account_id, which is sourced from account.account instead of account.analytic.account. This mismatch leads to the error: ```The operation cannot be completed: another model requires the record being deleted. If possible, archive it instead.``` This fix moves when we remove the default_account_id from context to ensure it is removed despite the call stack not including the function _inverse_analytic_distribution opw-4443816 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200200
Reduce the memory footprint and slightly improve the performance of export, especially when we traverse multiple levels of relational fields. We replace the https://github.com/odoo/odoo/pull/22494 solution because it is only works at the top level of the export, to avoid invalidating records that may be used by the next iteration, and because the cache memory footprint of the cache has been reduced in recent years anyway. Instead, we explicitly read the only asked fields recursively. Memo
Original PR description
Reduce the memory footprint and slightly improve the performance of export, especially when we traverse multiple levels of relational fields. We replace the https://github.com/odoo/odoo/pull/22494…
Reduce the memory footprint and slightly improve the performance of export, especially when we traverse multiple levels of relational fields. We replace the https://github.com/odoo/odoo/pull/22494 solution because it is only works at the top level of the export, to avoid invalidating records that may be used by the next iteration, and because the cache memory footprint of the cache has been reduced in recent years anyway. Instead, we explicitly read the only asked fields recursively. Memory/Performance changes: For exporting 10K of stock.picking (Transfers) with basic fields of the list view: ``` Before: 25 Mb of memory peak - 31 SQL requests, +- 55 ms of queries, +- 2440 ms of Python After : 29 Mb of memory peak - 31 SQL requests, +- 45 ms of queries, +- 2402 ms of Python ``` For exporting 10K of stock.picking (Transfers) with their stock moves (30K) and their stock move line (4K): ``` Before: 191 Mb of memory peak - 162 SQL requests, +- 455 ms of queries, +- 7050 ms of Python After : 140 Mb of memory peak - 129 SQL requests, +- 315 ms of queries, +- 6930 ms of Python ``` Forward-Port-Of: odoo/odoo#200900 Forward-Port-Of: odoo/odoo#199218
The field `res.config.settings.l10n_ro_edi_client_id` [[1]](https://github.com/odoo/odoo/blob/63e0285ade407074c8e054d6d14a71b633d55f17/addons/l10n_ro_efactura/models/res_config_settings.py#L7C5-L7C26) [[2]](https://github.com/odoo/odoo/blob/63e0285ade407074c8e054d6d14a71b633d55f17/addons/l10n_ro_efactura/models/res_company.py#L18) in module `l10n_ro_efactura` has the same label `Client ID` as the field `res.config.settings.auth_oauth_google_client_id` [[3]](https://github.com/odoo/odoo/blob/63e0
Original PR description
The field `res.config.settings.l10n_ro_edi_client_id`…
The field `res.config.settings.l10n_ro_edi_client_id` [[1]](https://github.com/odoo/odoo/blob/63e0285ade407074c8e054d6d14a71b633d55f17/addons/l10n_ro_efactura/models/res_config_settings.py#L7C5-L7C26) [[2]](https://github.com/odoo/odoo/blob/63e0285ade407074c8e054d6d14a71b633d55f17/addons/l10n_ro_efactura/models/res_company.py#L18) in module `l10n_ro_efactura` has the same label `Client ID` as the field `res.config.settings.auth_oauth_google_client_id` [[3]](https://github.com/odoo/odoo/blob/63e0285ade407074c8e054d6d14a71b633d55f17/addons/auth_oauth/models/res_config_settings.py#L15C5-L15C32) from module `auth_oauth`. Field labels should be unique on the same model so we can change the label and set it in the view where this setting is shown. starting `saas-17.4` the change should be applied to module `l10n_ro_edi` as the efactura was merged in it --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202422 Forward-Port-Of: odoo/odoo#201110
In #195395, the following test suite should first check if the global_result is already stopped --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201800
Original PR description
In #195395, the following test suite should first check if the global_result is already stopped --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201800
Description of the issue/feature this PR addresses: This commit addresses inaccurate calculation of statistics in surveys. The survey fields `answer_score_avg` and `success_ratio` are affected. Current behavior before PR: These are currently using the number of completed surveys as the total number of surveys, but they are gathering data from all surveys, completed or not. This results in broken statistics when there are in progress or incomplete surveys. The values become too high, in
Original PR description
Description of the issue/feature this PR addresses: This commit addresses inaccurate calculation of statistics in surveys. The survey fields `answer_score_avg` and `success_ratio` are affected. Current behavior before PR: These are currently using the number of completed surveys as the total number of surveys, but they are gathering data from all surveys, completed or not. This results in broken statistics when there are in progress or incomplete surveys. The values become too high, including `success_ratio` being above 100%! Desired behavior after PR is merged: The proposed solution is simply to consider all answers to the survey so that the statistics can accurately reflect the scores across all initiated surveys. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197849
Issue Before This Commit: ============================ The system activate inappropriate rules in routes, including those where the rule itself is active but it's destination location is inactive. Steps to Reproduce: ============================ - Install the stock & MRP modules. - Activate multi-step routes and the MTO route. - Notice that 'WH: Stock → Pre-Production (MTO)' rule appears, even when the rule is active but its destination location is inactive. - Go to the warehou
Original PR description
Issue Before This Commit: ============================ The system activate inappropriate rules in routes, including those where the rule itself is active but it's destination location is inactive.…
Issue Before This Commit: ============================ The system activate inappropriate rules in routes, including those where the rule itself is active but it's destination location is inactive. Steps to Reproduce: ============================ - Install the stock & MRP modules. - Activate multi-step routes and the MTO route. - Notice that 'WH: Stock → Pre-Production (MTO)' rule appears, even when the rule is active but its destination location is inactive. - Go to the warehouse, enable the 3-step MRP then switch back to the 1-step MRP. - Go to the MTO route and see that only active rules are now shown. With This Commit: ============================ This commit resolves the issue where the unarchiving route unintentionally restored all associated rules, regardless of their active status. Now, only rules that are active and it's destination location is active are displayed in routes, where inactive ones are filtered out based on the destination location's active status. task - [4577280](https://www.odoo.com/odoo/project.task/4577280) Forward-Port-Of: odoo/odoo#197754
Mercado Pago requires the X-platform-id header to be passed in all requests to their platform to keep track of the amount of odoo customers that exist. This key is not secret and perfectly fine to be committed in this repo without worry. task-4628319 Forward-Port-Of: odoo/odoo#200864
Original PR description
Mercado Pago requires the X-platform-id header to be passed in all requests to their platform to keep track of the amount of odoo customers that exist. This key is not secret and perfectly fine to be committed in this repo without worry. task-4628319 Forward-Port-Of: odoo/odoo#200864
Also: - Add some missing gettext + proper list formattings - Fix some incorrect English since the modules haven't been translated yet so no translations will be lost. Note that the English of "Allow to export Working Entries to your Social Secretariat" was purposely left bad since it's used in other already translated modules + it's expected that only Belgians will be using the modules and/or the modules will be used only in French/Dutch
Original PR description
Also: - Add some missing gettext + proper list formattings - Fix some incorrect English since the modules haven't been translated yet so no translations will be lost. Note that the English of "Allow to export Working Entries to your Social Secretariat" was purposely left bad since it's used in other already translated modules + it's expected that only Belgians will be using the modules and/or the modules will be used only in French/Dutch
Problem: The WhatsApp template's attachment is set on the mail message of the related WhatsApp message. If the user deletes the mail message's attachment, the template's attachment also gets deleted. Solution: Instead of directly linking the template attachment, the attachment will be cloned with the appropriate `res_id` and `res_model` before sending. This ensures that the original template attachment remains intact even if the message attachment is removed. Task-4626855 Forward-Po
Original PR description
Problem: The WhatsApp template's attachment is set on the mail message of the related WhatsApp message. If the user deletes the mail message's attachment, the template's attachment also gets deleted. Solution: Instead of directly linking the template attachment, the attachment will be cloned with the appropriate `res_id` and `res_model` before sending. This ensures that the original template attachment remains intact even if the message attachment is removed. Task-4626855 Forward-Port-Of: odoo/enterprise#80760