Friday, March 7, 2025
64 changes · 18.0
Enhancements to existing features
The Live Chat integration instructions have been revamped to make it easier to enable chat on both Odoo-hosted and custom websites. This should help businesses set up customer chat more confidently and reduce confusion during website integration.
Original PR description
Purpose of this Commit: Revamp the integration to enable Live Chat functionality on custom websites and Odoo websites. task-3751548 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now enter an exact font size directly in the editor toolbar instead of choosing only from preset options. This gives content creators more flexibility and keeps text selection stable while applying the chosen size.
Original PR description
### Description of the issue/feature this PR addresses: - The editor only provided a font size dropdown with predefined options, preventing the selection of a custom font size. ### Desired behavior after PR is merged: - A font size input field is added to toolbar using an _`iframe`_, ensuring the selection remains intact in editable area. - Clicking the font size input selects the text and displays the predefined font size dropdown. - The entered value in the font size input is applied to the selected content after a _`200ms`_ debounce. - The font size can also be selected from the dropdown. - Font size dropdown closes on Enter and Tab key press. - ArrowUp/Down moves focus to font size dropdown. task-4488396 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Channel member lists now show a person’s full name when hovering over their entry. This makes it easier for users to identify members whose names may be shortened in the list.
Original PR description
Purpose: to display the full name on hover in channel member list. task-4630148 after PR:  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Repro steps: 1. Create a new company. 2. Attempt to delete the newly created company. 3. The deletion is successful, but if the user tries to login again, they will keep getting this error `Record does not exist or has been deleted.` Cause: The cause was that the cache would have the id of the deleted company, and attempting to access this company was the bug cause. Solution: This commit solves this bug by clearing the cache on company deletion. task-4438207 --- I confirm I
Original PR description
Repro steps: 1. Create a new company. 2. Attempt to delete the newly created company. 3. The deletion is successful, but if the user tries to login again, they will keep getting this error `Record does not exist or has been deleted.` Cause: The cause was that the cache would have the id of the deleted company, and attempting to access this company was the bug cause. Solution: This commit solves this bug by clearing the cache on company deletion. task-4438207 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200711 Forward-Port-Of: odoo/odoo#200164
Short automated portal or website walkthroughs no longer fail when portal chatter is still loading in the background. This prevents irrelevant test crashes and helps keep validation results stable without changing the customer-facing portal experience.
Original PR description
Backport of https://github.com/odoo/odoo/pull/199212 Runbot may be red due to tours ending while portal chatter is lazy-loading. We don't care of lazy-loading of portal chatter that hasn't ended, the…
Backport of https://github.com/odoo/odoo/pull/199212 Runbot may be red due to tours ending while portal chatter is lazy-loading. We don't care of lazy-loading of portal chatter that hasn't ended, the tour passes and that's what matters. ORIGINAL MESSAGE: Before this commit, short portal and website tours that open a page with portal chatter may crash with following error: ``` Error received after termination: AssetsLoadingError: The loading of http://127.0.0.1:8069/web/bundle/portal.assets_chatter_style?lang=en_US&website_id=1 failed ``` This happens because the tour is so short and doesn't assert loading of portal chatter that the tour ends while portal chatter hasn't been loaded. The tour termination forces abort of ongoing lazy-loading such as portal chatter, which results in the crash above. This commit fixes the issue by silently catching the error in this very specific case that lazy-loading has been aborted by browser page reload or closing, which is precisely the case with tour. The crash is not relevant in that case, in practice the crash is intended to detect programming errors. runbot-114302
This fixes the mobile call screen so the full call interface, including participant visibility, fits properly on smaller displays. Users joining calls from mobile devices should have a clearer, more usable experience without hidden or cramped controls.
Original PR description
Before this commit, since https://github.com/odoo/odoo/pull/175858, the call view in mobile was too small to fit all of the call UI, this commit fixes this issue. | Before | After | |--------|--------| |  |  |
This fix ensures that intercompany replenishment creates the purchase order in the company that owns the buying rule, rather than the company requesting the stock. It prevents purchase orders from being created in the wrong company or failing because the expected vendor is only configured in the supplying company.
Original PR description
### Issue: Currently, running a procurment to fulfill a demand in COMP1 linked to a buy rule of COMP2 toaward the inter-company transit will use seller's set in COMP1 and generate a PO in COMP1…
### Issue: Currently, running a procurment to fulfill a demand in COMP1 linked to a buy rule of COMP2 toaward the inter-company transit will use seller's set in COMP1 and generate a PO in COMP1 rather than COMP2. ### Steps to reproduce: - In the settings enable Multi-steps routes - Have two companies: COMP1 and COMP2 - Create a routes without set companies with 3 rules: - rule 1 (comp1): - Pull from Virtual Locations/Inter-company transit to WH1/Stock supply method: Trigger an other rule. - rule 2 (comp2): - Pull from WH2/Stock to Virtual Locations/Inter-company transit, supply method: Trigger an other rule. - rule 3 (comp2): - Buy from Partner/vendors to WH2/Stock using a custom operation type towards Virtual Locations/Inter-company transit. - Create a storable product with both routes set. - With COMP2: set a vendor on that product. - In COMP1, your product > Reordering rules create a new rule using the COMP1 route to replenish WH1/Stock. - With both COMP1 and COMP2 as active order once. > The PO could not find a vendor as it looked for suppliers in COMP1 and if such a supplier was set in COMP1, the PO would be created in COMP1. ### Cause of the issue: While the rule of COMP2 is found and used to run the procurment here: https://github.com/odoo/odoo/blob/2cd3d6a76db6bedba8bbb3233690b0cd72f87876/addons/stock/models/stock_rule.py#L484 the procurement was created and is linked to the company owning the move creating the demand (that is COMP1): https://github.com/odoo/odoo/blob/2cd3d6a76db6bedba8bbb3233690b0cd72f87876/addons/stock/models/stock_move.py#L1494-L1498 However, the `company_id` used in the `_run_buy` notably for the data's of the PO will be the company linked to the procurement rather than the company linked to the buy rule. Since the buy rule should generate a purchase order in company it uses, this is incorrect. opw-4578965 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes how eCommerce handles free combo products and combo items when zero-price sales are blocked. Businesses can now enforce the zero-price restriction on the overall combo product while still allowing free items inside a paid combo, preventing checkout issues and unintended free sales.
Original PR description
Previously: - Zero-priced combo products could always be sold on eCommerce. However, this shouldn't be allowed if `prevent_zero_price_sale` is enabled. - Zero-priced combo items couldn't be sold on eCommerce if `prevent_zero_price_sale` was enabled. However, this should always be allowed since only the price of the combo product matters (not its items).
Odoo now automatically includes the supporting property-definition field needed by property fields when preparing views. This prevents users from hitting an error in Studio or forms when access rules hide a related field, improving reliability without changing the visible workflow.
Original PR description
Steps to reproduce
==================
- Install repair,web_studio
- Go to repair
- Open any record
- Open studio
- Switch to the misceallaneous tab
- Click on the Operation Type field
- Add the "Technical / Receive notifications in Odoo" group in "Allow visibility to groups"
```
TypeError: Cannot read properties of undefined (reading '0')
at PropertiesField._getSeparatorFoldKey
```
Cause of the issue
==================
Since the user doesn't have that group, the field `picking_type_id` will no be available.
```py
repair_properties = fields.Properties(
'Properties',
definition='picking_type_id.repair_properties_definition'
)
```
That field is needed as it's the definition field for the repair_properties field.
Solution
========
When postprocessing views, we already add some fields that are needed by others. We can do the same for properties fields.
opw-4594796This fix prevents Czech bank reconciliation from incorrectly replacing a manually chosen bank transaction date with today’s date. It keeps taxable supply date rules for Czech accounting where appropriate while avoiding wrong dates on bank transactions.
Original PR description
- Install l10n_cz and switch to a cz company. - In bank reconciliation, create a new bank transaction and set its date to a past or future date (not today) The date of the newly created bank transaction is automatically set to today. In the Czech Republic, it is required to use the taxable supply date as the accounting date. This functionality was introduced by 184c1e65a9992e890af81bb60eeeb7b8b825ab54. However, it also sets the taxable supply date for bank transactions, which is incorrect. opw-4544305 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Point of Sale product card now rounds displayed quantities to two decimal places, preventing confusing values like 4.199999999999999. This makes weighted product totals clearer and more trustworthy for cashiers during checkout.
Original PR description
Steps to reproduce: - install pos - create a product with weigh on scale - open pos session and add it twice, once in 1.9 and once in 2.3 - you will find the number on the card number as 4.1999999999999999 Problem: issue in the precision of decimal additions in javascript, so added a rounding to max 2 decimal places opw-4529408 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 stock dashboard now handles records that do not have a date category instead of failing during display or upgrade checks. This prevents an error in the inventory kanban dashboard and shows a blank value rather than the word "none" when no date is available.
Original PR description
date_category can be None, we should check before adding values to the dict. And also return empty string instead "none" in _compute_kanban_dashboard_graph error from upgrade mock viewer. ``` File…
date_category can be None, we should check before adding values to the dict.
And also return empty string instead "none" in _compute_kanban_dashboard_graph
error from upgrade mock viewer.
```
File "/tmp/tmpd7nbq20v/migrations/base/tests/test_mock_crawl.py", line 256, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpd7nbq20v/migrations/base/tests/test_mock_crawl.py", line 269, in mock_action
return self.mock_act_window(action)
File "/tmp/tmpd7nbq20v/migrations/base/tests/test_mock_crawl.py", line 429, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpd7nbq20v/migrations/base/tests/test_mock_crawl.py", line 531, in mock_view_kanban
self.mock_web_search_read(model, view, [domain], fields_list)
File "/tmp/tmpd7nbq20v/migrations/base/tests/test_mock_crawl.py", line 590, in mock_web_search_read
data = model.search_read(domain=domain, fields=fields_list, limit=80)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6074, in search_read
return records._read_format(fnames=fields, **read_kwargs)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4016, in _read_format
vals[name] = convert(record[name], record, use_display_name)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6983, in __getitem__
return self._fields[key].__get__(self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1287, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1469, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5222, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 109, in determine
return needle(*args)
File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_picking.py", line 376, in _compute_kanban_dashboard_graph
summaries[picking_type_id]['total_' + date_category] += 1
KeyError: 'total_none'
```
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-prKiosk orders paid through a payment terminal now appear on the preparation display only after payment is completed. This prevents staff from preparing orders that may not be successfully paid, while still supporting counter payment flows.
Original PR description
to reproduce: ============= - Setup kiosk on POS shop using Stripe or other payment terminal - Open the Preparation display for the shop and start the kiosk - When an order is sent to the terminal on the kiosk, the order appears on the prep display immediately before payment is completed Problem: ======== the issue is introduced when we allowed for he customer to pay on the counter, the order is sent to the preparation display before the payment is completed Solution: ========= add a flag in context to tell if payment should be done in kiosk or on the counter opw-4556029 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures the HTML editor only removes focus outlines from areas that are actually editable. Non-editable content keeps its normal visual outline behavior, helping preserve clarity and expected page editing feedback.
Original PR description
**Problem**: The outline is removed for all elements with `contenteditable`, including those with `contenteditable=false`, which is incorrect. **Solution**: Restrict outline removal to elements with `contenteditable=true` only. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents two devices from recording the same point-of-sale session opening at the same time. It keeps cash opening records and session numbering accurate, improving reliability for stores using multiple devices.
Original PR description
Before this commit, if a session was opened on two devices concurrently, both devices could set the opening control. This resulted in duplicate opening cash setting and a gap in the session ID sequence. This fix ensures that opening control is set only once, maintaining correct session tracking. opw-4627585 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale product search now returns all relevant matching products instead of limiting results to exact matches. This aligns search behavior with the removal of fuzzy search and helps staff find products more reliably during checkout.
Original PR description
Since the fuzzy search has been removed, it is no longer necessary to exclusively display only exact match results. This commit updates the search functionality to adopt and return all relevant search results, ensuring consistency with the new behavior. opw-4535250 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The signup password field now has better spacing so typed text does not overlap with the password strength indicator. This makes account creation clearer and easier for users, with no change to the underlying password rules.
Original PR description
Due to the pasword security meter on the right of the input, the content of the input can overflow behind the security meter. Note: I seized the opportunity to reindent this file according to our coding guidelines task-4630394 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents inventory reservation cleanup from trying to process kit products in a way the system does not support. It helps users avoid blocking errors when opening or updating inventory quantities after a product has been changed into a kit.
Original PR description
Since this commit: https://github.com/odoo/odoo/pull/188201/commits/766ec99dbc2701a237f082f3fb124793d9dfe596 We try to clean reservations because, for some reason, there could be a discrepancy…
Since this commit: https://github.com/odoo/odoo/pull/188201/commits/766ec99dbc2701a237f082f3fb124793d9dfe596 We try to clean reservations because, for some reason, there could be a discrepancy between the sum of “stock.move.line” and the quantity/reserved quantity on “stock.quant”. However, there are cases where a user creates a storable product, updates its quantity, and then uses it in a “stock.move.line”, confirms it, and later changes the product type to a kit. So, when trying to clean the reservations for these “stock.move.line”, a user error occurs because the system attempts to create a quant for a kit-type product: https://github.com/odoo/odoo/blob/c07778bbce4311c142bd8e2ce3013998d4f126ae/addons/mrp/models/stock_quant.py#L6-L11 As a result, each time users try to access the quant list, clean_reservation is triggered, causing a user error that prevents them from modifying the quantity of any quant. Solution: For kits, we can skip cleaning their quant to avoid unnecessary errors. opw-4625002 opw-4624008 opw-4621175 opw-4625465 opw-4621504 opw-4623523 opw-4621508 opw-4623329 opw-4629386
This commit fixed the access error issue that non-admin users would encounter when submitting a Jordanian e-invoice. It adds sudo access rights to the fields l10n_jo_edi_client_identifier and l10n_jo_edi_secret_key while reading them for e-invoice submission. task-4577597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200015
Original PR description
This commit fixed the access error issue that non-admin users would encounter when submitting a Jordanian e-invoice. It adds sudo access rights to the fields l10n_jo_edi_client_identifier and l10n_jo_edi_secret_key while reading them for e-invoice submission. task-4577597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200015
Currently, the date filters do not have their title displayed in the `FilteValue` component which is an issue in dashboards where one could have multiple date filters defined and could not differentiate them. This revision adds the fiter label as a title such that users can identify the right filter given that they gave it an appropriate label. task-4606670 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged:
Original PR description
Currently, the date filters do not have their title displayed in the `FilteValue` component which is an issue in dashboards where one could have multiple date filters defined and could not differentiate them. This revision adds the fiter label as a title such that users can identify the right filter given that they gave it an appropriate label. task-4606670 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#200657 Forward-Port-Of: odoo/odoo#200502
Versions -------- - saas-17.4+ Earlier versions displayed each variant seperately. Steps ----- 1. Have 2 product template attributes A and B; 2. have one of B's attribute values be excluded for one of A's values; 3. have a product template using these values; 4. ensure product template is available in POS; 5. sell product template in POS. Issue ----- The attribute combination that should be excluded isn't displayed as such. Cause ----- When checking for product attribute
Original PR description
Versions -------- - saas-17.4+ Earlier versions displayed each variant seperately. Steps ----- 1. Have 2 product template attributes A and B; 2. have one of B's attribute values be excluded for one of A's values; 3. have a product template using these values; 4. ensure product template is available in POS; 5. sell product template in POS. Issue ----- The attribute combination that should be excluded isn't displayed as such. Cause ----- When checking for product attribute exclusions, it currently only considers attribute combinations of archived products to be unavailable for sale. Solution -------- In the `_get_archived_combinations_per_product_tmpl_id` method, factor in attribute exclusions, and treat them as archived product variants. In master, rename the method & references to it to reflect more general unavailable attribute combinations instead of specifically archived products. opw-4521198 Forward-Port-Of: odoo/odoo#199042
Since the upgrade of Chartjs to v4.3 in [commit 1], stacked charts in website were wrongly computed. This commit fixes it. [commit 1]: https://github.com/odoo/odoo/commit/7e3c1ecdb86110912b15722e600f9571692807ed task-4603349 Forward-Port-Of: odoo/odoo#199186
Original PR description
Since the upgrade of Chartjs to v4.3 in [commit 1], stacked charts in website were wrongly computed. This commit fixes it. [commit 1]: https://github.com/odoo/odoo/commit/7e3c1ecdb86110912b15722e600f9571692807ed task-4603349 Forward-Port-Of: odoo/odoo#199186
#### Description of the issue/feature this PR addresses: When updating an allocation's number_of_days, a validation check is performed to ensure that we do not reduce the `number_of_days` to be less than the number of leaves that are taken by the employee. However this logic also takes into consideration any virtual leaves (leaves that are in the `confirm` or `validate1` state, ie. leaves that are awaiting an approval) that may have been requested by an employee. These virtual leaves that ar
Original PR description
#### Description of the issue/feature this PR addresses: When updating an allocation's number_of_days, a validation check is performed to ensure that we do not reduce the `number_of_days` to be less…
#### Description of the issue/feature this PR addresses: When updating an allocation's number_of_days, a validation check is performed to ensure that we do not reduce the `number_of_days` to be less than the number of leaves that are taken by the employee. However this logic also takes into consideration any virtual leaves (leaves that are in the `confirm` or `validate1` state, ie. leaves that are awaiting an approval) that may have been requested by an employee. These virtual leaves that are not yet approved should not count towards the calculation since it could be possible that the employer could refuse them or the employee's accrual plan could grant sufficient leaves if it is requested for a future date. #### Current behavior before PR: 1. Setup a timeoff type that requires approval from the manager 2. Set up an accrual plan where an employee accrues '_N_' days of leave at the start of each year with **no carryover** (NOTE: the no carryover is the most crucial step because this is what writes the number_of_days on the leave allocation to zero) 3. Request a leave by an employee for any date after the carryover period. What should have happened: The accrual should reset the leaves based on no carryover policy back to _N_ days However, it throws a validation error: Now the issue happens because when we see that the carryover is none because of which: 1. The allocated leaves are set to 0 when calling this CRON (for no carryover): https://github.com/odoo/odoo/blob/cf18c4ac88919513a9f2b922d625fa5dc113cb39/addons/hr_holidays/models/hr_leave_allocation.py#L527 2. The leave that was requested by the employee but not yet approved causes the validation to fail. It is best explained in the below screen recording which uses the test case mentioned in the commit: https://github.com/user-attachments/assets/f8914bac-815d-48c9-b4b2-c132a2fccbdb   #### Desired behavior after PR is merged: Virtual Leaves that are not yet approved would not block us from updating the allocation's `number_of_days` opw-4442471 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200000 Forward-Port-Of: odoo/odoo#198382
This https://github.com/odoo/enterprise/commit/68f6c1f9fd3ff6762c98e1a405ade035129efce0 caused the `test_create_res_partner` test to fail. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200527
Original PR description
This https://github.com/odoo/enterprise/commit/68f6c1f9fd3ff6762c98e1a405ade035129efce0 caused the `test_create_res_partner` test to fail. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200527
### Steps to reproduce: - In Sale create an empty sale order and confirm - In Expense > Configuration > Expense Categories > Mileage set the price per km to be 1 and "Re-Invoice Expenses" to "Sales price" - Create a new expense - Change the category to "Mileage" - Set a quantity >1 - In "Customer to Reinvoice" select the one from the quotation - Click "Create Report" > "Submit to Manager" > "Validate" > "Post Journal Entries" - Return to the sale order - The number under "Delivered" is
Original PR description
### Steps to reproduce: - In Sale create an empty sale order and confirm - In Expense > Configuration > Expense Categories > Mileage set the price per km to be 1 and "Re-Invoice Expenses" to "Sales price" - Create a new expense - Change the category to "Mileage" - Set a quantity >1 - In "Customer to Reinvoice" select the one from the quotation - Click "Create Report" > "Submit to Manager" > "Validate" > "Post Journal Entries" - Return to the sale order - The number under "Delivered" is 1, it should be the same as the quantity ### Cause: When creating the move from the expense, the quantity is not given and defaults to 1. ### Solution: Add the quantity to the `payments_vals`. opw-4389303 Forward-Port-Of: odoo/odoo#200179 Forward-Port-Of: odoo/odoo#192524