Monday, June 30, 2025
56 changes · saas-18.4
Enhancements to existing features
The public employee area now shows the same updated help screen as the private employee area. This creates a more consistent experience for users viewing employee information and reduces confusion between the two views.
Original PR description
This PR adds the new help screen to the public employee action to align it with the private one. Task: 4886479 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Fixes a display issue in Mail where clearing a message while editing could make the empty message bubble stretch across the full conversation area. This keeps chat and discussion views cleaner and avoids confusing visual glitches for users.
Original PR description
This commit fixes a UI bug where editing a message and clearing its content results in the message bubble expanding to full width. **Current behavior before PR:**  **Desired behavior after PR is merged:** 
Features or functions removed from Odoo
The web interface no longer shows the reset filters button in the action helper. This simplifies the screen and removes an option that was no longer needed, with related view tests updated to match the new behavior.
Original PR description
This commit removes the button used to reset filters in the action helper. task-4891535
Miscellaneous changes
This commit fixes the calculation of the duration of an attendance record for an employee on a fully flexible working schedule. Previously, we were using the adjusted start and end times, which were adjusted from their original values to be the outer bounds of the interval made up of the original times and the UTC-converted times. This resulted in a duration that was too long. Now, we use the original start and end times to calculate the duration of the attendance because this value is ti
Original PR description
This commit fixes the calculation of the duration of an attendance record for an employee on a fully flexible working schedule. Previously, we were using the adjusted start and end times, which were adjusted from their original values to be the outer bounds of the interval made up of the original times and the UTC-converted times. This resulted in a duration that was too long. Now, we use the original start and end times to calculate the duration of the attendance because this value is timezone-agnostic. Forward-Port-Of: odoo/odoo#214918 Forward-Port-Of: odoo/odoo#213700
The live chat widget now waits for the correct availability check before showing the start chat button. This prevents visitors from briefly seeing a chat option that may not actually be available, creating a smoother website experience.
Original PR description
When the live chat is loaded on a page, it receives a value called `isAvailable` from the session. This name is misleading: it indicates availability if either an agent or a bot is present, but it…
When the live chat is loaded on a page, it receives a value called `isAvailable` from the session. This name is misleading: it indicates availability if either an agent or a bot is present, but it doesn’t consider the live chat rules.
These rules depend on the URL. Since `get_livechat_info` is called from the website template, we can’t determine which rule applies at that point. The goal is mainly to avoid calling `init_livechat` ("/mail/data") if we already know the live chat won’t be available. However, this check alone isn’t enough to decide whether to show the chat button.
This commit renames `isAvailable` to `can_load_livechat` for clarity. If `can_load_livechat` is set, we can load the live chat and call `init_livechat`, which will then set the `livechat_available` value.
task-4908197
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-prWebsite editing could show duplicate live chat bubbles and windows because both editing and visitor assets were loaded at the same time. This fix keeps the chat experience clean during website editing by hiding the extra chat elements with styling, avoiding more complex communication between page frames.
Original PR description
When editing is enabled, the website loads both the backend and frontend assets. Until [1], this resulted in two sets of chat windows and bubbles being displayed. This commit is a follow-up to the above PR, maintaining the same behavior but relying only on styles. This avoids the need for cross-iframe or cross -window communication. [1]: https://github.com/odoo/odoo/pull/212452 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
The messaging menu button in the top bar now displays with the correct background. This fixes a small visual issue so the interface looks consistent and polished for users.
Original PR description
This commit fixes a background issue on the messaging menu button in the systray. issue introduced by: https://github.com/odoo/odoo/pull/198012 before:  after: 
This update fixes a broken automated test for the website editor so the test suite better reflects the current behavior. It helps maintain release stability by reducing false test failures during development and deployment checks.
Original PR description
This commit adapt the broken tests test_05_specific_website_editor.
Clicking a GIF preview in Mail now works without triggering an error when no click handler is available. This prevents a confusing interruption for users who open GIF links from messages.
Original PR description
**Current behavior before PR:** When a user posts a GIF link and clicks the preview, it opens in a new tab but throws an error because `props.onClick` is called unconditionally, even if undefined. **Desired behavior after PR is merged:** The issue is fixed by ensuring `props.onClick` is only called if it is defined. **Task**-4908537 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now only shows the quick-create option for grouped list and kanban views when the view uses its intended default grouping. This prevents confusing or unsupported behavior when users group records by other fields.
Original PR description
This commit updates the conditions for enabling group quick create in list and kanban views. In addition to existing checks, the view must now be grouped using its default groupby (if defined) for quick create to be available. This ensures that group quick create is only shown in contexts where it is properly supported and avoids undesired behavior when grouping by arbitrary fields. task-4897809
This fixes a small error in how the Time Off app checks which team members are currently online. The change makes the status check more reliable and reduces the risk of incorrect availability information being shown.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/198012 PR above made a typo in code in which list of "online" member IM status is a list of string, and it uses + to concatenate items like in python but this doesn't work in JS. Thankfully it kinda "worked" because this casted the array into list (e.g. `["a", "b"]` becomes "a,b") and other items were appended to string. Since this list was used for `.includes()` by chance the ".includes()" method is on Array and String and functionally this results to about the same intention... Again by chance!
Restores the missing help tooltip in the website builder's product filter dropdown. This makes it easier for website editors to understand filter choices such as recently viewed products when configuring product snippets.
Original PR description
> [LIPI] Missing dynamic filter help tooltip added in https://github.com/odoo/odoo/pull/196493 (quick fix: `title="fitler.help"` in dynamic_snippet_option.xml:9) Steps to reproduce: - Open website builder (with website_sale) - Drop snippet `s_dynamic_snippet_products` - Open the "Filter" dropdown and hover "Recently Viewed Products (...)" - Bug: No tooltip appears with a help message The tooltip with a help message on filter option was implemented on master in parallel of the initial refactor of the website builder. This commit adds the tooltip on the refactored builder Help on filter option: 5e21f518d285d0e3ca619ba3505ded6da5fb2e67 Website refactor: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-4367641
This fixes a crash that could happen in the website HTML builder when users moved the mouse while pressing a key. The change keeps editing interactions stable and avoids interrupting page-building work.
Original PR description
__Current behavior before commit:__ The `onMouseMoveOrDown` event listener is inside `throttleForAnimation` therefore it might be called asynchronously. In this case `ev.currentTarget` is `null` and the following traceback appears when we move the mouse while pressing a key in the html builder: ``` TypeError: Cannot read properties of null (reading 'removeEventListener') ``` __Description of the fix:__ Replace `ev.currentTarget` by `this.editable` since the `onMouseMoveOrDown` event listener is always added on the latter.
This fix prevents an error when loading restaurant sample data after product categories have been removed. It adds a fallback so the sample sushi combo product can still be created, helping users set up restaurant demos without manual troubleshooting.
Original PR description
A ParseError is raised when the system attempts to assign a product category to the `sushi_drink_combo` product, in cases where food product category have have been manually removed before loading…
A ParseError is raised when the system attempts to assign a product category to the `sushi_drink_combo` product, in cases where food product category have have been manually removed before loading the demo data. - new demo data has been added : odoo/odoo@94734feba5670b23acf73a2ad485efe3d480efc0 - `raise_if_not_found` conditions has been added for all demo data : odoo/odoo@e6430737bdcea0162e4a3d5ee82e9ab6caa697e9 Steps to reproduce: 1. Install the `point_of_sale` module without demo data. 2. Navigate to Inventory -> Configuration -> Categories. 3. Delete food category. 4. Navigate to Point of Sale → Load Restaurant Sample Data. 5. An error is triggered during the process. Error: ```python odoo.tools.convert.ParseError: while parsing /home/odoo/odoo/codebase/odoo/saas-18.3/addons/pos_restaurant/data/scenarios/restaurant_demo_data.xml:605, somewhere inside ``` This issue occurs because `sushi_drink_combo` also references a missing product category. As with previous products, this change ensures a fallback to prevent failure when no categories exist. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213345
The website builder now treats unset social media links as empty values rather than missing entries. This ensures all expected social media options remain available when editing a social media snippet, especially on databases without demo data or preconfigured links.
Original PR description
Steps to reproduce: - On a database without demo data (and no social links set) - Open website builder - Click on a social media snippet (by default there is one in footer) - Bug: social media not in the snippet are not present in the option The bug was introduced when changing the handling of empty social media records to fix a crash: d4621f81698cdbf3e6a1d72349b3e5f135e0ee53
The website builder's Theme > Advanced section now shows the Code Injection and Google Map Custom Key controls as proper buttons. This improves clarity for users configuring advanced website settings and removes some unused internal code.
Original PR description
Before this commit, the buttons "Code Injection" and "Google Map Custom Key" in `ThemeAdvancedOption` were defined with the tag `button` instead of `BuilderButton` and were acting via `t-on-click` instead of using a `BuilderAction`. This commit converts the two elements to `BuilderButton` using `BuilderAction`. In addition, unused references are removed from `ThemeTabPlugin`. **How to reproduce** 1. In the website builder 2. In the "Theme" tab 3. In the "Advanced" section 4. Problem: the two objects on the rows "Code Injection" and "Custom Key" do not look like buttons. task-4367641
The website builder now hides the Header Position option when a sidebar header is selected, since that setting does not affect sidebar layouts. This prevents users from seeing a confusing control that has no visible impact while editing website headers.
Original PR description
> [BVR] select the "sidebar" header. Select "over the content" => no effect .. I think the option should be hidden for "sidebar" (check before mysterious egg). Steps to reproduce: - Open website builder - Click on the header - Change the "Template" to the last one: "Sidebar" - Bug: "Header Position" is still visible This bug was introduced during the initial website builder refactor. Website refactor: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-4367641
This fix updates a web test so it uses a reliable record created during the test setup instead of depending on existing demo data. It reduces false test failures and helps keep quality checks stable for future releases.
Original PR description
Before this commit, the test TestLoadBreadcrumbs was failing with demo data. After this commit, the test uses a record created during the setUpClass, thus resolving the issue introduced in #212950 .
A daily automated check now keeps each employee linked to their correct current HR version. This helps ensure employee records stay accurate over time without requiring manual updates.
Original PR description
This adds a cron that will update the current_version_id of all employees every day. Task: 4886048
This update fixes an internal validation issue in the HTML builder that could allow duplicate action identifiers when actions are defined in newer formats. It helps keep website editing behavior consistent and reduces the risk of unexpected builder conflicts.
Original PR description
With the changes of b4b215325db61fbbe9793545293c8b6fbc99f310, some actions are declared as classes with their id as a static field instead of an object for which th id is the key in the resource `builder_actions`. The check for unique action id has not been adapted and only checked if the key is not the id of another action. But for classes the key is not the id, which could lead to duplicates. It also introduced an inconsistency between the actions declared with objects and classes: the id field was added to the object, but not the other. As this field is not used, this commit removes it for both. task-4367641
This fixes which Helpdesk ticket form is opened from timesheet-related views so users see the appropriate ticket layout for their team restrictions. It helps prevent navigation to the wrong form and keeps the Helpdesk timesheet workflow consistent.
Original PR description
- Replaced `form_view_ref` from `helpdesk_timesheet.helpdesk_ticket_view_form_inherit_helpdesk_timesheet` to `helpdesk_timesheet.helpdesk_ticket_view_form_inherit_helpdesk_timesheet_restrict_teams`. - Add primary mode
A new automated check confirms that website rentals count both the start and end dates correctly. This helps prevent pricing or availability errors where a two-day rental could be calculated incorrectly.
Original PR description
Adds a tour that ensure date-based rental durations are set correctly, i.e. renting from 2025-01-01 to 2025-01-02 should result in a rental period of 2 days. This should prevent commits like 574e111 (reverted by 5982e11) from introducing faulty logic. Forward-Port-Of: odoo/enterprise#88671 Forward-Port-Of: odoo/enterprise#88264
This update adjusts internal test expectations for the Mail enterprise module after a recent merge caused performance checks to fail. It helps keep automated validation reliable without changing business functionality for users.
Original PR description
Started to fail just after merge, weird. runbot-227060
This fix ensures AI email rendering no longer changes shared settings provided by custom modules. It helps avoid unexpected behavior when the same settings are reused elsewhere, improving reliability for customized deployments.
Original PR description
In custom modules the caller parameters are reused, don't modify them in place as it is a bad practice and copy the dict.
This fix keeps accounting report tests focused on the intended generic tax report, even when US accounting localization is installed. It prevents test failures caused by automatic switching to the US-specific report variant, improving release reliability without changing user-facing behavior.
Original PR description
https://github.com/odoo/odoo/commit/174fda9bde8460df0d819100aed7974321d43a59 added a new US variant for the tax report. When running the tests, some failed, because the active company was then a US one, and calling the generic tax report actually rerouted to that new variant. We now ensure we don't reroute in those tests by using the appropriate option key. runbot-226719
This update prevents errors when Belgian Intrastat VAT report export views are combined with related screens. It removes an empty view definition that could disrupt normal reporting workflows.
Original PR description
In l10n_be_intrastat, we have vat_report_export.xml, which contains an empty arch (because it had to be removed in master). But as this view is inherited by other views, it raises an error, because we're trying to merge a string (the inherits) and a None (the empty arch). We will remove the empty arch in 18.4 (as we did in 18.3), and remove totally the view in master, with an upgrade script. no-task
**Problem:** when the decimal precision of Product Price is higher than the precision of the currency used, the seller is not correctly selected based on their prices **Steps to reproduce:** - Open Settings/Technical/Database Structure/Decimal Accuracy - For Product Price set a decimal accuracy of 3 - Create a new product - In the purchase tab add 3 lines for a vendor the same vendor - First line with a price of 0.025 and a qty of 1 - Second line with a price of 0.022 and a qty of 2 -
Original PR description
**Problem:** when the decimal precision of Product Price is higher than the precision of the currency used, the seller is not correctly selected based on their prices **Steps to reproduce:** - Open…
**Problem:** when the decimal precision of Product Price is higher than the precision of the currency used, the seller is not correctly selected based on their prices **Steps to reproduce:** - Open Settings/Technical/Database Structure/Decimal Accuracy - For Product Price set a decimal accuracy of 3 - Create a new product - In the purchase tab add 3 lines for a vendor the same vendor - First line with a price of 0.025 and a qty of 1 - Second line with a price of 0.022 and a qty of 2 - Third line with a price of 0.020 and a qty of 3 - Create a new request for quotation for this product with this vendor - set a quantity of 3 **Current behavior:** The unit price is 0.022 **Expected behavior:** It should be 0.020 **Cause of the issue:** When sorting the set of product.supplierinfo, rounding should not be applied because the rounding will be the one of the currency and the Product Price could allow more decimal than the currency. If we allow vendors price to be more precise the the currency, the sorting should take into account this precision when choosing a vendor. opw-4823919 Forward-Port-Of: odoo/odoo#213826
Forward-Port-Of: odoo/odoo#213890
Original PR description
Forward-Port-Of: odoo/odoo#213890
This PR changes the sales and purchase taxes for Cyprus when selling/purchasing within the EU. - All sales taxes changed to 0% when selling to country within the EU. - All purchase taxes changed to 19% when buying from country within the EU. However, a second tax repartition line is added at -100% of the tax. The tax is effectively applied and deducted at the same time. - Redundant taxes were removed like zero rate taxes and taxes with reverse charge. task-4488340 Current behavior be
Original PR description
This PR changes the sales and purchase taxes for Cyprus when selling/purchasing within the EU. - All sales taxes changed to 0% when selling to country within the EU. - All purchase taxes changed to…
This PR changes the sales and purchase taxes for Cyprus when selling/purchasing within the EU. - All sales taxes changed to 0% when selling to country within the EU. - All purchase taxes changed to 19% when buying from country within the EU. However, a second tax repartition line is added at -100% of the tax. The tax is effectively applied and deducted at the same time. - Redundant taxes were removed like zero rate taxes and taxes with reverse charge. task-4488340 Current behavior before PR: - When selling to other EU countries, a 19% sales tax is added to goods and services. - When buying with other EU countries, a 0% VAT tax is added to goods and a 19% VAT tax is added to services. Desired behavior after PR is merged: - When selling to other EU countries, a 0% sales tax is added to goods and services. - When buying with other EU countries, a 19% VAT tax is added to goods and services, and a second tax repartition line is added at -100% of the tax effectively making it 0. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216082 Forward-Port-Of: odoo/odoo#211746
Description of the issue/feature this PR addresses: I'm not sure how to reproduce right now. Clue: these modules are installed: - sale_stock_margin - stock_account Other clue: user is going to an mrp.production order and clicking on "Set as done". Some unknown combination of facts under this situation make multiple `sale.order.line` have to recompute their `purchase_price`. It happens that some product involved is measured in Units, while some other is measured in Kg. At the end of
Original PR description
Description of the issue/feature this PR addresses: I'm not sure how to reproduce right now. Clue: these modules are installed: - sale_stock_margin - stock_account Other clue: user is going to an…
Description of the issue/feature this PR addresses:
I'm not sure how to reproduce right now. Clue: these modules are installed:
- sale_stock_margin
- stock_account
Other clue: user is going to an mrp.production order and clicking on "Set as done".
Some unknown combination of facts under this situation make multiple `sale.order.line` have to recompute their `purchase_price`. It happens that some product involved is measured in Units, while some other is measured in Kg.
At the end of the rabbit hole, the code ends up here, where there's a pretty obvious bug: a singleton value being extracted from a multi-record variable.
So, yes, this is probably the worse fix description ever. 😅 However, the bug is so obvious that I'm not sure I really need something more elaborate in this case. So, here's the fix! 🎁
@moduon MT-7556
Current behavior before PR:
<details>
```
Traceback (most recent call last):
File "/opt/odoo/auto/addons/etl/controllers/[dataset.py](https://dataset.py/)", line 15, in _call_kw
raise ValueError
ValueError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/[models.py](https://models.py/)", line 5182, in ensure_one
_id, = self._ids
ValueError: too many values to unpack (expected 1)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/[http.py](https://http.py/)", line 1651, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "/opt/odoo/custom/src/odoo/odoo/service/[model.py](https://model.py/)", line 133, in retrying
result = func()
File "/opt/odoo/custom/src/odoo/odoo/[http.py](https://http.py/)", line 1678, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/opt/odoo/custom/src/odoo/odoo/[http.py](https://http.py/)", line 1882, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/opt/odoo/custom/src/odoo/odoo/addons/base/models/[ir_http.py](https://ir_http.py/)", line 154, in _dispatch
result = endpoint(**request.params)
File "/opt/odoo/custom/src/odoo/odoo/[http.py](https://http.py/)", line 734, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/opt/odoo/auto/addons/web/controllers/[dataset.py](https://dataset.py/)", line 46, in call_button
action = self._call_kw(model, method, args, kwargs)
File "/opt/odoo/auto/addons/etl/controllers/[dataset.py](https://dataset.py/)", line 19, in _call_kw
return super()._call_kw(model, method, args, kwargs)
File "/opt/odoo/auto/addons/web/controllers/[dataset.py](https://dataset.py/)", line 33, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "/opt/odoo/custom/src/odoo/odoo/[api.py](https://api.py/)", line 469, in call_kw
model.env.flush_all()
File "/opt/odoo/custom/src/odoo/odoo/[api.py](https://api.py/)", line 745, in flush_all
self._recompute_all()
File "/opt/odoo/custom/src/odoo/odoo/[api.py](https://api.py/)", line 741, in _recompute_all
self[field.model_name]._recompute_field(field)
File "/opt/odoo/custom/src/odoo/odoo/[models.py](https://models.py/)", line 6282, in _recompute_field
field.recompute(records)
File "/opt/odoo/custom/src/odoo/odoo/[fields.py](https://fields.py/)", line 1370, in recompute
apply_except_missing(self.compute_value, recs)
File "/opt/odoo/custom/src/odoo/odoo/[fields.py](https://fields.py/)", line 1343, in apply_except_missing
func(records)
File "/opt/odoo/custom/src/odoo/odoo/[fields.py](https://fields.py/)", line 1392, in compute_value
records._compute_field_value(self)
File "/opt/odoo/custom/src/odoo/odoo/[models.py](https://models.py/)", line 4240, in _compute_field_value
fields.determine(field.compute, self)
File "/opt/odoo/custom/src/odoo/odoo/[fields.py](https://fields.py/)", line 98, in determine
return needle(*args)
File "/opt/odoo/auto/addons/sale_stock_margin/models/[sale_order_line.py](https://sale_order_line.py/)", line 18, in _compute_purchase_price
purch_price = product._compute_average_price(0, line.product_uom_qty, line.move_ids)
File "/opt/odoo/auto/addons/mrp_account/models/[product.py](https://product.py/)", line 54, in _compute_average_price
return super()._compute_average_price(qty_invoiced, qty_to_invoice, stock_moves, is_returned=is_returned)
File "/opt/odoo/auto/addons/stock_account/models/[product.py](https://product.py/)", line 788, in _compute_average_price
qty_valued, valuation = candidates._consume_specific_qty(qty_invoiced, qty_to_invoice)
File "/opt/odoo/auto/addons/stock_account/models/[stock_valuation_layer.py](https://stock_valuation_layer.py/)", line 113, in _consume_specific_qty
rounding = self.product_id.uom_id.rounding
File "/opt/odoo/custom/src/odoo/odoo/[fields.py](https://fields.py/)", line 1154, in __get__
record.ensure_one()
File "/opt/odoo/custom/src/odoo/odoo/[models.py](https://models.py/)", line 5185, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: uom.uom(1, 12)
```
</details>
Desired behavior after PR is merged: Fixed!
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#183402The `s_numbers_charts` snippet had two main issues: - The progress bar within `s_numbers_charts` visually appeared as 45% on initial rendering, despite its actual configured value being 25%. This was due to a mismatch between its `aria-valuenow` attribute and its style `width` property. The display would correct itself when the user manually changed the value. - A crash would occur when attempting to select the "Label" option after dropping the `s_numbers_charts` snippet. This happe
Original PR description
The `s_numbers_charts` snippet had two main issues: - The progress bar within `s_numbers_charts` visually appeared as 45% on initial rendering, despite its actual configured value being 25%. This was…
The `s_numbers_charts` snippet had two main issues: - The progress bar within `s_numbers_charts` visually appeared as 45% on initial rendering, despite its actual configured value being 25%. This was due to a mismatch between its `aria-valuenow` attribute and its style `width` property. The display would correct itself when the user manually changed the value. - A crash would occur when attempting to select the "Label" option after dropping the `s_numbers_charts` snippet. This happened because `s_progress_bar_text` was forgotten during the initial implementation of `s_numbers_charts` [1]. This commit addresses these problems by: - Adding the missing `s_progress_bar_text` to the `s_numbers_charts` template. - Including `s_progress_bar_text` in `_computeSnippetTemplates` to ensure that existing databases also receive this fix, as snippets are stored in the database. - Adding a check in the `progress` option to prevent the aforementioned crash. Steps to reproduce the crash: - Drop the `s_numbers_charts` snippet. - Click on a progress bar within the snippet. - Select the option `Label`. - Hover over "Hide" without any other prior interactions. - A crash will occur. [1]: https://github.com/odoo/odoo/commit/6c94fd66c1db75d74588ce670fb6cf1e960cf8bd Forward-Port-Of: odoo/odoo#215946 Forward-Port-Of: odoo/odoo#214318
Before this commit, The ControlPanel was displayed even when there were no breadcrumbs, unnecessarily occupying space. This commit adds a condition to display the ControlPanel only when breadcrumbs are present. task-[4690325](https://www.odoo.com/odoo/project/1519/tasks/4690325) Forward-Port-Of: odoo/odoo#205852
Original PR description
Before this commit, The ControlPanel was displayed even when there were no breadcrumbs, unnecessarily occupying space. This commit adds a condition to display the ControlPanel only when breadcrumbs are present. task-[4690325](https://www.odoo.com/odoo/project/1519/tasks/4690325) Forward-Port-Of: odoo/odoo#205852
Steps to reproduce: - Create a product - Add two purchase supplier info to that product - The first one has date_start < today and date_end < today (or fail on the other side) - The second one has date_start < today and date_end > today - The first supplier info should have min_qty < the second one - Add two different vendor product code on the two supplier infos - Make sure that the two supplier infos are of the same partner_id - Create a purchase order on that product with the partner_
Original PR description
Steps to reproduce: - Create a product - Add two purchase supplier info to that product - The first one has date_start < today and date_end < today (or fail on the other side) - The second one has…
Steps to reproduce: - Create a product - Add two purchase supplier info to that product - The first one has date_start < today and date_end < today (or fail on the other side) - The second one has date_start < today and date_end > today - The first supplier info should have min_qty < the second one - Add two different vendor product code on the two supplier infos - Make sure that the two supplier infos are of the same partner_id - Create a purchase order on that product with the partner_id set The POL has the qty set to the min_qty of the invalid supplierInfo and the vendor code of that supplier info is not displayed. And if you further remove the invalid supplier info from the product page, the vendor code will be read and the POL qty will be the min_qty of the valid supplier info. This is because on creating a POL, two functions are got called, the first one is `_suggest_quantity` which suggests the initial quantity to set on the POL when the PO is created. This one is based on the minimum min_qty of all the supplierInfos related to the same product we are purchasing regardless if they are completely valid or not. Hence it chose the invalid supplierInfo min_qty. https://github.com/odoo/odoo/blob/a05e39c61aaf8eb639a279229b1f803aeb6744c1/addons/purchase/models/purchase.py#L1386C9-L1388C45 After the qty of the POL is set based on the `_suggest_quantity`, the `_compute_price_unit_and_date_planned_and_name` is called because it depends on the product_qty which calls the `_select_seller` function on the product. The `_select_seller` filters all the supplierInfo keeping only the valid ones BASED on the qty we are asking (so it eliminated the one with the smallest min_qty because the date_end is < PO.date and also the second one because the min_qty of the second_supplierInfo is > qty we are asking) ending up with empty list of supplierInfo to apply on our POL. Then the POL is set to the standard price and no vendor code is attached and read into it. https://github.com/odoo/odoo/blob/a05e39c61aaf8eb639a279229b1f803aeb6744c1/addons/product/models/product_product.py#L616-L617 https://github.com/odoo/odoo/blob/a05e39c61aaf8eb639a279229b1f803aeb6744c1/addons/product/models/product_product.py#L603-L612 opw-4640937 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#216126 Forward-Port-Of: odoo/odoo#205915
Current behavior before commit: The issue occurs when the product is a kit. The Procurement: run scheduler scheduled action updates some fields, triggering the _compute_purchase_price method. Within _compute_purchase_price, the method _compute_average_price is called with the company context of the sales order line (SOL). Company Context https://github.com/odoo/odoo/blob/a823c4ef6962672fe68726682e94ff82db211772/addons/sale_stock_margin/models/sale_order_line.py#L14 Method Call https://g
Original PR description
Current behavior before commit: The issue occurs when the product is a kit. The Procurement: run scheduler scheduled action updates some fields, triggering the _compute_purchase_price method. Within…
Current behavior before commit: The issue occurs when the product is a kit. The Procurement: run scheduler scheduled action updates some fields, triggering the _compute_purchase_price method. Within _compute_purchase_price, the method _compute_average_price is called with the company context of the sales order line (SOL). Company Context https://github.com/odoo/odoo/blob/a823c4ef6962672fe68726682e94ff82db211772/addons/sale_stock_margin/models/sale_order_line.py#L14 Method Call https://github.com/odoo/odoo/blob/a823c4ef6962672fe68726682e94ff82db211772/addons/sale_stock_margin/models/sale_order_line.py#L18 During recursion in `_compute_average_price`, the company context incorrectly reverts to the global company instead of preserving the original company context from the initial call. Recursive call https://github.com/odoo/odoo/blob/a823c4ef6962672fe68726682e94ff82db211772/addons/mrp_account/models/product.py#L77 Since the product is a kit, its cost is derived from its components. However, due to the incorrect company context switch, the purchase price is incorrectly set to 0 (because the product does not exist in the global company). This distorts sales margins in ongoing sales orders. Root Cause: The stock_moves passed into the method have env.company set to Company 1. At https://github.com/odoo/odoo/blob/a823c4ef6962672fe68726682e94ff82db211772/addons/mrp_account/models/product.py#L66 bom_lines are extracted, inheriting the environment from stock_moves. As a result, _compute_average_price is executed within the context of Company 1, which may lead to incorrect computations when the intended company context is different. Fix: Ensure that stock_moves is explicitly passed into the method with the correct company context. This guarantees that the company context remains consistent throughout the execution, preventing unintended company switching. opw-4222976 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#216326 Forward-Port-Of: odoo/odoo#192890
take default_employee_id from the employee_id not from active_id task-4885649 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215177
Original PR description
take default_employee_id from the employee_id not from active_id task-4885649 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215177
**Problem:** When settling an order that has been paid with a customer account or that has an amount due for that customer, the loyalty points will be awarded again depending on the amount paid. This means that the customer will receive the points in full when making the order, and one more time when settling said order. **Steps to reproduce:** - Make a purchase with Customer Account as payment method - The points are awarded in full - Go to the customer tab and click settle due accounts
Original PR description
**Problem:** When settling an order that has been paid with a customer account or that has an amount due for that customer, the loyalty points will be awarded again depending on the amount paid. This means that the customer will receive the points in full when making the order, and one more time when settling said order. **Steps to reproduce:** - Make a purchase with Customer Account as payment method - The points are awarded in full - Go to the customer tab and click settle due accounts - Select your order and pay for it - The points are awarded once again depending on how much was left to pay **Why the fix:** The points should just be awarded once when the order is confirmed, even if it has not been paid for yet. We now ignore the line if it's about a settled order, as those points have already been awarded. opw-4770142 Forward-Port-Of: odoo/odoo#215690 Forward-Port-Of: odoo/odoo#214137
Steps to reproduce the bug: - Create two purchase orders and add a note - Try to merge them Problem: A traceback is triggered: ``` ValueError: AttributeError("'int' object has no attribute 'total_seconds'") while evaluating 'if records:\n action = records.action_merge()' ``` opw-4890120 Forward-Port-Of: odoo/odoo#216080 Forward-Port-Of: odoo/odoo#215958
Original PR description
Steps to reproduce the bug:
- Create two purchase orders and add a note
- Try to merge them
Problem:
A traceback is triggered:
```
ValueError: AttributeError("'int' object has no attribute
'total_seconds'") while evaluating 'if records:\n
action = records.action_merge()'
```
opw-4890120
Forward-Port-Of: odoo/odoo#216080
Forward-Port-Of: odoo/odoo#215958Have a cron action written like the following: def cron_complex(...): # prepare items_to_do = collections.deque(...) while self._commit_progress(remaining=len(items_to_do)): item_to_do = items_to_do.pop() try: process(item_to_do) self._commit_progress(1) except: pass This case is similar to what ir.autovacuum is doing: it doesn't always mark an item done, but instead de
Original PR description
Have a cron action written like the following: def cron_complex(...): # prepare items_to_do = collections.deque(...) while self._commit_progress(remaining=len(items_to_do)): item_to_do =…
Have a cron action written like the following:
def cron_complex(...):
# prepare
items_to_do = collections.deque(...)
while self._commit_progress(remaining=len(items_to_do)):
item_to_do = items_to_do.pop()
try:
process(item_to_do)
self._commit_progress(1)
except:
pass
This case is similar to what ir.autovacuum is doing: it doesn't always
mark an item done, but instead decrease the remaining counter.
The problem with this code is the `while` conditional.
The first call to `_commit_progress` is gonna be `done=0`. In case the
function `return 0` (no remaining time) then the `while` is gonna break
and the function will return immediately. The ir.cron would then be in
the condition `not progress.done` which for this case should be
understood as PARTIALLY DONE (there are remaining items to process) but
instead is understood as FULLY DONE.
This scenario is the direct consequence of commit https://github.com/odoo-dev/odoo/commit/f135c06cfde62256348f5e0791a49fa019d1f15c: always run
at least 10 seconds AND at least 10 times. The action runs for 10
seconds the first time, but is called a second time in which it returns
immediately, with progress done=0, remaining>0.
Forward-Port-Of: odoo/odoo#215918Scenario: - install website_sale - go in settings and enable "extra steps" - go to configure extra steps - get in edit mode and add any visibility condition for the form - save Result: the form is hidden in all conditions, even when it should be shown. Why: In 0750eb6315fe9c2d1f1de36b9b756b5097ed11e0 17.0 redesign of the checkout flow, the structure of extra steps changed so now the root element when editing became the section tag of the form. This means that when we set a visibility on it,
Original PR description
Scenario: - install website_sale - go in settings and enable "extra steps" - go to configure extra steps - get in edit mode and add any visibility condition for the form - save Result: the form is hidden in all conditions, even when it should be shown. Why: In 0750eb6315fe9c2d1f1de36b9b756b5097ed11e0 17.0 redesign of the checkout flow, the structure of extra steps changed so now the root element when editing became the section tag of the form. This means that when we set a visibility on it, the form will be hidden by default then shown based on attributes such as data-visibility-selectors. But on the root tag, we only allow to modify only a very restricted list of tags, so we saved the hiding of the form, but didn't save the attributes that made it visibile based on a condition. Fix: add the attributes used for visibility in the authorized list on the root tag. opw-4765026 Forward-Port-Of: odoo/odoo#215479
### Rationale for omitting `nbsp` in code blocks: - Code blocks, usually rendered within `<pre>` tags, inherently preserve whitespace & indentation through browser’s white-space: pre CSS behavior. Thus, inserting `nbsp` to maintain space visibility is redundant & may introduce hidden characters. ### Description of the issue/feature this PR addresses: - Indentation pasted as plain text inside code blocks was replaced by `nbsp`. ### Desired behavior after PR is merged: - Pasting pla
Original PR description
### Rationale for omitting `nbsp` in code blocks: - Code blocks, usually rendered within `<pre>` tags, inherently preserve whitespace & indentation through browser’s white-space: pre CSS behavior. Thus, inserting `nbsp` to maintain space visibility is redundant & may introduce hidden characters. ### Description of the issue/feature this PR addresses: - Indentation pasted as plain text inside code blocks was replaced by `nbsp`. ### Desired behavior after PR is merged: - Pasting plain text inside code blocks preserves indentation using normal spaces, avoiding insertion of `nbsp`. task-4815939 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215252 Forward-Port-Of: odoo/odoo#211386
Problem: When content containing HTML comments is added to the editor, a traceback occur when deleting the commente element. Solution: Remove HTML comments from the content when it's inserted into the editor. These comments are added by `convert_inline` and will be re-applied on save if needed. Steps to reproduce: - Create a new email template - Add an image - Save - Delete the image using backspace - Traceback occurs opw-4863747 --- I confirm I have signed the CLA and read t
Original PR description
Problem: When content containing HTML comments is added to the editor, a traceback occur when deleting the commente element. Solution: Remove HTML comments from the content when it's inserted into the editor. These comments are added by `convert_inline` and will be re-applied on save if needed. Steps to reproduce: - Create a new email template - Add an image - Save - Delete the image using backspace - Traceback occurs opw-4863747 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213807
Followup to https://github.com/odoo/odoo/commit/fdcb584b20af1f99cf760eaff94e489a77e6c36d When the `_onClickUpdateQuantity` was updated to use a view instead of a wizard that opens in a new window, it was not checked that the HTML help when no records found is correctly rendered. This fixes that by ensuring it's correctly parsed, i.e. copied same solution as here: https://github.com/odoo/odoo/commit/f9f7d9d6a8470f3ca5ff464bb425b219ac4ed571 Steps to reproduce: - open any product > click
Original PR description
Followup to https://github.com/odoo/odoo/commit/fdcb584b20af1f99cf760eaff94e489a77e6c36d When the `_onClickUpdateQuantity` was updated to use a view instead of a wizard that opens in a new window, it was not checked that the HTML help when no records found is correctly rendered. This fixes that by ensuring it's correctly parsed, i.e. copied same solution as here: https://github.com/odoo/odoo/commit/f9f7d9d6a8470f3ca5ff464bb425b219ac4ed571 Steps to reproduce: - open any product > click on forecast report button - click on "Update Quantity" - apply a filter so that no records are found (e.g. only "Transit Locations" Expected result: normal no records found icon + help Actual result: raw html Additionally cleaned up some of the junk code that was left by the original commit.... --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208896
To reproduce: ============= - install documents_project - create project - go to documents and get share link of the project's folder with permission to upload (anyone with the link can upload) - open the share link in a new browser window and connect as portal user - upload a document -> access error Problem: ======== while uploading a document, we will need to read `partner_id` from the linked project, but the portal user does not have access to the project Solution: ======== r
Original PR description
To reproduce: ============= - install documents_project - create project - go to documents and get share link of the project's folder with permission to upload (anyone with the link can upload) - open the share link in a new browser window and connect as portal user - upload a document -> access error Problem: ======== while uploading a document, we will need to read `partner_id` from the linked project, but the portal user does not have access to the project Solution: ======== read as `sudo` opw-4782062 Forward-Port-Of: odoo/enterprise#87919 Forward-Port-Of: odoo/enterprise#87301
Odoo’s current behaviour - When a Lead is converted into a Ticket, the resulting Ticket contains a reference to the Lead in its chatter. However, the original Lead does not display any reference or information about the created Ticket. - This behaviour differs from how Odoo handles conversions between Tickets and Tasks, where both records include reciprocal chatter messages indicating the link between them. Expected behaviour after PR is merged When a Lead is converted into a Ticket: - The
Original PR description
Odoo’s current behaviour - When a Lead is converted into a Ticket, the resulting Ticket contains a reference to the Lead in its chatter. However, the original Lead does not display any reference or information about the created Ticket. - This behaviour differs from how Odoo handles conversions between Tickets and Tasks, where both records include reciprocal chatter messages indicating the link between them. Expected behaviour after PR is merged When a Lead is converted into a Ticket: - The Ticket should continue to include a reference to the originating Lead (existing behaviour). - The Lead should also display a chatter message referencing the newly created Ticket. Forward-Port-Of: odoo/enterprise#87463
Show the Do Not Disturb state text on the voip header Task-4891947 Forward-Port-Of: odoo/enterprise#88362
Original PR description
Show the Do Not Disturb state text on the voip header Task-4891947 Forward-Port-Of: odoo/enterprise#88362
Steps to reproduce: - Create a company (for example a Belgian one) and set the vat - Create a child company with same country, but different vat - set the account opening date for both companies - open the tax returns page with the child company -> the child company should have VAT returns associated, because it's the main company for the vat branch, but it doesn't contain anything Forward-Port-Of: odoo/enterprise#88061
Original PR description
Steps to reproduce: - Create a company (for example a Belgian one) and set the vat - Create a child company with same country, but different vat - set the account opening date for both companies - open the tax returns page with the child company -> the child company should have VAT returns associated, because it's the main company for the vat branch, but it doesn't contain anything Forward-Port-Of: odoo/enterprise#88061
After this commit https://github.com/odoo/enterprise/pull/74528/commits/c0af404c2b3e08ec92243f4c070f915833b4a538 some tests are failing when we don't have timesheet_grid module installed as the allocated hours will get recomputed so the behavior will be different. To fix this we moved all of the tests that test allocated hours value to timesheet_grid and adapted another test to check whether we have the timesheet_grid module installed or not and upon this check we change the value that we are
Original PR description
After this commit https://github.com/odoo/enterprise/pull/74528/commits/c0af404c2b3e08ec92243f4c070f915833b4a538 some tests are failing when we don't have timesheet_grid module installed as the allocated hours will get recomputed so the behavior will be different. To fix this we moved all of the tests that test allocated hours value to timesheet_grid and adapted another test to check whether we have the timesheet_grid module installed or not and upon this check we change the value that we are checking. runbot-115003 Forward-Port-Of: odoo/enterprise#88316 Forward-Port-Of: odoo/enterprise#81643
Currently, once a fsm task report has been sent once, the "Send report" buttons are disabled in the form view. However, the contextual server action is always available, but a check in `action_send_report` prevents the report from being sent if the buttons are disabled. This commits allows re-sending the report, which can be useful if some changes have been made after the report was first sent. opw-4818953 Forward-Port-Of: odoo/enterprise#88579 Forward-Port-Of: odoo/enterprise#87104
Original PR description
Currently, once a fsm task report has been sent once, the "Send report" buttons are disabled in the form view. However, the contextual server action is always available, but a check in `action_send_report` prevents the report from being sent if the buttons are disabled. This commits allows re-sending the report, which can be useful if some changes have been made after the report was first sent. opw-4818953 Forward-Port-Of: odoo/enterprise#88579 Forward-Port-Of: odoo/enterprise#87104
Change: Skip access rights of `hr.contract` when refusing an applicant. Reasoning: If you have the right to refuse an applicant, you should be able to refuse an applicant and retrospectively, **sudo** refuse the associated offer(s). Task-4868368 Forward-Port-Of: odoo/enterprise#87730
Original PR description
Change: Skip access rights of `hr.contract` when refusing an applicant. Reasoning: If you have the right to refuse an applicant, you should be able to refuse an applicant and retrospectively, **sudo** refuse the associated offer(s). Task-4868368 Forward-Port-Of: odoo/enterprise#87730
Steps to reproduce: - Set language to RTL Orientation - Go to Accounting > Reporting > Aged Payable - Add multiple columns to report - Print as PDF Issue: When enough columns have been added to the report, the report will overflow the right side of the page Cause: Wkhtmltopdf does not correctly shrink the table if the direction is specified on the body of the document opw-4746361 Forward-Port-Of: odoo/enterprise#87520
Original PR description
Steps to reproduce: - Set language to RTL Orientation - Go to Accounting > Reporting > Aged Payable - Add multiple columns to report - Print as PDF Issue: When enough columns have been added to the report, the report will overflow the right side of the page Cause: Wkhtmltopdf does not correctly shrink the table if the direction is specified on the body of the document opw-4746361 Forward-Port-Of: odoo/enterprise#87520
The aim of this commit is replacing all the tabulations in the file while reading it for spaces as the csv reader is using spaces as delimiter. This commit also introduces a new user error which indicates the user that the #ADRESS line is malformed. opw-4868415 Forward-Port-Of: odoo/enterprise#88259
Original PR description
The aim of this commit is replacing all the tabulations in the file while reading it for spaces as the csv reader is using spaces as delimiter. This commit also introduces a new user error which indicates the user that the #ADRESS line is malformed. opw-4868415 Forward-Port-Of: odoo/enterprise#88259
With an MX Company setup: - Have a product with MX info correctly setup for external trade - Create an invoice - Set the external trade to definitive - Add the product on the invoice line and set "Qty UMT" to 0 Try to send and you will get a traceback opw-4807271 Forward-Port-Of: odoo/enterprise#87083 Forward-Port-Of: odoo/enterprise#86118
Original PR description
With an MX Company setup: - Have a product with MX info correctly setup for external trade - Create an invoice - Set the external trade to definitive - Add the product on the invoice line and set "Qty UMT" to 0 Try to send and you will get a traceback opw-4807271 Forward-Port-Of: odoo/enterprise#87083 Forward-Port-Of: odoo/enterprise#86118
Before, aml.ref had to be at least 5char length to be a full match candidate. But it seems 5 is not enough and leads to unwanted matches, so let's increase the limit to 7. no-task Forward-Port-Of: odoo/enterprise#88554
Original PR description
Before, aml.ref had to be at least 5char length to be a full match candidate. But it seems 5 is not enough and leads to unwanted matches, so let's increase the limit to 7. no-task Forward-Port-Of: odoo/enterprise#88554
Reproduce: 1. Create a new folder 2. Set a specific internal user as editor member on it 3. Archive that user 4. Try creating a spreadsheet in that folder -> ValidationError The check wrongly considered archived internal users as portal users. Task-4878693 Forward-Port-Of: odoo/enterprise#87940
Original PR description
Reproduce: 1. Create a new folder 2. Set a specific internal user as editor member on it 3. Archive that user 4. Try creating a spreadsheet in that folder -> ValidationError The check wrongly considered archived internal users as portal users. Task-4878693 Forward-Port-Of: odoo/enterprise#87940
Reproduce: 1. Select a document so that its token is now part of the URL 2. Refresh the page 3. The document is not selected as it should This is problematic because if you are given a link to access a document in a folder with any siblings, you have no way to know which one the link pointed to. Technically, since 18.3, records are no longer found in `onMounted`. Note that due to another (older, independent, and less critical) bug, non-previewable records are not focused. Task-4
Original PR description
Reproduce: 1. Select a document so that its token is now part of the URL 2. Refresh the page 3. The document is not selected as it should This is problematic because if you are given a link to access a document in a folder with any siblings, you have no way to know which one the link pointed to. Technically, since 18.3, records are no longer found in `onMounted`. Note that due to another (older, independent, and less critical) bug, non-previewable records are not focused. Task-4873715 Forward-Port-Of: odoo/enterprise#88555
Currently, an error occurs when the system initializes the voip configuration for the currently logged-in internal user. Steps to Reproduce: - Install the `voip` module. - Delete the activity type where the `Action` is `'Phonecall'`, and then refresh the page. `IndexError: tuple index out of range.` This error occurs when the system initializes the voip configuration and no phonecall activity type exists. The system attempts to search for activity types with the 'phonecall' catego
Original PR description
Currently, an error occurs when the system initializes the voip configuration for the currently logged-in internal user. Steps to Reproduce: - Install the `voip` module. - Delete the activity type where the `Action` is `'Phonecall'`, and then refresh the page. `IndexError: tuple index out of range.` This error occurs when the system initializes the voip configuration and no phonecall activity type exists. The system attempts to search for activity types with the 'phonecall' category, which returns an empty recordset. Then it tries to access the first record of this empty recordset[1], which raises an error. [1] https://github.com/odoo/enterprise/blob/2896974e9eda61bfe5e1d67423dc56f6ab17b2af/voip/models/res_users.py#L128 This commit ensures that if activity type with the 'phonecall' category is present, it store the activity type id, otherwise, it stores False as the activity type id. sentry-6689050392 Forward-Port-Of: odoo/enterprise#87958