Description of the issue this commit addresses:

Happens since https://github.com/odoo/enterprise/commit/40484f985f511edd7ba2ae759ce63ef564bcf1f7

When rebuilding report options, _init_options_date applies the
default_opening_date even when explicit date_from/date_to are
provided. This can trigger an unintended shift (e.g. previous_month),
causing exports to use incorrect periods.

----

Steps to reproduce (exemple among many more):

1. Install l10n_nl_reports and go on the NL Company.
2. Create an invoice for a belgian partner in February.
3. Go to the EC Sales List report and select february 1st to 28/29.
4. Export for XBRL (cog icon) and download file. Invoice values are not in.
5. When debugging the export, you can see the exported dates are January.

----

Desired behavior after this commit is merged:

This commit ensures explicit dates take precedence by inferring the
period_type instead of applying default_opening_date, preventing
unexpected date shifts during export and preserving the selected
period.

----

task-6065382

…getting column_group_totals from json

Backport of f91e98fe645768db4af590fa4cdfe2ddfe85f888

// Bug

The following flow failed:

1) Create a report with 3 lines:
    - Line 1: using the "domain" engine
    - Line 2: using the "external" engine, with subformula="editable"
    - Line 3: an aggregation summing lines 1 and 2

2) Open the report, and edit the amount in line 2

===> Error message, stating Line 1 cannot be evaluated while evaluating Line 3's formula.

// Cause of the issue

When editing a manual value, to avoid recomputing the whole report uselessly, the client sends the column_groups_totals that were computed to render report back to the server. When modifying the external value, that data structure is used to get the results of all other expressions, and reevaluate the aggregations that depend on the modified external value. json is used to send the column_group_totals.

json conversion always forces the keys to be strings. In the past, this was no problem, since the column_group_totals' keys were column group keys, which were also strings server-side. However, https://github.com/odoo/enterprise/commit/ec3581cd759d8c4e03db9e08f6f95546e5724e1f now makes those key indices of a list, hence integers. So, when column_group_totals were sent from the client, they basically were ignored, since none of their keys matched any column group index, causing the bug.

Currently, an error occurs when user converts a helpdesk ticket into an opportunity.

**Steps to Reproduce:**
 - Install the `crm_helpdesk` module.
 - Go to `Helpdesk` > `Tickets` > `All Tickets`.
 - Create a `new ticket`, set only the `ticket name`, and `save` the record.
 - Click on the `Convert to Opportunity` button.

**Error:**
`TypeError: 'bool' object is not iterable`

After this [recent commit], the system attempts to find the partner using the partner email. 
Since the helpdesk ticket does not have partner email, False is passed as the email [1]. 
As result, when retrieving emails based on the ticket record, it returns False, and iterating 
over it raises the error [3].

This commit ensures that the system attempts to find the partner from the email only if the 
partner email exists. It also passes the partner email as a list, since _partner_find_from_emails_single 
expects emails in list format.

[recent commit]: https://github.com/odoo/enterprise/commit/41aa34b74f59d48c3ad2fc87a5655866fda968c9

[1]- https://github.com/odoo/enterprise/blob/241b2b0174731558795572d8843d9b184d98e2e0/crm_helpdesk/models/helpdesk_ticket.py#L21

[2]: https://github.com/odoo/odoo/blob/6ccdc3b6e6f2957a73eb1539fc37de800a229569/addons/mail/models/mail_thread.py#L2050

[3]: https://github.com/odoo/odoo/blob/6ccdc3b6e6f2957a73eb1539fc37de800a229569/addons/mail/models/mail_thread.py#L2052

sentry-7359614247

When scaning a lot after a packaging, the lot won't recognize the packaging and will not work properly

### Steps to reproduce:

* In the settings enable packagings
* Create a storable product P with Units as uom, a barcode and tracked by lots
* Create new lots with barcode for Product P
* Inventory > Configuration > Product > Units & Packagings
* Click on pack of 6 > Packaging Barcodes > New
* Create one for your product with a different barcode
* Go to barcode > Operations > eg. internal transfer > New
* Scan packaging barcode
* Scan one of the lots
-> Issue, the lot create a new line, and will not find the packaging

