Daily updates from Odoo
Thursday, May 29, 2025
8 changes
1 change
Resolved issues and error corrections
Installing the Settle Due point-of-sale module no longer fails if the default Services product category was previously removed. This prevents an installation error and lets businesses enable the module without manually restoring that category first.
Original PR description
Currently a ParseError is arising when the user installs the `pos_settle_due` module after deleting the `Services` in Product Categories/Configuration. Steps to reproduce: --- - Install `Invoicing`…
Currently a ParseError is arising when the user installs the `pos_settle_due` module after deleting the `Services` in Product Categories/Configuration.
Steps to reproduce:
---
- Install `Invoicing` application (without demo data).
- Invoicing > Configuration > Product Categories > Delete `Services`
- Now install `pos_settle_due` module
Traceback:
---
```
ValueError: External ID not found in the system: product.product_category_services
ParseError: while parsing /home/odoo/src/enterprise/saas-18.3/pos_settle_due/data/pos_settle_due_data.xml:22, somewhere inside <record id="product_product_settle_invoice" model="product.product">
<field name="name">Settle Invoice</field>
<field name="categ_id" ref="product.product_category_services"/>
<field name="type">service</field>
<field name="weight">0.00</field>
<field name="available_in_pos">False</field>
<field name="taxes_id" eval="[]"/>
</record>
```
The error occurs because the user deleted `Services` in Product Categories, and then tried to install the other module.
This commit resolves the error by providing a False value for the field if the product category is missing.
sentry-63776593551 change
Resolved issues and error corrections
Template names were updated to use the correct module prefixes after the HTML builder integration. This reduces the risk of naming conflicts and helps appointment, knowledge, and studio website features behave consistently.
Original PR description
*: website_appintment, website_knowledge, website_studio This commit corrects improperly prefixed template names introduced during the integration of the new HTML builder. This ensures consistency and avoids conflicts or ambiguity when referencing templates across website modules. Community PR : - https://github.com/odoo/odoo/pull/211723
6 changes
Resolved issues and error corrections
Manufacturing unbuild forms now allow quantities with the same decimal precision as the product's unit of measure. This prevents valid manufactured quantities, such as three-decimal amounts, from being rounded or blocked when reversing a production order.
Original PR description
Steps to reproduce the bug:
- Set the decimal precision and rounding accuracy for the unit of measure to more than 2 digits (e.g. 3)
- Create a storable product “P1”
- Create a manufacturing order to produce 1.234 units
- Confirm and validate it
- Try to unbuild the MO
Problem:
The unbuild form does not respect the product's UoM decimal precision, allowing only 2 digits for product_qty.
opw-4818591Point of Sale invoices now calculate and display discounts added directly to order lines even when pricelist discounts are also used. This prevents printed invoice totals from showing missing or incorrect discount amounts when prices are manually adjusted.
Original PR description
### Problem:
The discount display policy in POS invoices is designed to hide discounts when a pricelist with a percentage-based discount is applied to its items. However, if an additional discount is added directly to a POS order line, it will not be shown in the total.
Additionally, if one of the lines has a manually modified price, the total will incorrectly reflect that line's discount.
### How to reproduce:
* Add a percentage discount to one of the products in the pricelist
* Order two products and add a percentage discount to both
* Modify the price of the order line for one of them
* Complete the order (the printed invoice total discount is the total discount of the manually modified line)
opw-4776259When users work with multiple companies at once, product sale and purchase taxes now show which company they belong to. This removes ambiguity when selecting or reviewing taxes on products and helps avoid choosing the wrong company-specific tax.
Original PR description
Backport of some changes included here https://github.com/odoo/odoo/commit/2cf73ba8fe50288a0ea9d0ad4b8aeb51bc345740 (if this pr 212215 is merged then is not neccesary to merge the FW to master) The…
Backport of some changes included here https://github.com/odoo/odoo/commit/2cf73ba8fe50288a0ea9d0ad4b8aeb51bc345740 (if this pr 212215 is merged then is not neccesary to merge the FW to master) The goal of this pr is to see for which company belongs each sale/purchase tax in a product when more than one company is selected. This pr solves odoo task #4829985 and this issue https://github.com/odoo/odoo/issues/147673 Steps to reproduce: 1) Go to runbot odoo enterprise 18 instance and select companies "My Belgian Company" and "My Company (San Francisco)" taking position in "My Belgian Company". 2) Go to "Accounting / Customers / Products" and get into product with name "Bolt" and internal reference "CONS_89957". There is shown two taxes in "Sale Taxes" and "Purchase Taxes" fields but is not possible to distinguish for which company belongs each tax.  Current behavior: It can not be distinguished whenever for which company belongs each customer tax in a product if more than one company is selected. Expected behavior: It can be distinguished whenever for which company belongs each customer tax in a product if more than one company is selected. Task Adhoc side: 51853 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue in Discuss where someone writing a long message could disappear from the "is typing..." indicator before they stopped typing. The indicator now refreshes correctly, giving other users a more accurate view of ongoing conversations.
Original PR description
Before this commit, if a user is typing without interrupt for more than 1 minute, other members stop seeing this person from about 40 seconds. As a reminder, the "is typing..." feature in discuss is…
Before this commit, if a user is typing without interrupt for more than 1 minute, other members stop seeing this person from about 40 seconds. As a reminder, the "is typing..." feature in discuss is implemented as follow: - when typing, notify `is_typing: true` once every 50 seconds. - when stop typing for 5 seconds, notify `is_typing: false`. - other members assume stop typing if nothing received after 60 seconds. This logic is good, but there was a problem with current implementation: members only send and receive `isTyping: true` through `mail.record/insert` notification. This means a long typer is seen as follow ``` - time: 0sec. -> is_typing: true sent + received - time: 50sec. -> is_typing: true sent + received - time: 60sec. -> is_typing: false (assuming stop typing) - time: 100sec. -> is_typing: true sent + received ``` This is the case because the notification is `mail.record/insert` so from the store data, data of `isTyping` is unchanged. The timeout was made through a change of `isTyping` status, which doesn't in this scenario, hence the problem of assuming stop typing. This commit fixes the issue by sending the datetime of notified `is_typing` and linking the timeout to the datetime of last notified of `is_typing` of this member. This fix ensures that at the 50sec, the timeouts are refreshed and they have to wait until time 110sec. to assume stop typing, which is good in case the message is very long as typer will warn again at time 100sec. with refreshed datetime. runbot-223760
The event list view now correctly displays key card information such as sold out and unpublished statuses. This helps website visitors and event managers see accurate event availability and publication details when switching between grid and list views.
Original PR description
When changing the website view of the events from grid to list, we are losing the "Sold out, Unpublished, etc" information that was displayed on the card. This is due to loading the event calendar date widget before the rest of the elements which is provoking them to not properly load. opw-4597647 ## Before:  ## After: 
Removing a lot number from a manufacturing order no longer automatically marks components as consumed. This prevents unnecessary manual correction and lets users reassign lots and check component availability smoothly.
Original PR description
Issue: ------------------------- In a Manufacturing Order, when a lot number is assigned to a product and then removed, the components are consumed automatically. Steps to Reproduce:…
Issue: ------------------------- In a Manufacturing Order, when a lot number is assigned to a product and then removed, the components are consumed automatically. Steps to Reproduce: ------------------------- - Create an MO for a lot-tracked product. - Assign a lot number to the product, then remove the assigned lot number. - Notice that the component is automatically marked as Consumed. With this commit: ------------------------- Previously, removing the lot number triggered an `onchange`, which called `_set_qty_producing`. This method auto-marked the component as consumed. As a result, users cannot re-reserve the components using the Check Availability button unless they manually uncheck the Consumed field. This commit updates the logic to ensure that removing an assigned lot does not trigger component consumption. This allows users to reassign and re-reserve components smoothly in the production flow. Task ID: [4797711](https://www.odoo.com/odoo/all-tasks/4797711)