Saturday, June 28, 2025
24 changes · saas-18.4
Enhancements to existing features
The busy status now acts as the main way for users to avoid interruptions, replacing the previous mute-all behavior. When enabled, it mutes sound alerts and rejects incoming calls while keeping message counters visible, helping users focus without losing awareness of activity.
Original PR description
enterprise: https://github.com/odoo/enterprise/pull/88606 This commit adds behavior to the busy IM status. This status replaces the "mute all" behavior, with the exception of hiding counters and the addition of rejecting incoming calls and muting sound alerts. task-4889586
The busy status now replaces the previous mute-all behavior for WhatsApp conversations while still keeping message counters visible. When users are busy, incoming calls are rejected and sound alerts are muted, reducing interruptions during focused work.
Original PR description
community: https://github.com/odoo/odoo/pull/215866 This commit adds behavior to the busy IM status. This status replaces the "mute all" behavior, with the exception of hiding counters and the addition of rejecting incoming calls and muting sound alerts. task-4889586
Resolved issues and error corrections
Fixes a visual alignment issue in Discuss where live chat conversation items could appear off-center in the compact sidebar. This keeps the compact view cleaner and easier to scan for users managing chats.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/215447 PR above makes improvements to new livechat status feature, one of the improvement is to show the livechat status as floating icon on livechat conversation avatar in discuss sidebar when it's not in "in progress", i.e. "waiting customer" or "need help". At some point in dev, the icon was before the avatar when discuss sidebar was not compact. This was changed in last minute to floating icon too. However template kept lefovers of old design and mistakenly put a left margin in compact mode, leading to not centered discuss sidebar items in compact mode. This commit fixes the issue by reverting to original margin rules that was before the improvements made in PR above.
Miscellaneous changes
Before this commit, test "test_star_message" was failing frequently on runbot at step to check message was starred have click on "Mark as Todo". This happens because when click on mark as todo, the message is asynchronously starred. However, there's no visual indication other than the message action have yellow filled star icon. This requires hovering the message to see it, but we don't know when we should exactly hover the message to see it. This commit fixes the issue by adding a `data-s
Original PR description
Before this commit, test "test_star_message" was failing frequently on runbot at step to check message was starred have click on "Mark as Todo". This happens because when click on mark as todo, the message is asynchronously starred. However, there's no visual indication other than the message action have yellow filled star icon. This requires hovering the message to see it, but we don't know when we should exactly hover the message to see it. This commit fixes the issue by adding a `data-starred` on the `o-mail-Message` root node of message template that tells whether the message is starred or not. This removes necessity to hover to check whether message is starred. Fixes runbot-227568 Forward-Port-Of: odoo/odoo#216466 Forward-Port-Of: odoo/odoo#216106
This fix restores several website builder controls for carousel card snippets so they display correctly and work as expected. Users can now adjust extra height, see the right tooltips, and view translated position labels, improving editing reliability for website pages.
This update fixes a calculation error that could interrupt electronic invoice generation when invoice line quantities are zero. It also reorganizes related invoice line processing to make future maintenance and improvements safer.
Original PR description
We recently refactored UBL generation in 840bd1832ed. This commit makes some bugfixes/improvements: - prevent a ZeroDivisionError when `base_line['quantity'] == 0` - factorize the invoice line node code into a `_get_invoice_line_node` method - add the `_add_document_line_period_nodes` and `_add_document_line_pricing_reference_nodes` helpers. task-none
This update adds extra logging when email template validation fails during setup. It helps support and engineering teams diagnose rare installation issues more quickly, reducing investigation time when the problem occurs.
Original PR description
The installation of auth_signup can fail when creating mail templates. This issue is hard to reproduce and only occurs when a worker enters some broken state. Adding some log to help to solve the issue.
Fixes an issue where saving a custom website snippet could include temporary visual elements that were only meant for editing interactions. This prevents reused snippets, such as countdown blocks, from displaying incorrectly and helps keep website building reliable.
Original PR description
**Problem** Before this commit, custom snippets were saved including elements inserted by interactions (marked with `data-skip-history-hack`). These elements are not intended to be saved, and their…
**Problem** Before this commit, custom snippets were saved including elements inserted by interactions (marked with `data-skip-history-hack`). These elements are not intended to be saved, and their presence in the custom snippet could disrupt the normal functioning of an interaction (see `s_countdown` example below). This happened because interactions were not stopped before saving a snippet. **How to reproduce** 1. Save a custom snippet including `s_countdown`. E.g. insert `s_text_block`, then insert `s_countdown` in it, and finally save it as custom snippet. 2. Place the newly generated custom snippet on the page. 3. PROBLEM: the countdown rings are not centered anymore. Inspecting the page, one can see that `s_countdown` includes 8 canvas, the first 4 being invisible. **Solution** This commit introduces two new resources: `on_will_save_snippet_handlers` and `on_saved_snippet_handlers`, which are called by `saveSnippet` before and after cloning a snippet for saving. `EditInteractionPlugin` installs two handlers which stop the interactions before saving a custom snippet and restart the interactions after saving it. This way: 1. snippets are saved correctly; 2. we have a system that can be used in future to do other processing before and/or after the saving; and 3. interactions are not directly touched by `saveSnippet`. task-4367641
This fixes an error that could occur when editing website content and changing the Discussion Group snippet option. The update makes the builder handle non-text values correctly, preventing interruptions during page editing.
Original PR description
In some cases the value passed might be not string (e.g. a number),
so we don't need to check if it starts with ('var(--)'). Also, since the data-* attributes
are always strings we need to convert the value to a string when comparing them.
To replicate the error, open website and start editing, drop a "Discussion Group" snippet,
click on it, go to the Discussion Group option and change its value to something else
=> We have an error.
This commit follows [the html_builder refactoring].
[the html_builder refactoring]: odoo/odoo@9fe45e2b7ddb
Related to task-4367641This fixes the styling of date picker header buttons so they better blend with different page backgrounds, including frontend pages and dark mode. The change removes awkward button backgrounds and borders while keeping a simple hover effect, making the interface look more consistent across Odoo editions.
Original PR description
After [1], each button is separated and therefore has its own border radius and background color. On the backend side, using the ´.btn-light´ class works well since it matches the background of our…
After [1], each button is separated and therefore has its own border radius and background color. On the backend side, using the ´.btn-light´ class works well since it matches the background of our views. However, on the frontend, the background color is dynamic and does not match the page background, leading to a visually awkward result. One possible solution is to reintroduce the ´.btn-group´ class, but only wrap the "Previous" and "Next" buttons, which makes sense. However, we preferred to simply remove ´.btn-light´, which eliminates background and border issues. We only want a hover effect, similar to the one already implemented for the modal "expand" button. The result is consistent across Community, Enterprise, Backend, Frontend, and Dark mode. Additionally, the font size has been removed to ensure consistent button height, and ´text-transform´ no longer seems necessary. [1]: https://github.com/odoo/odoo/commit/e2b78fca435f268515f9593c2af821616aff7ebb 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
Website headers now keep selected preset background and text colors after saving, instead of reverting to the default styling. This preserves the intended site appearance for users customizing headers in the website builder.
Original PR description
Steps to reproduce: - Open website builder and click on header - Set "Header Position" to "Over The Content" - Set the "Background" color to one of the suggestion (not from the arbitrary picker) - Set the "Text Color" to one of the suggestion from the "Custom tab" - Save - Bug: The colors of the header are reset to default This issue was introduced during the initial refactor of website builder Website refactor: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-4367641
This update fixes failing automated builds caused by recent changes to the cash basis report. It updates the related tests so they match the current report structure and no longer rely on outdated behavior.
Original PR description
The builds were failing due to this PR: https://github.com/odoo/enterprise/pull/72675 The reason is that we removed one column of the report. Another issue is that a test was trying to call an old expand function which is not in use anymore. Build failing: https://runbot.odoo.com/odoo/runbot.build.error/226793/runbot.build.error/226793
Before this commit, the "jump present" button when scrolling to older messages was displayed when going quite far in older messages. This happens because condition was: greater distance of either 3 times the view port client height and 10 times the height of most recent messages. When most recent messages are very big, this can be long until to see the jump to present. Also when there are lots of messages, 3 times the scroll client height can be a bit too much. In the past the "jump to
Original PR description
Before this commit, the "jump present" button when scrolling to older messages was displayed when going quite far in older messages. This happens because condition was: greater distance of either 3…
Before this commit, the "jump present" button when scrolling to older messages was displayed when going quite far in older messages. This happens because condition was: greater distance of either 3 times the view port client height and 10 times the height of most recent messages. When most recent messages are very big, this can be long until to see the jump to present. Also when there are lots of messages, 3 times the scroll client height can be a bit too much. In the past the "jump to present" UI was a banner so we were tempted to show when user was likely to want to jump to present. This is a small button now so we can be much more eager to its showing. This commit removes the condition to recent message height and just uses the height of scroll client height for the showing of jump to present. Before / After   Forward-Port-Of: odoo/odoo#213833
When building `base_tax_line_mapping`, the JOIN on `affecting_base_tax_ids` was effectively scanning the CTE as many times as there were tax lines in the domain. This lead to computing a number of rows equivalent to the number of base lines times the number of tax lines; so O(n²). Using a LATERAL JOIN helps in avoiding that behavior and only getting the lines needed in each loop.Description of the issue/feature this PR addresses: Forward-Port-Of: odoo/odoo#216186 Forward-Port-Of: odoo/odo
Original PR description
When building `base_tax_line_mapping`, the JOIN on `affecting_base_tax_ids` was effectively scanning the CTE as many times as there were tax lines in the domain. This lead to computing a number of rows equivalent to the number of base lines times the number of tax lines; so O(n²). Using a LATERAL JOIN helps in avoiding that behavior and only getting the lines needed in each loop.Description of the issue/feature this PR addresses: Forward-Port-Of: odoo/odoo#216186 Forward-Port-Of: odoo/odoo#215411
**Steps to reproduce:** From a Romanian company with the RO localization configured, when processing a payment transaction from the e-commerce, it can happen that the creation of the invoice fails due to a SerializationFailure but the EDI is correctly sent to the government service. As the creation of the invoice has failed, the system will retry to create it and trigger the sending of the EDI again. **Solution:** Trigger a commit before sending the EDI. opw-4844913 --- I confi
Original PR description
**Steps to reproduce:** From a Romanian company with the RO localization configured, when processing a payment transaction from the e-commerce, it can happen that the creation of the invoice fails due to a SerializationFailure but the EDI is correctly sent to the government service. As the creation of the invoice has failed, the system will retry to create it and trigger the sending of the EDI again. **Solution:** Trigger a commit before sending the EDI. opw-4844913 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216295 Forward-Port-Of: odoo/odoo#216114
Actually update to use new email domain --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216195
Original PR description
Actually update to use new email domain --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216195
**Current behavior before PR:** Prior to this PR, when a subthread was created from a deleted message, the thread name appeared empty. **Desired behavior after PR is merged:** the issue is resolved by setting the thread name to "New Thread" when the original message is deleted. task-4665143 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205828
Original PR description
**Current behavior before PR:** Prior to this PR, when a subthread was created from a deleted message, the thread name appeared empty. **Desired behavior after PR is merged:** the issue is resolved by setting the thread name to "New Thread" when the original message is deleted. task-4665143 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205828
[FIX] l10n_in_ewaybill: Prevent duplicate e-way bills during demo data load Steps to Reproduce: 1. Run the Odoo app from the terminal without installing demo data. 2. Install the l10n_in_ewaybill module. 3. Load demo data from the App Settings. 4. Select the IN Company. 5. Open any invoice. Issue: - An error occurs when opening the invoice page. Reason: - The method that generates demo data was being called twice during demo data loading. - As a
Original PR description
[FIX] l10n_in_ewaybill: Prevent duplicate e-way bills during demo data load Steps to Reproduce: 1. Run the Odoo app from the terminal without installing demo data. 2. Install the l10n_in_ewaybill…
[FIX] l10n_in_ewaybill: Prevent duplicate e-way bills during demo data load
Steps to Reproduce:
1. Run the Odoo app from the terminal without installing demo data.
2. Install the l10n_in_ewaybill module.
3. Load demo data from the App Settings.
4. Select the IN Company.
5. Open any invoice.
Issue:
- An error occurs when opening the invoice page.
Reason:
- The method that generates demo data was being called twice during demo data loading.
- As a result, two e-way bills were created per invoice instead of one, which led to errors.
- Additionally, the condition in the account.move model was assuming only one e-way bill per invoice, causing incorrect logic.
Fix:
- Added a check before creating the e-way bill to verify whether it has already been created or not
- Also fixed the logic in the account.move model to properly handle the e-way bill state check.
task: 4777642
Forward-Port-Of: odoo/odoo#216165
Forward-Port-Of: odoo/odoo#208825Before this commit: =================== - Cash in/out time was displayed incorrectly, not reflecting the local timezone. - Today's cash in/out date was shown as the actual date instead of using the `Today` label. - The cash in/out label was not properly aligned for responsive UI. Issue: ====== - The datetime was stored in UTC but interpreted using the system timezone, causing a mismatch. - The value was already a DateTime object but was unnecessarily re-parsed, leading to incorrect res
Original PR description
Before this commit: =================== - Cash in/out time was displayed incorrectly, not reflecting the local timezone. - Today's cash in/out date was shown as the actual date instead of using the `Today` label. - The cash in/out label was not properly aligned for responsive UI. Issue: ====== - The datetime was stored in UTC but interpreted using the system timezone, causing a mismatch. - The value was already a DateTime object but was unnecessarily re-parsed, leading to incorrect results. After this commit: ================== - Cash in/out time now displays correctly according to the local timezone. - Today's date is properly labeled as `Today` instead of displaying the date directly. - Cash in/out labels are properly aligned and displayed across different screen sizes for responsive UI. Task-4862777 Forward-Port-Of: odoo/odoo#214198
Before this commit: When adding any statement line with a date in the future, the amount is reflected in the journal's final balance. While it's not considered when calculating the graph points of the dashboard. Which results in a discrepancy between balances and graph points of all past points. With this commit: Future points are considered in graph points aggregation and visualization. Steps: 1- Create 2 bank transaction in a bank journal one with date in the past, the other in futu
Original PR description
Before this commit: When adding any statement line with a date in the future, the amount is reflected in the journal's final balance. While it's not considered when calculating the graph points of the dashboard. Which results in a discrepancy between balances and graph points of all past points. With this commit: Future points are considered in graph points aggregation and visualization. Steps: 1- Create 2 bank transaction in a bank journal one with date in the past, the other in future. 2- Check dashboard graph points of past transaction, will notice a difference between the graph point and real balance. (difference amount is exactly equal the future transaction amount) opw-4823770 Forward-Port-Of: odoo/odoo#216102 Forward-Port-Of: odoo/odoo#214641
Because recordsets are immutable, `-=` is in O(n), and doing it in a loop is therefore O(n²). Forward-Port-Of: odoo/enterprise#88704 Forward-Port-Of: odoo/enterprise#88261
Original PR description
Because recordsets are immutable, `-=` is in O(n), and doing it in a loop is therefore O(n²). Forward-Port-Of: odoo/enterprise#88704 Forward-Port-Of: odoo/enterprise#88261
When we are trying to auto review returns, we are not checking if the return is a new return and it was possible for checks in the submitted state to be set back to the reviewed state. task-4900867 Forward-Port-Of: odoo/enterprise#88638
Original PR description
When we are trying to auto review returns, we are not checking if the return is a new return and it was possible for checks in the submitted state to be set back to the reviewed state. task-4900867 Forward-Port-Of: odoo/enterprise#88638
opw-4816130 Forward-Port-Of: odoo/enterprise#88744
Original PR description
opw-4816130 Forward-Port-Of: odoo/enterprise#88744
Add the computed current year profit/loss to the balance sheet to have the full picture as expected Translation files were changed based on Odoo Export, so I guess the diff is ok as it will anyway appear with the next code change if created from the system. Info: @wt-io-it Forward-Port-Of: odoo/enterprise#86823 Forward-Port-Of: odoo/enterprise#83875
Original PR description
Add the computed current year profit/loss to the balance sheet to have the full picture as expected Translation files were changed based on Odoo Export, so I guess the diff is ok as it will anyway appear with the next code change if created from the system. Info: @wt-io-it Forward-Port-Of: odoo/enterprise#86823 Forward-Port-Of: odoo/enterprise#83875