Friday, March 7, 2025
32 changes · 18.0
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
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
The HTML editor's automated tests now use the actual default text color instead of assuming a value from the Enterprise edition. This makes test results consistent across Odoo editions and helps prevent false failures during development.
Original PR description
Before this commit, some tests based on the default text color only worked if the tests were run with enterprise because the default text color was hard-coded based on the style of enterprise. 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
Down payment receipts in Point of Sale now display long product names without creating an unwanted horizontal scrollbar. This keeps receipts easier to read and improves the checkout experience for staff and customers.
Original PR description
Before this commit, making a down payment for a sale order with a product that has a long name would cause a horizontal scroll bar to appear in the receipt. Before: <img width="259" alt="image" src="https://github.com/user-attachments/assets/3db17ad0-e1a7-4653-9e50-edd9dd8c4e9e" /> After: <img width="383" alt="image" src="https://github.com/user-attachments/assets/faa0c3ea-c400-4cb6-96ed-2b496236710f" /> opw-4604797 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Point of Sale screen now displays extra charges for combo product choices when staff select a combo item. This helps cashiers and customers see the correct pricing upfront, reducing confusion and checkout errors.
Original PR description
Extra prices are not displayed in the POS when selecting a combo product with defined combo choices. When a combo product is created with combo choices that have extra prices, those extra prices should be visible in the POS interface. Steps to Reproduce: 1. Create a new combo product with multiple combo choices. 2. Set an extra price for one or more of the combo choices. 3. In the POS, select the combo product. 4. Notice that the extra price is not shown. opw-4485134 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes how the editor identifies reusable website content blocks so only the intended main snippet is selected and checked. This prevents confusing empty option panels and false outdated-snippet warnings when using masonry and accordion-style snippets.
Original PR description
In [1], the masonry_block snippet has been exploded into multiple 'sub-snippet'. But this had for consequence that when selecting a block of the snippet one too many option section was appearing…
In [1], the masonry_block snippet has been exploded into multiple 'sub-snippet'. But this had for consequence that when selecting a block of the snippet one too many option section was appearing because of this multiple level snippet. (e.g: s_masonry_block > s_masonry_block_default_template > Block) Yet this middle level has no options on its own. so it was unnecessary to have an options section for the 'sub-snippets'. This commit just prevent to be able to select the 'sub-snippets'. Furthermore, due to those 'sub-snippets' being contained inside the s_masonry_block snippet, they would not get registered in the list of all the snippets, and then the website would failed to determine their version which raised the 'outdated_snippet' alert. Preventing the selection of those 'sub-snippet' thus also prevent the website checking their version. As of now none of these sub-snippets have different version than the basic s_masonry_block so I guess we can just ignore that since they are not designed to change from the basic s_masonry_block options. And if so should happen in the future they would probably become completely independant snippets. Steps to reproduce : - Enter edit mode - Drag and drop a s_masonry_block snippet - Select one of the blocks of the snippets - On the options panel an errored 'Block' option section appeared. - Click on 'access options anyway', the section is then empty. [1] : https://github.com/odoo/odoo/pull/183755 task-4508767
Public ecommerce visitors no longer receive access to react to product or course reviews unless they have a valid portal identity. This keeps review interaction permissions consistent and prevents anonymous users from seeing or using reaction features incorrectly.
Original PR description
This commit completes the fix https://github.com/odoo/odoo/pull/197508. In this commit we make sure that the thread has the correct `can_react` value by also checking that the user has a valid portal_partner.
Point of Sale now avoids loading a customer's linked price list and products during customer search when those items are not available in the PoS. This prevents extra, unintended data from being pulled into the session and helps keep PoS behavior aligned with its configured availability.
Original PR description
Before this commit, when a partner linked to a specific pricelist was searched and loaded in the PoS, the associated pricelist and its products could be unintentionally loaded, even if they were not available in the PoS. opw-4615603 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change reverts a previous accounting adjustment because currency fallback handling is already covered elsewhere in the system. It helps prevent redundant logic and reduces the risk of inconsistent invoice tax behavior.
Original PR description
Revert https://github.com/odoo/odoo/commit/fbdf519e0dc8830326a8ac120475966002b8474f The fallback of the currency is already managed automatically since: https://github.com/odoo/odoo/commit/1cf68be0807fbbd040022533ecf6372995296989 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes failing HTML editor tests by checking the actual text color used during testing instead of relying on fixed color values. It helps keep automated validation reliable when table cell colors vary for readability in light or dark modes.
Original PR description
**Problem**: Tests are failing due to hardcoded text color in this commit: https://github.com/odoo/odoo/commit/443e1678e748ee2320c4d361d0d0538d862c5f68 Text color might change during tests, causing failures. This issue affects only `td` elements since `color` is added to them when their background is changed to ensure text visibility in dark/light modes. **Solution**: Use the computed text color instead of hardcoded values in tests. runbot-159850 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Document uploads now use the company currently selected by the user instead of defaulting to the user's main company. This ensures company-specific default values are applied correctly in multi-company setups, reducing errors in document ownership and configuration.
Original PR description
### Issue: - When we user-defined defaults based on company_id set on documents, they always trigger based on the user's default company instead of the current company. ### Steps to reproduce: - In a…
### Issue: - When we user-defined defaults based on company_id set on documents, they always trigger based on the user's default company instead of the current company. ### Steps to reproduce: - In a multi-company environment say we have companies A(id: 1) and B(id: 2), and the user default company is A. (he has access to both). - Create 2 user-defined defaults for the field : `documents.document.company_id`, setting value to 1 for company A and 2 for company B. - Create a document using company B, the document's `company_id` will be set to company B which is wrong. ### Solution: - in controllers `request.env.company` always returns the user's default company, so whenever we upload a document (call the `documents_upload` controller), `documents.document` create assumes that the current company is the user's default company. - To fix this, we add the `allowed_company_ids` to the upload request params in the JS `DocumentService` and we intercept in the python controller and set the `allowed_company_ids` context on the request to make sure create will use the current company instead. OPW-4507424
Cash payments in German POS are now reported to Fiskaly based on the payment method type, not the payment method name. This prevents renamed cash methods from being incorrectly shown as non-cash in certification records and dashboards.
Original PR description
When making a payment using a payment method of type cash with a name different than "CASH" the payment type was not being set correctly in the fiskaly payload. Steps to reproduce: ------------------- * Setup fiskaly for the German POS * Create a payment method of type cash but give it any other name than "CASH" * Make a payment using that payment method * Check the payment type on the fiskaly website dashboard > Observation: The payment type is set to "Non cash" Why the fix: ------------ We should base the payment type on the payment method type and not on the payment method name. opw-4606731