Daily updates from Odoo
Sunday, July 5, 2026
5 changes · saas-19.4
Resolved issues and error corrections
PDF form fields are now locked during the signing process instead of being flattened in a way that could change how the document looks. This keeps signed documents visually consistent for users while preventing fields from being edited during signing.
Original PR description
Currently, we flatten fields in a naive way which does not handle many edge cases and can alter the PDF appearance for users. We could use pypdf to handle production-grade flattening, but Odoo's `pypdf` dependency (5.4.0) does not support native form field flattening (which was introduced in 5.8.0). To resolve this, rather than flattening, we lock the interactive fields so they are no longer editable while signing, which perfectly maintains the original appearance. In the future, when we support higher pypdf versions, we can truly flatten the PDF to provide a better user experience. task-6037759 Forward-Port-Of: odoo/enterprise#122966 Forward-Port-Of: odoo/enterprise#112351
This fixes an error that could prevent AI Studio fields from being filled in appraisal forms when prompts referenced employee feedback. The AI feature now passes field information in the expected format, improving reliability for users configuring AI-assisted forms.
Original PR description
**STEPS TO REPRODUCE** 1. Add an AI Studio field in the employee appraisal form view (can be a regular text field or other) 2. Add `employee_feedback` to the prompt using '/' 3. Click the AI button to populate the field 4. Error occurs: `TypeError: unsupported operand type(s) for +: 'OrderedSet' and 'list'` **CAUSE** In any model, the read function expects the argument `fields` to be a list. When using AI fields in Studio, the fields argument is stored as an OrderedSet instead of a list, causing errors when performing operations. opw-5954203 Forward-Port-Of: odoo/enterprise#121981 Forward-Port-Of: odoo/enterprise#120799
This update resolves issues where scanning employee badges within the Point of Sale (PoS) system wasn't working correctly, specifically when entering a PIN. The fix ensures badge scanning seamlessly integrates with the PIN input, allowing users to log in and process transactions reliably. It also corrects a bug where scanning another cashier's badge didn't switch the active cashier.
Original PR description
See commit messages. [[FIX] pos_hr: scanning badge should work with PIN input focused](https://github.com/odoo/odoo/commit/95d9329674e81b2659445e2021a35b21bbbc81a3) [[FIX] point_of_sale: scanning a badge should not auto confirm the PIN](https://github.com/odoo/odoo/commit/d59fb1f6fe27d117579b3945c5bba400d17d0014) (Note: this is only needed up to saas-18.4 included -- 19.0 already has this diff) [[FIX] pos_hr: scanning another cashier's badge switches to that cashier](https://github.com/odoo/odoo/commit/c812fe596694b16a494e3dcf908d17f621f7ce92) opw-6125029 Forward-Port-Of: odoo/odoo#274259 Forward-Port-Of: odoo/odoo#262474
This update ensures that return stock moves now correctly display the reference for the return picking itself (WH/OUT/000XX) instead of the original receipt. Previously, the reference was incorrectly linked to the original order, causing confusion in tracking returned items. This change clarifies the stock movement process and improves inventory accuracy.
Original PR description
Steps to reproduce: ------------------- - Install `stock` - Create a receipt for a product with `x` quantity - Validate the receipt - Click `Return` and create a return picking - Validate the return…
Steps to reproduce:
-------------------
- Install `stock`
- Create a receipt for a product with `x` quantity
- Validate the receipt
- Click `Return` and create a return picking
- Validate the return picking
- Open the Moves History
Issue:
------
The stock move line generated by the return operation still displays the
original receipt reference (`WH/IN/000XX`) in the Reference column
instead of the return picking reference (`WH/OUT/000XX`).
As a result, the return move appears to belong to the original receipt
rather than being identified as a separate stock operation.
Cause:
--------
In this [commit](https://github.com/odoo-dev/odoo/commit/1c7d80a10b5d7db1c4163166bf52b3f3c77044ba
) `reference` is become editable field (readonly=False)
Now `stock.move.reference` is a stored, editable computed field
https://github.com/odoo/odoo/blob/53cbd4ee7e6ddc1994607d457dfff3fd03e82418/addons/stock/models/stock_move.py#L182
Since `_compute_reference` derives its value from `move.picking_id.name
https://github.com/odoo/odoo/blob/53cbd4ee7e6ddc1994607d457dfff3fd03e82418/addons/stock/models/stock_move.py#L383
Because the field is both `store=True` and `readonly=False`, the
field-setup logic in `Field._setup_attrs_` no longer applies its usual
default of disabling `copy` for computed fields
https://github.com/odoo/odoo/blob/53cbd4ee7e6ddc1994607d457dfff3fd03e82418/odoo/orm/fields.py#L460-461
With `store=True` and `readonly=False`, this condition evaluates to
`False`, so the line is skipped and `copy` falls back to the base
`Field` default of `True` instead of `False`.
https://github.com/odoo/odoo/blob/53cbd4ee7e6ddc1994607d457dfff3fd03e82418/odoo/orm/fields.py#L286
When the return wizard duplicates the original move with
https://github.com/odoo/odoo/blob/53cbd4ee7e6ddc1994607d457dfff3fd03e82418/addons/stock/wizard/stock_picking_return.py#L53
therefore copies the *old* stored `reference` value ("WH/IN/000XX") into the
`create()` vals of the new move, alongside the new `picking_id`.
`BaseModel.create()` then protects editable computed fields that
receive an explicit value in `vals` from being recomputed.
https://github.com/odoo/odoo/blob/53cbd4ee7e6ddc1994607d457dfff3fd03e82418/odoo/orm/models.py#L3996-L3999
Since `reference` is present in `vals` and `readonly=False`, it is
added to the `protected` set, so `_compute_reference` never runs for
the new move even though its `picking_id` now points to the new
return picking. The stale value from the original receipt is kept
as-is, and propagates to the move line via the related field
https://github.com/odoo/odoo/blob/53cbd4ee7e6ddc1994607d457dfff3fd03e82418/addons/stock/models/stock_move_line.py#L89
Fix:
----
Set `copy=False` explicitly on `stock.move.reference`, restoring the
behaviour it had before `readonly=False` was added (when `readonly`
defaulted to True, `copy` was already False automatically). This
keeps the field editable in the UI while preventing the stale value
from being carried over on `copy()`, so it is correctly recomputed
from the new move's own `picking_id`.
---
opw-6293019
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#270473This update resolves a rare technical issue within the Odoo web interface that could cause a component to be destroyed during testing. The fix adds a simple step to ensure popovers are properly closed, preventing errors related to RPC calls while components are being shut down. This improves the stability of our testing process.
Original PR description
Add an extra step to close the popover and prevent the `Component is destroyed` error[1], which can happen during hoots cleanup, similar to the issue we see when some dialogs perform RPCs as they are being destroyed. [1]: https://runbot.odoo.com/runbot/build/115972540 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273826 Forward-Port-Of: odoo/odoo#273085