Example of steps:

- open any form view with a date field
- navigate to this date field with tab
- For example clicking on the previous field and pressing tab
- type another date press enter (without opening the picker)
- save
=> The change has not been saved.

`onInputKeydown` closes the picker on Escape and on Enter the same
way: by calling `saveAndClose()` directly, without first calling
`updateValueFromInputs()` to parse the raw text typed in the input
into the reactive `pickerProps.value`.

This doesn't work when the calendar popover was never opened
(i.e. the value was typed by hand instead of picked visually),
`saveAndClose()` calls `apply()` directly, which only pushes
`pickerProps.value` to `onApply`. Since that value was never refreshed
from the input's text, `apply()` sees no change and silently returns
without calling `onApply`, so the typed value is lost.

Every other confirmation path (`onInputChange`, the popover's `onClose`, and `Ctrl+Enter`) already calls `updateValueFromInputs()` before proceeding, so plain Enter was the only path missing it.

To fix this we call `updateValueFromInputs()` before `saveAndClose()` in the Enter/Escape case, like every other confirmation path already does.

opw-6511435

When an incoming mail server has the "Keep Original" option enabled, a
copy of every incoming mail is stored as original_email.eml. Because it
is not a document of the invoice, the system unattaches it, however
it may still be used as main attachment in case no other PDF or image
was attached to the message.

Steps to reproduce:
- Configure an incoming mail server with "Keep Original" enabled, using
  an alias pointing to a vendor bill journal.
- Send a mail to that alias containing an xml embedding a PDF.
- Open that bill

Issue:
The invoice's main attachment points to the .eml file.
This occurs because it is set before the PDF is extracted from the xml.
Then, when import extracts the PDF, it is added as attachment on the invoice,
but we already have a main attachment that won't be overwritten.
However, once a pdf or image is added as attachment, the system will show
the (broken) preview.

opw-6431726

Forward-Port-Of: odoo/odoo#285409
Forward-Port-Of: odoo/odoo#280318

When the quantity of a make-to-order manufacturing order is changed, its finished move is copied to propagate the extra quantity downstream. In some cases (after splitting then merging back productions) that copy is not merged back, so the order ends up with two finished moves for the same product.

On validation, two things then go wrong:
- _post_inventory writes the produced quantity on each finished move,
  so both get the full quantity and the production is doubled
- mrp_account._cal_price prices the finished move and calls
  ensure_one(), which raises "Expected singleton" for an average/fifo
  product, so "Produce All" fails

Split the produced quantity across the finished moves with unit_factor (like _set_qty_producing already does), and price them as a whole instead of expecting a single finished move.

Steps to reproduce:
- Create a BoM for product A with the MTO route, and a component B
- Create a Sale Order for 30 units of A, confirm it
- Split the MO into 3 productions of 10, merge two of them
- On the third, Update Quantity 10 -> 15, then Produce All
- The product should be produced once (15, not 30), with A valued in
  average/fifo it instead of an error.

opw-6242504
opw-6310972
opw-6307025
opw-6354739

Forward-Port-Of: odoo/odoo#282733
Forward-Port-Of: odoo/odoo#269254

Steps to reproduce:
- Have an external VoIP software configured (e.g. Linphone)
- Have your Odoo configured and opened too
- Call your VoIP number, using your smartphone => Both the softphone and Linphone ring
- Answer or reject using Linphone => The VoIP call record in Odoo immediately switches from "Trying to call" to "Missed".

While there was no guarantee for our VoIP integration to work alongside Linphone in 19.0, we decided this should be an easy safe enough fix. Starting 19.2 (with [1]), the fix will be simplified and hopefully prettier thanks to the ameliorations that were made.

After this fix, provided Odoo is open while Linphone is used, the call records will now switch to the right terminated / rejected status, still immediately once Linphone answers / rejects.

In future versions and especially 20.0+, the system will be different and will allow way more features like this one to work better (e.g. here the call record only even exists if Odoo is opened while using Linphone and we won't have any information about the call duration).

[1]: https://github.com/odoo/enterprise/commit/942f32316ab02d8c739fe7fdd5ec2bdde472a68e

task-6449259

Forward-Port-Of: odoo/enterprise#128644
Forward-Port-Of: odoo/enterprise#127077

Users who only have accounting rights (not the Settings > Users Companies > Access Rights group) get an access error on the Companies model when generating the BOE file for the Modelo 115 tax reports, even though exporting a BOE file has nothing to do with editing company configuration and should be available to any accountant.

Steps to reproduce:
-------------------
* Log in as a user with accounting rights only (not part of the Companies > Access Rights group)
* Go to Accounting > Reporting > Tax Return, open the Mod 115 report
* Click the gear icon > BOE > Generate BOE

> Observation:
An AccessError is raised: "You are not allowed to modify 'Companies' (res.company) ... This operation is allowed for the following groups:
Access Rights", even though the user is not trying to edit the company.

Why the fix:
------------
The BOE wizard shared by Mod 111/115/303 declares a `company_partner_id` field, related to `company_id.partner_id`, with `readonly=False`. That field is invisible in every view and only exists to compute the domain of `partner_bank_id`; it was never meant to be edited by the user. Because it is declared writable, the ORM attaches an inverse to the related field, so saving the wizard (which happens when generating the BOE, since the field, though invisible, is still part of the view and thus of the saved values) writes `company.partner_id` back onto `res.company`, even though the value never actually changes. That implicit write requires write access on res.company, which is only granted to the Access Rights group, causing the error for regular accountants. Dropping `readonly=False` keeps the field as a plain readonly related field, still usable for the bank account domain, without ever triggering that spurious write.

opw-6388869

Forward-Port-Of: odoo/enterprise#129924
Forward-Port-Of: odoo/enterprise#126661

**Steps to reproduce:**
- Create a quotation
- Add order lines until reaching 200 (duplicating helps), save and ensure that the pager appeared (1-200/201)
- Drag one of the lines with the handle to reorder them
- Discard all changes (X shaped button) 

You will have an evaluation error

**Behavior:**
When loading a list of records exceeding the limit, only parts of the records are saved in `_cache`.
When triggering a reordering of said list, all records need to be loaded including the ones on other pages: https://github.com/odoo/odoo/blob/d4eff7b14d37a9b59c95d304542a5a12629bc90b/addons/web/static/src/model/relational_model/static_list.js#L1139-L1149 `_getResIdsToLoad()` gets all Ids missing from the cache, these are then passed through `._createRecordDatapoint` and will then be stored in `_cache`.
The issue is that the Datapoints are getting created with only `activeFields` as data, which in our case are `id` and `sequence`

When discarding the changes `._checkValidity()`is called on each Datapoint: https://github.com/odoo/odoo/blob/d4eff7b14d37a9b59c95d304542a5a12629bc90b/addons/web/static/src/model/relational_model/record.js#L423-L429 And then `._isInvisible()` is called.
This is where the issue happens, since only `sequence` and `id` are stored, when we try evaluate `combo_item_id`, which is the condition to see if sequence is invisible, `combo_item_id` is not found and we get an Evaluation Error.

This commit prevents going into `._checkValidity()` by adding `this.isInEdition` to the check leading to it, requiring that the record is in 'edit' mode which is not the case for records created with `_createRecordDatapoint()`

opw-6399024

Forward-Port-Of: odoo/odoo#281018

Steps to reproduce:
- Install `l10n_fr_pdp` and `l10n_be` module
- Activate `French e-invoicing` (you need to put your DB in test mode)
  (i.e: `account_peppol.edi.mode = 'test'` in system parameter) Refer this Documentation https://www.odoo.com/documentation/19.0/applications/finance/fiscal_localizations/france.html?highlight=e%20invoicing#localizations-france-e-invoicing-fac-elec-config
- Create a Invoice and Sent with `E-invoicing`
- Run `PEPPOL: retrieve new documents` Cron
- In Invoice Other Info >  `E-Invoicing Status` should be in `Done` state
- Now Vendor Bill is created for that invoice > Cancel that bill with reason >  Check `E-Invoicing Status` response for bill(one response will be without UUID)
- Go to schedule actions > `PEPPOL: update message status`
- Run it and get the traceback: `KeyError: 'false'`

Issue:
When sending a lifecycle response to the French PDP, `_pdp_send_response` calls the `/api/pdp/1/send_response` endpoint and expects IAP to return a `message_uuid` for each response.

However, IAP return a response without a message UUID, for example: ` {'messages': [{'message_uuid': False}]}` `_pdp_send_response` currently assumes that every returned message has a valid UUID and creates an `account.peppol.response` with:
```
    'peppol_message_uuid': False
    'peppol_state': 'processing'
```
This leaves an `account.peppol.response` in `processing` state without a UUID that can be used to track it.

During the next execution of `_cron_peppol_get_message_status`, `_peppol_get_message_status` retrieves this response through `_peppol_get_documents_for_status` and builds `uuid_to_record` using `peppol_message_uuid` as the key. The resulting mapping contains the Python value `False` as a key.

The cron then calls the PDP `1/get_document` endpoint with this invalid UUID. IAP returns it as the string `'false'`, which is passed to `_peppol_process_messages_status`. The French PDP implementation tries to retrieve the corresponding record with: `uuid_to_record[uid]`

Since the mapping contains `False` while `uid` is `'false'`, this raises: `KeyError: 'false'`

This failure prevents the status cron from completing the processing of the messages.

Solution:
Avoid creating the `account.peppol.response` when IAP does not return a `message_uuid`. A response without a UUID cannot be tracked through the PDP status flow, so creating it in `processing` state only leaves an
invalid record that will later cause the status processing to fail.

opw-6453133

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#281691

### Steps to reproduce: 

- Create a subcontracted product P1
- Create a storable product P2
- Buy 5 units of both products from your subcontractor
- On the receipt set both moves quantity to 2 Units
- Validate the receipt and create a backorder
#### > Only the subcontracted move has been kept on the receipt and a backorder was created for 3 units of P1 and 5 of P2.

### Cause of the issue:

Setting the quantity of the subcontracted move will automatically record the quantities on the subcontracted MO: 
https://github.com/odoo/odoo/blob/9440ff9064c77af0159a427de8f5e5721aec0de5/addons/mrp_subcontracting/models/stock_move.py#L83
https://github.com/odoo/odoo/blob/9440ff9064c77af0159a427de8f5e5721aec0de5/addons/mrp_subcontracting/models/stock_move.py#L123
https://github.com/odoo/odoo/blob/9440ff9064c77af0159a427de8f5e5721aec0de5/addons/mrp_subcontracting/models/mrp_production.py#L91
However, the `_update_finished_move` method adds and update the related subcontracted move lines marking them as *picked* to adapt the related reservation:
https://github.com/odoo/odoo/blob/9440ff9064c77af0159a427de8f5e5721aec0de5/addons/mrp_subcontracting/models/mrp_production.py#L118-L164
This is problematic since picking a move line will also pick the move:
https://github.com/odoo/odoo/blob/9440ff9064c77af0159a427de8f5e5721aec0de5/addons/stock/models/stock_move.py#L261-L267
And only picked moves are considered to be processed at picking validation.

### Note:

The exact same issue had already been fixed in 17.0: db8b33ebb9fe23507bcba30b12741e4d688ae549
However, the fix had an issue concerning the barcode behavior as it removed the picked computation for subcontracted moves which made  hybrid pickings such as the above one (with one subcontracted and one non-subcontracted move) impossible to process in the barcode app. As such, the fix and test where reverted in cf2d18c92bee55ef79db1a338e9baf12f258ee5b

The present commit provides an alternative fix of the original issue keeping subcontracted moves unpicked by quantity changes without affecting the picked computation of subcontracted moves (e.g. adding  a picked move line on a subcontracted move will still pick that move).

Enterprise: https://github.com/odoo/enterprise/pull/123884

opw-6330584

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#285614
Forward-Port-Of: odoo/odoo#275304

Problem:
In Calendar, dragging a slot opens the quick create dialog. Typing a
subject and clicking the expand button in the dialog header creates the
event, but the form that opens is empty, and saving it creates a second
event for the same slot.

Cause:
`FormViewDialog` stores the id of the record it saved in `currentResId`,
which `onExpand` passes as `res_id`. `saveRecord` sets it only in the
branch that runs when no `onRecordSave` prop is given.
`AttendeeCalendarController` passes one since 30478fe855cd
(odoo/odoo#239435), so `currentResId` stays false and the action opens a
new record.

Solution:
Set `currentResId` in the shared branch of `saveRecord`. It is private to
`FormViewDialog`, so a consumer passing `onRecordSave` cannot set it.

Steps to reproduce:
- Open Calendar.
- Drag a slot in the week view to open the quick create dialog.
- Type a meeting subject.
- Click the expand button in the dialog header.
- Observe that the form opens on a new record while the event is created.

Ticket [link](https://www.odoo.com/odoo/project/49/tasks/6476930)

opw-6476930

Forward-Port-Of: odoo/odoo#285899