### Observation:

When scanning a barcode, it will first try to find a match with existing lines,
In our case, it will find a match with the line of the packaging, but since the line is considered as "completed" since there was no expected quantity since we create a new picking:
https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_picking_model.js#L1497-L1501
It will erase the line, to avoid to overfill a completed line:
https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1459-L1460
and since, it decided to ignore that line, it will not find another lines, and will create a new one :
https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1535

Additional Issues
-----------------
Issue 1 : When scaning a packaging, lot1, packaging, lot2, all the packagings will be linked to the first lot, which doesn't allow us to scan multiple lots.
Issue 2 :  When having sublines with different uoms, it will add the quantity without considering the differences in uoms

### Steps to reproduce:

* In the settings enable packagings
* Create a storable product P with Units as uom, a barcode and tracked by lots
* Create new lots with barcode for Product P
* Inventory > Configuration > Product > Units & Packagings
* Click on pack of 6 > Packaging Barcodes > New
* Create one for your product with a different barcode
* Create a packaging 2 with barcode for product A
* Go to barcode > Operations > eg. internal transfer > New
* Scan packaging 1 barcode
* Scan one of the lot 1
* Scan packaging 1
* Scan lot 2
-> Issue 1, the packaging 2 will be link to lot 1, it won't be possible to link any packaging to another lot.
* Scan packaging 2
-> Issue 2, it create a subline (excpeted), but the sum that appear on the main grouped line is wrong, it doesn't considere the difference in uoms

### Observation:
Issue one :
When scanning a barcode, it will first try to find a match with existing lines, since the uom is the same it will not be erased by the full line check
https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1456-L1460
and since, it found a line, it will just add it's self to the line

Issue Two:
When creating the group lines it will first calculate the sum of all the quantities:
https://github.com/odoo/enterprise/blob/8774388a7b1b2ca2c08c752026ac1a20dbc10347/stock_barcode/static/src/models/barcode_model.js#L248-L254
And after inside of groupSublines it will choose the main line and it's uom and use the previous sum for the total quantity:
https://github.com/odoo/enterprise/blob/8774388a7b1b2ca2c08c752026ac1a20dbc10347/stock_barcode/static/src/models/barcode_picking_model.js#L1456-L1461

opw-5189492
opw-5408372

Forward-Port-Of: odoo/enterprise#108666
Forward-Port-Of: odoo/enterprise#98701

To reproduce the issue:

- Setup tax periodicity to "trimester"
- Create a report evaluating something with previous_tax_period date_scope (real cases tend to do that for carryover ; see monthly Italian tax report for an example)
- Create the appropriate data so that in the current trimester, the report line evaluates to 42, and to 1 in the previous trimester
- Open the report for the second month of the trimester => The line has value 42, while it should have 1.

This happens because the date bounds for previous_tax_period were computed too naively, considering the date_from was always the first day of the tax period. The first day of the second month of the trimester, it's not the case, and we return the period boundaries of the day before that day. That day is the last day of the first month of the trimester, but belongs to the same trimester, so it's the same tax period. Therefore, we display the value of the current tax period, which is wrong.

Forward-Port-Of: odoo/enterprise#111721
Forward-Port-Of: odoo/enterprise#110504

Steps to produce:
---
- Install `purchase_stock` module.
- Inventory > Configuration > Settings > Warehouse > enable `Multi-Step Routes`.
- Go to Configuration > Warehouse Management > Warehouses.
- Open `YourCompany` record.
- Click on Routes > open `Buy` > enable `Products`.
- Return to `YourCompany` and disable `Buy to Resupply`.

Issue:
---
- After disabling `Buy to Resupply`, the option is automatically re-enabled.

Root cause:
---
- In [1], `buy_to_resupply` is set to true if either buy route is product selectable OR the current warehouse is included in buy route warehouses.
- In the `_inverse_buy_to_resupply` method, unchecking the flag only unlinks the warehouse from the route. However, if `product_selectable` is still enabled, the compute logic will continue to set the field back to true.

