Sunday, July 5, 2026
3 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 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#270473