Tuesday, June 16, 2026
14 changes · 19.0
Resolved issues and error corrections
This fixes an issue where certain combined website builder actions could fail when a user clicked an element with that option. The change makes these actions run with the correct context, improving reliability for website customization flows, and adds test coverage to prevent the problem from returning.
Original PR description
In 18.4 the composite action isn't used extensively, so the problem was unnoticed. However, if you use it with an action that has a `getValue` set, you may get issues, since the action will not be bound. Possible way to reproduce the issue: - Create an option that uses the `composite` action - Set `customizeWebsiteVariable` as a first action in the `actionParam` - Click on an element that has that option => You'll get an error. Note, that testing just this would be useless, so I added a test that tests that the action uses the first `getValue`. Without this fix the test would crash since in `getValue` `this` is unbound. Forward-Port-Of: odoo/odoo#269873
Debit note PDFs now display as debit notes instead of being labeled as invoices when printed or sent. This helps customers and accounting teams clearly distinguish debit notes from regular invoices and avoid document confusion.
Original PR description
### Steps to reproduce the issue: 1. Download Invoice and Debit Notes 2. Go to an invoice (or create a new one) 3. Create a debit note for that invoice and print it or send it 4. In the PDF the title is 'INVOICE DINV....' instead of 'DEBIT NOTE DINV...' ### Reason to introduce the fix: Differentiate debit notes from invoices. opw-6252239 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268207
Polish electronic invoices now keep more decimal places for unit prices, so line totals better match the quantity multiplied by the unit price. This reduces confusing discrepancies in exported KSeF XML files, even though the previous invoices were still accepted as valid.
Original PR description
**STEP TO REPRODUCE** 1. Create an invoice with a unit price of 10.005 and qty of 2. 2. Send the invoice to ksef. 3. Open the xml and notice P_9A (unit price) is 10.00 and P_11 (total without tax) is 20.01 Which is inconsistent (10.00 * 2 =/= 20.01). This PR increase the decimal places of P_9A to 8 digits which is the maximum allowed by the FA(3) format. Note that Ksef doesn't verify the untaxed unit price * quantity = total without tax, so the invoice we send are technically valid. However, it's best to generate invoice where the numbers add-up. opw-6203896 Forward-Port-Of: odoo/odoo#263812
Point of Sale sales detail reports now keep the date range chosen by the user in the report header. This prevents confusion when reviewing sales for part of an open session, while session-specific reports still show the full session period.
Original PR description
Steps to reproduce ------------------ 1. Open a PoS session, e.g. at 1h45 2. Wait a bit and make an order, e.g. at 1h55 3. Keep the session open and go to PoS > Reporting > Sale Details. 4. Select a…
Steps to reproduce ------------------ 1. Open a PoS session, e.g. at 1h45 2. Wait a bit and make an order, e.g. at 1h55 3. Keep the session open and go to PoS > Reporting > Sale Details. 4. Select a starting date before the ordre and after the session open, e.g. at 1h50 5. Generate the report. The header shows the starting date of the session, i.e. at 1h45, instead of that of the selected date, i.e. 1h50 Why it's happening ------------------ Commit 5003774bf2a7 changed the way the report decides if the data comes from a single session: now if all the orders in the user selected start and end date belong to one particular session, the start and end date on the report are overriden to be those of that particular session, ignoring the user selected ranges. The fix ------- Only overwrite the start and end dates when `session_ids` was passed (i.e. the report is about a specific session). When called via date range + `config_ids` (from the backend wizard like in our reproduction steps), keep the user-selected range. opw-6185106
Selected items in multi-select menus now appear above the input field instead of sharing the same line. This keeps the input area from shrinking or wrapping unpredictably, making selection fields easier and more consistent to use.
Original PR description
Before: With multiSelect enabled, tags appear on the same line as the input, shrinking it. After multiple selections, the input wraps to the next line inconsistently. After: Tags and the input are always on separate lines. task-5226503
This fix prevents an error when comparing a page or editor history entry that happens to be empty. Users can continue viewing history differences without the comparison failing unexpectedly.
Original PR description
If, for whatever reason, the history we try to compare is an empty string, we might get a value error thrown. We guard the code to avoid the error. see :https://github.com/odoo/odoo/issues/269149 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269722
Fixes a mail issue where adding a reaction to a message could crash when using a small browser window on desktop. This keeps message reactions reliable across different screen sizes and avoids user disruption.
Original PR description
Before this commit, when browser window is small while not on a mobile device, clicking on the message action "Add a reaction" would lead to the following crash: ``` Cannot destructure property…
Before this commit, when browser window is small while not on a mobile device, clicking on the message action "Add a reaction" would lead to the following crash:
```
Cannot destructure property 'owner' of 'undefined' as it is undefined.
at Proxy.onSelected
```
This happens because cliking on this button on small screen would immediately trigger the complete showing of the emoji picker rather than just the quick menu. While this calls `action.onSelected()` and is expected to work [1], the problem is that this was passing the action definition rather than the action object as prop. As a result, `onSelected()` was using the definition and didn't pass the expected params that are destructed in the definition.
This commit fixes the issue by passing the `action` object to `QuickReactionMenu` component, so that the `action.onSelected()` is properly passing the `action.params`.
[1]: https://github.com/odoo/odoo/blob/19.0/addons/mail/static/src/core/common/quick_reaction_menu.js#L84Overtime durations are now stored with greater precision when attendance records generate overtime entries. This helps avoid tiny rounding errors that could affect pay-related calculations.
Original PR description
Overtime duration computed as fractional hours was rounded to 3 decimal places before being stored on the overtime line. Since 1 decimal hour = 3600 seconds, this gives only 3.6 seconds of precision and the rounding can go in the wrong direction due to floating-point representation. The fix consists in replacing the duration rounding to 4 decimals when building overtime work entries so stored durations keep sub-second precision needed for money computation. task-6212231 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Cashdro payments that are manually force completed will no longer show an error if the background cancellation request fails. Requests to the cash machine now time out faster when the configured IP address is wrong, reducing waiting time and avoiding confusing error screens.
Original PR description
In odoo/odoo#268496, a fallback was added to automatically cancel the payment when forcing it, to avoid the cash machine getting stuck with a payment in progress. However, if an error occurs with this cancel request, it causes a traceback to appear. In this commit, we now catch the error from the cancellation, and don't show it to the user at all since they have already force completed the payment. We also add a timeout to Cashdro requests to fail faster when using a wrong IP (e.g. 1.2.3.4). task-6307491 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update optimizes the MRP work order process by preventing unnecessary BoM explosions for non-material quality points like instructions and pass/fail checks. Previously, this process was slow, but now it's significantly faster, reducing processing time by orders of magnitude. This improves overall system responsiveness and efficiency.
Original PR description
`_compute_component_ids` unconditionally called `bom.explode()` for every product variant on the BoM, even for quality point types (`instructions`, `pass_fail`, etc.) that never use the `component_id` picker. The field is only meaningful for `register_consumed_materials` and `register_byproducts`. Restrict the expensive path to those two types with an `elif` so all other types return `component_ids = False` immediately. | # Input data | Before PR | After PR | |:---:|:---:|:---:| | 10 variants, 10 components, 2 phantom BoMs, 3 ops | 841 ms | 0.1 ms | | 30 variants, 20 components, 5 phantom BoMs, 3 ops | 1,343 ms | 0.1 ms | | 80 variants, 40 components, 12 phantom BoMs, 5 ops | 8,674 ms | 0.1 ms | OPW-6210368
This update corrects a potential issue in the Swiss payroll module where users could incorrectly request refunds for payslips. Swiss regulations limit one payslip per month, so the system now directs users to cancel and re-create the payslip for any necessary corrections, ensuring compliance with Swiss tax laws.
Original PR description
Prevent refunds for CH payslips since only one payslip per month is allowed for Swiss payroll. Users should cancel the payslip and create a new one to apply corrections. task-5951981 Forward-Port-Of: odoo/enterprise#107943
This update corrects a bug that occurred when a subformula was removed from a report without resetting its value. This prevented errors during record processing, ensuring reports could be generated correctly. The change resets subformula values to 'False' to avoid future issues.
Original PR description
The subformula was [removed](https://github.com/odoo/enterprise/pull/117601) without resetting its value to False, leaving existing values in the database. This causes errors when processing records that still contain a subformula value. ```.py Invalid subformula in expression "balance" of line "Treasury shares": -sum ``` To prevent these errors, existing subformula values are reset to False opw-6297901
This update corrects a bug where selection fields in Odoo's web studio were incorrectly flagged as required, even when not explicitly marked so. The change ensures that required fields are only applied when explicitly set to 'true', preventing unexpected behavior and improving the usability of the studio for users creating and editing forms.
Original PR description
Before: any studio property using a SelectMenu (selection) component, without a `required: false` in the childProps, was implicitly required because the check used `required !== false`, which evaluates `undefined` as truthy. After: `required` is only applied when explicitly set to `true`. task-5226503
This update resolves two key issues related to attaching documents to employee records. Previously, attachments were created in the root 'Employees' folder, which was inconvenient. Additionally, creating sick leave attachments didn't always generate a document. This fix ensures attachments are correctly created in the appropriate folder and that all attachment types are properly recorded.
Original PR description
Before this commit, when adding an attachment to a leave or a employee version the mixin was configured to create the document in the root folder of Employees which was not very convenient. In addition, when creating a Sick leave with an attachment, no document was ever created. This commit fix both those bugs. Task-6095811 Forward-Port-Of: odoo/enterprise#119417 Forward-Port-Of: odoo/enterprise#112993