Solution:
---
- `warehouse.buy_to_resupply` is now set to True only when the warehouse ID is present in the buy route’s warehouse_ids.

[1] https://github.com/odoo/odoo/blob/aeaace7c70b7ac3db68f188c9c517f1ff849e55d/addons/purchase_stock/models/stock.py#L57

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

Forward-Port-Of: odoo/odoo#250360

When scrapping a kit product, an error would pop if account is installed

Steps to reproduce:
-------------------
* Install stock, mrp, account
* Create a product
* Create a bom of type kit for that product
* Put some quantity of the component in stock
* Mrp>Operantion>Scrap
* Scrap the kit product

Observation:
-------------
When a product is scrapped, the ```do_scrap``` method triggers ```_action_done``` on the new kit ```stock.move```
https://github.com/odoo/odoo/blob/89e5038c224d58a2f6be8f3001fd0a2932733cbc/addons/stock/models/stock_scrap.py#L156-L158

In the ```stock_account``` module, ```_action_done``` is overridden to handle inventory valuation and update the standard price.

For products using the FIFO costing method, the move value (for move out) must be calculated before the move is processed to ensure the correct cost are considered. The sequence in ```stock_account/models/stock_move.py``` is as follows:

The move out value is calculated before processing it, to have the correct value in fifo case:
https://github.com/odoo/odoo/blob/e43f6040a6aa9e8f8c10d720a760f9c92606eab5/addons/stock_account/models/stock_move.py#L165-L166
https://github.com/odoo/odoo/blob/e43f6040a6aa9e8f8c10d720a760f9c92606eab5/addons/stock_account/models/stock_move.py#L307
The move is executed:
https://github.com/odoo/odoo/blob/e43f6040a6aa9e8f8c10d720a760f9c92606eab5/addons/stock_account/models/stock_move.py#L167
The product's standard price is updated for the outgoing move
https://github.com/odoo/odoo/blob/e43f6040a6aa9e8f8c10d720a760f9c92606eab5/addons/stock_account/models/stock_move.py#L172

When scrapping a Kit, this logic breaks due to the move being exploted 
- The value calculation and standard price update are mistakenly applied to the Kit move itself, rather than the individual component moves
- During processing, the Kit move is "exploded" into its components (and [unlinked](https://github.com/odoo/odoo/blob/e4d7b400c556344ca0eaab17956efce3ea0ae04e/addons/mrp/models/stock_move.py#L398), because of this when updating the standard price it will raise and error.)

opw-5970674

Forward-Port-Of: odoo/odoo#252049

Before this commit, confirming a Sale Order that creates a Manufacturing Order for a product with a large BoM could take several minutes when `purchase_mrp` was installed.

The slowdown comes from `mrp.bom.line._get_cost_share()`, which is called for every line during a BoM explosion. When no explicit `cost_share` is set, the method recomputes the list of eligible BoM lines and checks whether any of them has a manual cost share.

That computation depends only on the BoM and the product variant, but it is recomputed for every exploded line during `mrp.bom.explode()`. This causes a full BoM scan to be repeated for every single line.

This commit introduces a contextual cache, initialized in `mrp.bom.explode()`, to store that metadata. We compute it once and reuse it for all lines of the same (BoM, variant) within the same explosion.

### Benchmark:

| BoM lines | Before PR | After PR |
| --- | ---: | ---: |
| 100 | 3.747s | 1.094s |
| 300 | 26.554s | 2.826s |
| 600 | 85.378s | 5.299s |
| 992 | 229.246s | 9.068s |

opw-6017626

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

Forward-Port-Of: odoo/odoo#255686
Forward-Port-Of: odoo/odoo#254868

Accrual plan for leave days gets blocked, even when the remaining leave balance is below the cap. As a result, no additional leaves are accrued beyond a certain point, even though they should be.

# Steps to reproduce:
Go to time off app
* Create a new leave type.
* Create a new accrual plan with:
        - one milestone :
		- 2 days accrued per month
		- Cap: 10 days
		- start accruing 1 days after
		- No expiration
		- Carry over: All
* Create and validate a leave allocation 
       - 1 year ago
       - new leave type
       - new accrual plan
* Take the maximum number of leaves available.
* Advance the computer calendar by 1 year.
* Again, take the maximum number of leaves.
* Advance the computer calendar by another year.
* Try to take a future leave.
-> Issue: It’s not possible to take a future leave, the number of accrued days has stopped increasing. The accrual plan appears blocked.

Objective : The accrual plan should continue to allocate leave days even if leaves have been consumed regularly, as long as the remaining leaves are under the cap.

## Issue
Before going further: the property `leaves_taken` of the `hr.leave.allocation` is supposed to contain the number of leaves this allocation cover until "today".

In the `_test_get_allocation_future_leaves1` added test, in the last line of the test :
`assert_virtual_leaves_equal(self, leave_type_day, 2, self.employee_emp, date='2023-02-01')`

When calling `get_allocation_data` with a `target_date` set in the future, the result is wrong. Here is how it works :
`get_allocation_data`
...
.....`_get_consumed_leaves` (1)
...........`_get_future_leaves_on` (2)
...............`_process_accrual_plans` (3)
....................`_compute_leaves` (4)
.........................`_get_consumed_leaves` (5)
..............................`get_future_leaves_on` (6)
...................................`process_accrual_plans` (7)

**A)** The method **(2)** try to calculate the added number of days each allocation will have on `target_date`. So it creates a copy of the allocation in memory using the 'new' method:
`fake_allocation = self.env['hr.leave.allocation'].with_context(default_date_from=accrual_date).new(origin=self)`
It will then update it to `target_date` using `_process_accrual_plans` and will return the difference of days between the
updated `fake_allocation` and the current allocation (`self`)

**B)** Before iterating over each accrual date, the `_process_accrual_plans` **(3)** will get the `leaves_taken` property which is a computed field. It will trigger `_compute_leaves`.

**C)** The method **(4)** will call `_get_consumed_leaves`, and so the nightmare begins.

**D)** The method **(6)** will create a second `fake_allocation` based on the origin of the first `fake_allocation` (see **A)**).

**E)** This time, `_process_accrual_plans` **(7)** will also look at the `leaves_taken`, but won't trigger the `_compute_leaves` probably because the current allocation is a `fake_allocation` of a `fake_allocation`, and one property of the `new` method is that `Two new records with the same origin record are considered equal.`. Therefore, the `leaves_taken` is considered to be already computed (but it's not).

So `_process_accrual_plans` read the `leaves_taken` which is 0 (probably the default value of `leaves_taken`), but it should be 20 !

**F)** As the value of `leaves_taken` is wrong, the fake_allocation n°2 is also wrong, and its `number_of_day` is 10 but the `number_of_days` of the origin allocation is 20. So `get_future_leaves_on` **(6)** will return -10 which makes no sense, and all the previous calls computations will be wrong. And the final `virtual_remaining_leaves` value will be 0 instead of 2.

## Source of the issue
In the `_process_accrual_plans` method, for each allocation, `leaves_taken` is only computed once at the start of the loop over the allocation "important" dates (see `nextcall` property of `hr.leave.allocation`). At this moment, the method calculates the `leaves_taken` the allocation will have on the `accrual_date` parameter. Yet, this property can change depending on the date the allocation is on (`nextcall` property) which leads to some issues in the computation of the `allocation.number_of_days`.

## Solution
For each allocation, compute the `leaves_taken` at every iteration trough the values of `nextcall`. BUT, this can trigger an infinite loop as computing `leaves_taken` calls `_get_consumed_leaves` which calls `_get_future_leaves_on`, which calls `_process_accrual_plans` ... To avoid this, this PR add the context variable `precomputed_allocations` (will be converted into a function parameter in master) which will prevent `_get_consumed_leaves` from calling `_get_future_leaves_on` for the allocations already up to date (contained by this very `precomputed_allocations` context variable).

## Second Issue
    
The accrual plan allocation engine (method `hr.leave.allocation._process_accual_plans`) is still using the `hr.work.entry.type.request_unit` field instead of the `unit_of_measure`. This PR changes that and adds the test `test_work_entry_unit_of_measure_hour` to ensure accrual plans granted days are computed correctly when using a work entry type with `unit_of_measure` set to 'hour' and `request_unit` set to 'day'.

opw-4934391
opw-5226806

Forward-Port-Of: odoo/odoo#239836

Forward-Port-Of: odoo/odoo#250998
Forward-Port-Of: odoo/odoo#243812

Issue:
------------------------------------------------
When a Manufacturing Order is created via an MTO flow from a Sales Order,
the Forecast Report was displaying the Sales Order in the "Available" section
instead of the Manufacturing Order.

Steps to Reproduce:
------------------------------------------------
1. Install `sale_mrp` and `sale_management`.
2. Create a storable product with BOM and MTO route
3. Confirm a Sales Order for the product
4. Open the Forecast Report
5. Observe incorrect reference in "Available" section

Cause:
------------------------------------------------
Before v19.0, finished moves of an MO created via MTO did not carry a
`sale_line_id`, but now it will propagate to the MO finished moves.
Because `_get_source_document()` is overridden in multiple modules,
the `sale_stock` implementation now matches first and returns the
Sales Order, preventing the MRP logic from returning the Manufacturing Order.

With this commit:
------------------------------------------------
This fix ensures that the Manufacturing Order is shown as the
source document providing correct traceability and aligning the behaviour
with the purchase MTO flows.

task-5941986

Forward-Port-Of: odoo/odoo#250121

Since Odoo 18.4, the general logic for the fetchmail Cron Job was
refactored to align it with the new changes to how cron jobs are
handled (i.e. the _commit_progress etc.)
See https://github.com/odoo/odoo/pull/191911

But it certain (legitimate) edge-cases, the current logic might not
handle real-life scenario correctly

Analysis:

When having a high number of legitimate and working fetchmail.server records (>10).
The cron job was repeatably finishing in a "partially done" state,
reporting 0 done progress and retriggering immediately.
Also if there was a notable latency when establishing the IMAP connection,
this had for effect of:

- The cron would process the first few (empty, no new unseen mail) inboxes
 stop break early because of this
 https://github.com/odoo/odoo/blob/4056fa8036ddad11c898cd775b7fa21ba4f8a5de/addons/mail/models/fetchmail.py#L329
 , i.e. if no progess is commited, the cron job handler stops the job
 after 10 secs see https://github.com/odoo/odoo/blob/4056fa8036ddad11c898cd775b7fa21ba4f8a5de/odoo/addons/base/models/ir_cron.py#L495-L498
- Thus the job would stop early in the partially done state, which would
create a cron trigger and relaunch it at the earliest
(usally 1 min later if no other jobs running)
- In the new run, because _fetch_mails always browses the fetchmail.server
 records in the same order, it will check the same inboxes again, and
 because they are empty and there is a connection lag, it would take
 longer than 10 secs again and stop the cron early
 in partially done → rinse and repeat
- In practice in this edge-case we will never check the remaining
fetchmail servers, so unseen emails on those would never be processed →
customer complains that emails are not coming in
- The repeated triggering of the job and it never officially reporting
progress seems to trigger the automatic deactivation on the odoo.sh
platform, further aggravating the situation

Issues with current business logic of the cron:

1) The `total_remaining` variable (tracking the "units" of work to be done)
 does not distinguish between number of servers to be process and the
 number of unseen emails to be processes on the current fetchmail server.
 At the same time it does not commit an explicit progress when finishing
 an outer loop (at the server level) when the inbox was empty
2) The use of `remaining_time` as a circuit-breakers seems like a good
idea at first, but combined with point 1, will terminate the cron early
if checking empty inboxes takes too long and will break the inner loop
(fetching emails) early on subsequent loops of the cron
3) `_fetch_mails` will always return the model records in the same order,
and everything being equal, will not account for that fact if some
fetchmail.server records have been fetched more recently than others

Proposed changes to logic:

1. We add a time buffer to the 'cron_end_time' context value, initialized at the beginning of a job an usually accounting for 10 secs of wall-time per job. We scale the time buffer as 4 * N secs, N being the number of total fetchmail records that need to be checked. This is to ensure that, assuming that all mail inboxes are empty, we have enough time to loop over all of them even if there is "extreme" latency of 2s to connect and 2s to get a response from the mail server.

2. We make the ordering in _fetch_mails "smarter" by  adding a
    custom order argument for more dynamic queuing:
	A) Records with the lowest priority first
	B) Records having the oldest date first, i.e we dynamically penalize
    records that were fetched recently given the date fields get's
    updated every time it fetched/checked a server successfully

3. If a customer still hits the implicit threshold (i.e. it takes longer than 10 + 4 *N s to loop over all current fetchmail servers), the cron will simply rerun at the next recurrence and the custom order should ensure that the backlog get's resorbed. If the time buffer is still not enough in extreme latency scenarios, then users should either fix the root cause (connection latency between the Odoo DB and the mail servers) or opt for an alternative to route the emails to the DB (setting up an MX record and redirecting mails into a mailgate).

OPW-6054244
OPW-6019730

Forward-Port-Of: odoo/odoo#255110

**Description:**
The issue is raised in this pr(v19.2) : https://github.com/odoo/odoo/pull/236971
The compute method used a [`return`](https://github.com/odoo/odoo/pull/236971/changes#diff-4e1a18a369f7dd4de264139227676dd818c06612681c88019f43d238bd8a1490R91) statement when a `if condition` was met. While this works correctly for a single record, it causes issues when multiple records are present.
**For example**, if `self` contains records like `project.project(3, 2, 4)`, and the condition **is satisfied** for the first `record (3)`, the method exits early. As a result, the remaining `records (2 and 4)` are **not** processed.
When the compute method is [triggered](https://github.com/odoo/odoo/blob/8c3043b436f8aae295f247341e3ac427fab05474/odoo/orm/fields.py#L1746) this incomplete computation leads to
missing values for some records and can result in errors.

**Solution:**
To resolve this issue, `return` has been replaced with `continue`. 
This ensures that:
Only the current record is skipped when the condition is satisfied and the loop continues processing the remaining records.

**Traceback:**
```.py

Traceback (most recent call last):
  File "/tmp/tmp2cuqrnuy/migrations/testing.py", line 483, in test_check
    self.check(value)
  File "/tmp/tmp2cuqrnuy/migrations/base/tests/test_mock_crawl.py", line 228,
 in check
    self.assertFalse(diff, msg)
AssertionError: [('project.menu_projects', 391, 'Project > Projects', 593)] is
not
false : At least one menu or view working before upgrade is not working after
upgrade.

('project.menu_projects', 391, 'Project > Projects', 593):
 Traceback (most recent call last):
   File "/tmp/tmp2cuqrnuy/migrations/base/tests/test_mock_crawl.py", line
335, in crawl_menu
    self.mock_action(action_vals)
   File "/tmp/tmp2cuqrnuy/migrations/base/tests/test_mock_crawl.py", line
348, in mock_action
    return self.mock_act_window(action)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/tmp/tmp2cuqrnuy/migrations/base/tests/test_mock_crawl.py", line
508, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
   File "/tmp/tmp2cuqrnuy/migrations/base/tests/test_mock_crawl.py",
line 541, in mock_view_form
    [data] = record.read(fields_list)
             ^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 2735, in read
    return self._read_format(fnames=fields, load=load)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 2991, in
_read_format
    vals[name] = convert(record[name], record, use_display_name)
                         ~~~~~~^^^^^^
   File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 6007, in
__getitem__
    return self._fields[key].__get__(self)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.2/odoo/orm/fields.py", line 1805, in
__get__
raise ValueError(f"Compute method failed to assign {missing_recs}.{self.name}")
ValueError: Compute method failed to assign
project.project(2, 4).stat_timesheet_value
```
opw-6046808



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

Steps to reproduce:
- Enable analytic distribution in Accounting settings
- Create a storable product "P1":
  - Routes: MTO + Buy
  - Vendor: add any supplier
- Create a Sale Order:
  - Add 1 unit of P1
  - Set any analytic distribution
- Confirm the Sale Order

Result:
A Purchase Order is created, but the analytic distribution is not propagated
to the purchase order line.

Problem:
When the Sale Order is confirmed, `_action_launch_stock_rule()` is triggered.
It creates and confirms the corresponding stock move with values from the
sale order line.

Since the product uses the MTO route, the procurement rule is executed.
The rule prepares procurement values from the stock move, but the analytic
distribution is not included in these values:

https://github.com/odoo/odoo/blob/18.0/addons/stock/models/stock_move.py#L1539

Later, `_run_buy` is triggered. It uses the procurement values coming from the
stock move to find an existing purchase order line candidate or to create a
new one. Because the analytic distribution is missing from the values, the
created (or matched) purchase order line does not contain the analytic
distribution:

https://github.com/odoo/odoo/blob/621a93b7b723999d943f1c4da78547763498c008/addons/purchase_stock/models/stock_rule.py#L113

Solution:
Propagate the analytic distribution from the sale order line through the stock
move so it can be included in the procurement values and correctly applied to
the purchase order line.

opw-5936971

Forward-Port-Of: odoo/odoo#255928
Forward-Port-Of: odoo/odoo#252292

Steps to Reproduce

- Create a draft manufacturing order : Desk Combination
- Update bom using ECO
- Add a new Line with Screw with 10 qty
- Apply Changes
- Update BOM in the manufacturing order

-> Record does not exist or has been deleted.

Changing bom_id causes the computes state/move_finished_ids/move_raw_ids & workorder_ids to be triggered.

Since https://github.com/odoo/odoo/pull/195995, raw_material_production_id have ondelete='cascade'
Therefore
https://github.com/odoo/odoo/blob/95c73aa4dd7433f394799fdaaad57a84d750ec5a/addons/mrp/models/mrp_production.py#L828 will unlink the raw moves, see
https://github.com/odoo/odoo/blob/95c73aa4dd7433f394799fdaaad57a84d750ec5a/odoo/orm/fields_relational.py#L980

Due to
https://github.com/odoo/odoo/blob/95c73aa4dd7433f394799fdaaad57a84d750ec5a/addons/mrp/models/mrp_bom.py#L265 unlink cannot be removed, so exists() will do the job.

Also fix unlinking of workorder_ids which causes the same error message in 18.0

issue: 254376

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

Forward-Port-Of: odoo/odoo#255844

When a PDF is received by a journal email alias, a race condition occurs between the notification email process and the OCR (IAP) callback.

The notification email template generates a portal URL. Accessing this URL triggers a lazy-generation of the 'access_token' on the account.move record. If the OCR callback (which is asynchronous) updates the same record while the main thread is busy communicating with the SMTP server, the main thread fails with a SerializationError (Concurrent Update) when it finally tries to commit the new token.

This results in a "bouncing email" error for the user, even though the invoice was created and the OCR worked correctly.

This commit forces the generation and flush of the 'access_token' immediately before the notification process begins. By ensuring the write happens early and is flushed to the DB, we avoid a conflicting lazy-write during the post-SMTP commit phase.

Traceback example (simplified):
```
# Thread A (Alias) starts parsing
INFO: iap jsonrpc .../invoice/2/parse
# Thread B (OCR Callback) finishes and updates the record
 INFO: POST /account_invoice_extract/request_done/... HTTP/1.0" 200 
# Thread A finishes SMTP and tries to flush the lazy-generated access_token 
ERROR: bad query: UPDATE "account_move" SET "access_token" = ... 
ERROR: could not serialize access due to concurrent update psycopg2.errors.SerializationFailure: could not serialize access due to concurrent update
```

OPW-5887922

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

Forward-Port-Of: odoo/odoo#251781