Issue
-----
Reports printed using the DIN5008 layout but not the paper format have a big empty vertical band. The issue was reported for Return Slips but is common to all external documents.

![image](https://github.com/user-attachments/assets/c3311fc1-1e7f-4d3f-8f9a-6bddb8242dde)

Steps to reproduce
-----
- Go to Settings > Companies > Configure Document Layout
- Set the Layout to DIN 5008
- Set Paper format to A4 (anything except DIN5008)
- Download the PDF Preview

-> The printed pdf has an empty vertical band to the right of the document

Cause
-----
87b067a added a new `din_page_pdf` class that we apply when printing the pdf

https://github.com/odoo/odoo/blob/846c9746a601f52ddb768be4e4c7bfc21d6eeb23/addons/l10n_din5008/report/din5008_report.xml#L37

This forces a specific width to the contents

https://github.com/odoo/odoo/blob/846c9746a601f52ddb768be4e4c7bfc21d6eeb23/addons/l10n_din5008/static/src/scss/report_din5008.scss#L124-L127

This works with the DIN paper format because it applies adequate margins

https://github.com/odoo/odoo/blob/846c9746a601f52ddb768be4e4c7bfc21d6eeb23/addons/l10n_din5008/report/din5008_report.xml#L5-L18

For regular formats, we are better off with the default dynamic behaviour.

Visual comparison
-----
Left is before the fix, right is after the fix.
![image](https://github.com/user-attachments/assets/12d3fa71-bd41-4474-9e03-252902401539)

-----
Ticket:
opw-4660716

Forward-Port-Of: odoo/odoo#213992
Forward-Port-Of: odoo/odoo#211715

**Problem:**
When a kit sale order is created with a package for the kit
product, inside the delivery for the component of the BOM
the package is the package of the kit product

**Steps to reproduce:**
- Inside Settings/Sales activate the "Product Packagings"
setting
- Create a new product (the final product)
- Inside the inventory tab add a packaging line for a pack of
9 units
- Create a new product (the comp product)
- In the general information tab, set a unit of mesure of g
- In the inventory tab add a packaging line for a pack of
0.9 g
- Set an on hand quantity for the comp product
- Create a new BOM for the final product
- Add a a line with the comp product for a quantity of 0.1 g
- Select kit
- Create a new quotation and select your kit product
- Select your packaging > Confirm
- Click on the delivery smart button
- In the operations tab change the packaging of the stock move
to the packaging of the comp
- validate and print

**Current behavior:**
An error message appears

**Cause of the issue:**

When _compute_packaging_qtys calls _compute_qty (the method of the
product.packaging model):
bom_id.product_uom_qty is the uom of the final product (here: Units)
but line['packaging'] is the packaging of the comp that
we set manually on the stock move
https://github.com/odoo/odoo/blob/8244b0bcdb470ff6eb95e2613903fb9175f2c435/addons/mrp/models/stock_move.py#L116
So inside _compute_qty, when _compute_qty (the method of the uom.uom model)
is called, qty_uom is Units and self.product_uom_id is g
https://github.com/odoo/odoo/blob/8244b0bcdb470ff6eb95e2613903fb9175f2c435/addons/product/models/product_packaging.py#L79
which triggers an error inside _compute_qty
https://github.com/odoo/odoo/blob/8244b0bcdb470ff6eb95e2613903fb9175f2c435/addons/uom/models/uom_uom.py#L223-L227

opw-4781180

Forward-Port-Of: odoo/odoo#213353
Forward-Port-Of: odoo/odoo#210540

Previously, when multiple form snippets were added to the same page,
corresponding fields (e.g., the "Name" field) in each form were assigned
the same ID.

This happened because we retrieved the form fields from the
`FormEditorRegistry`.
For the first form snippet, field IDs are generated and assigned
correctly. However, assigning IDs to the fields also updated the fields
stored in the `FormEditorRegistry`.
So when a second form snippet is added, the fields it receives from the
registry already have an ID.
The ID generation logic skips fields that already have an ID, so the
fields in subsequent forms never got new IDs.

With this fix, we now create a shallow copy of each field before using
it. This prevents the original field definitions in the
`FormEditorRegistry` from being modified.

As a result, fields in different forms now receive unique IDs without
needing to explicitly delete the field ID to force a new one to be
generated.

[task-4251881](https://www.odoo.com/web#id=4251881&cids=1&menu_id=4720&action=333&active_id=1695&model=project.task&view_type=form)

Forward-Port-Of: odoo/odoo#214954
Forward-Port-Of: odoo/odoo#183883

### Steps to reproduce:

- Create a product P with a bom with an operation in the Assembly line
- Create and confirm an MO for 1 unit of P
- Open Shop Floor, Mark the operation as Done
- Click on the All MO tab
> The operation was removed from the Assembly line
- Click on "close production"
#### > Nothing happends while the MO should be marked as done and disappear

### Cause of the issue:

The issue has been introduced by commit [1].
To be more precise, clicking on the "Close production" button will launch a call of the `validate`. In case of `mrp.production` records, this call will first launch a call of the `pre_button_mark_done` and then (prior to the change) add the record to the validation Stack for real Validation:
https://github.com/odoo/enterprise/pull/79918/commits/10ed12241365942914885dff953049303b9ed94f#diff-7695d0af56f8efc3200fc5a693b797de9314165f4754bb2054d25809381c0ccdL504 https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L521-L530 
Prior to commit [1], in our use case, the `pre_button_mark_done` would simply return `True` as no action need to be proceed prior to the `button_mark_done` and the porduction would be added and closed by the real validation. However, since commit [1], the record is simply set to the validated state and not added to the validation stack... That satement is simply incorrect:
https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L503-L505 
In the most general usecase, our mrp record is in `to_close` state and is not expected to be validated by the `pre_button_mark_done` even if this call returns `True``.

What is true however, is that in the exceptional use case treated in [1] where you are in the `always` backorder setting and where you need to create a backorder, the MO will be entirely processed by the `pre_button_mark_done`:
https://github.com/odoo/odoo/blob/6542b0a5a58324f532a4ae1e0c630ca4fe2f77d7/addons/mrp/models/mrp_production.py#L2142-L2145 
and hence should not be marked as done once more (otherwise it would raise multiple errors such as sn uniqueness,... (as the mo has already been validated)).

### Fix:

The double validation did not happen prior ot the change of [1] because we did not skip redirection at the time:
https://github.com/odoo/enterprise/commit/154eec919faac0725b90b830adf499df375e8e81 https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L497-L502 
returning the record before even adding it to the real validation stack. However, since we do not want to be redirected to the back end we propose to return the information that the record has been validated by the `pre_button_mark_done` and avoid the call of the real validation using the mechanism already in place:
https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L521-L524

Commit [1]: 10ed12241365942914885dff953049303b9ed94f

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

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

Forward-Port-Of: odoo/odoo#214049
Forward-Port-Of: odoo/odoo#212885

…nbuild

**Problem:**
When decreaseing the quantity of the stock move created for the component of the bom when unbuilding, it triggers an error message

**Steps to reproduce:**
- create a product tracked by quantity (the "component product")
- in the category field select an avco category
- set an on hand quantity of 1
- create another product tracked by quantity (the "final product")
- create a bom for this product and select your first product as the component
- create a manufacture order for the final product
- confirm and produce all
- unbuild it and click on the "Unbuilds" smart button
- select the line of the manufacture order
- click on "product moves"
- select the line of the component product
- set the quantity to 0

**Current behavior:**
an error message appears

**Expected behavior:**
a stock valuation layer should be created with
the unit cost of the component product at the
time of the manufacture order

**Cause of the issue:**
price_unit_map is created to make sure that when unbuilding a non standard final product,
the outgoing stock valuation layer created for the final product has the same value as in the MO (the current standard_price could have changed due to POs since the MO happened for instance) https://github.com/odoo/odoo/blob/05cff3b7d866f6bc95c4b32f343ae14a4da946f2/addons/mrp_account/models/stock_move.py#L47-L56

when reducing the quantity of the stock move linked to the component of the unbuild an outgoing stock valuation layer is created and _get_out_svl_vals is triggered,
those 2 conditions are true
https://github.com/odoo/odoo/blob/05cff3b7d866f6bc95c4b32f343ae14a4da946f2/addons/mrp_account/models/stock_move.py#L55-L56 but the product is not the same as the one of move_finished_ids of the MO (this product is final product of the MO) so the filter result in an empty record set and
[0] creates an index out of range error
https://github.com/odoo/odoo/blob/05cff3b7d866f6bc95c4b32f343ae14a4da946f2/addons/mrp_account/models/stock_move.py#L49-L51

**Fix:**
the unit_cost of the stock valuation layer for the component product created from unbuild is the same as :
the unit_cost from the stock valuation layer created from the MO for the component (even if the standard_price changed inbetween).
https://github.com/odoo/odoo/blob/4fd9ae6ccd96ac13475e7e5aa9805e6f529cd609/addons/stock_account/models/stock_move.py#L516-L517
https://github.com/odoo/odoo/blob/4fd9ae6ccd96ac13475e7e5aa9805e6f529cd609/addons/stock_account/models/stock_move.py#L51

So to be consistent an ajustement to the the stock move created from the unbuild should create a stock valuation layer which also has the same unit cost

opw-4747920

Forward-Port-Of: odoo/odoo#211091

### Steps to reproduce:
- On a contact, add the "Factur-X" E-Invoicing method under the "Accounting" tab
- Create an invoice with this contact as the customer
- Send the invoice, download the PDF
- Verify the PDF. For example with https://demo.verapdf.org/
- `The aforementioned EOL marker shall be immediately followed by a % (25h) character followed by at least four bytes, each of whose encoded byte values shall have a decimal value greater than 127`
- `The MIME type of an embedded file, or a subset of a file, shall be specified using the Subtype key of the file specification dictionary. If the MIME type is not known, the "application/octet-stream" shall be used`

### Cause:
- 1
Pypdf 2.2 is [adding the necessary binary](https://github.com/py-pdf/pypdf/commit/036789a4664e3f572292bc7dceec10f08b7dbf62) like Odoo [does](https://github.com/odoo/odoo/blob/c1679123c9c6f7184293befb399de1e79a6205a9/odoo/tools/pdf/__init__.py#L471) for Pypdf2.1 because it is mandatory for PDF/A.

The issue comes from two line break following each others:
Pypdf2.2 adds one at the beginning of the [file](https://github.com/py-pdf/pypdf/blob/036789a4664e3f572292bc7dceec10f08b7dbf62/PyPDF2/pdf.py#L487): 
`\n % E2 E3 CF D3`
Then Odoo [adds the header `%PDF-1.7\n` before](https://github.com/odoo/odoo/blob/c1679123c9c6f7184293befb399de1e79a6205a9/odoo/tools/pdf/__init__.py#L469) resulting in :
`b"%PDF-1.7" \n \n % E2 E3 CF D3`
PDF/A expects to have `% E2 E3 CF D3` on the second line right after the header but there is nothing on this line.

- 2
The Subtype is badly formatted: from `text/xml` to `/text#232Fxml` instead of `/text#2Fxml`

This occurs as Odoo [replace `/` by `#2F`](https://github.com/odoo/odoo/blob/2e43bee546d5c14729d654386209b539d8aa71d7/odoo/tools/pdf/__init__.py#L369-L377).
But then when [adding the subtype](https://github.com/odoo/odoo/blob/2e43bee546d5c14729d654386209b539d8aa71d7/odoo/tools/pdf/__init__.py#L595C17-L595C74) to the attachment, we call `NameObject` from PyPdf. This object will [format](https://github.com/py-pdf/pypdf/blob/1c4173a12cd21b91dff6d6596ed0bbf1999f2d10/PyPDF2/generic/_base.py#L548) the text again replacing the `#` by `#23`. 

### Solution:
- Don't add a `\n` after `%PDF-1.7` when using `_pypdf2_2`.

- As PyPdf2.2 is doing the formatting itself, we don't format on our side if `submod == ._pypdf2_2`. 
We still need to add the `/`.

opw-4748600

Forward-Port-Of: odoo/odoo#211006

Before this commit, discuss call HOOT tests retained the window object after test ended.

Retained memory was about 2.5Mb-4Mb per test.

An earlier PR [1] fixed a similar issue from a `const` object being used in field default value. This was a problem because JS models internal code is keeping a reference to this object, and since HOOT suite test reuses the same window object, the window of each test were retained. The PR [1] fixed the issue by not setting object as default value of the field.

Note that the default value and its presence in internal code of JS models happened for all tests that use `@mail` static files. That means this PR `[1]` fixed a retained memory for all `@mail` and related tests.

While this fixed many tests, we still observed this retained memory on all discuss call tests. This happens because while the default value no longer uses this shared object, the computed value still does. Therefore call tests were sharing the const and thus retaining the window object. Note that the computed method is implicitly lazy, so this is only invoked in code that actually uses this `iceServers` field, hence why only discuss call tests were still affected by the issue.

This commit fixes the issue by replacing the DEFAULT_ICE_SERVERS object by GET_DEFAULT_ICE_SERVERS function. This ensures each test use a different object, thus preventing retaining the window object after test has ended.

[1]: https://github.com/odoo/odoo/pull/204521

Forward-Port-Of: odoo/odoo#215208

**Steps to reproduce:**
- Install account_budget
- Activate "Budget Management" in Accounting settings

- Go to "Accounting / Accounting / Analytic Budget"
- Create a new budget:
  * Budget Type: Expense
  * Period: [this month]
  * Budget Lines: [a line with an analytic account (AA) in 2 plans]
- Open the budget

**Issue 1:**
Create a PO at the current date with a line having only one of the AA as analytic distribution and an amount higher than the budgeted amount.
The PO line and the Budget button appear in red, but it shouldn't because the analytic distribution of the line doesn't match all the accounts defined on the budget line.
The line will not impact the budget, but it appears in red, which is confusing.

**Cause 1:**
When computing the budget lines linked to the PO line, the domain that is used is only taking into account the plans that are set on the PO line, ignoring the plans that are not set.
For the Budget button, all the PO lines are used instead of just those having the correct analytic distribution.

**Issue 2:**
- Create a PO at the current date with 2 lines:
1) a line with the same AA than the budget line and an amount higher than the budget amount
2) a line with the same AA than the budget line and an amount lower than the budget amount
- Save the PO
The first line should be red, but it is not.

**Cause 2:**
When computing the budget lines linked to the PO lines, only the last PO line has its value set.

opw-4757067

Forward-Port-Of: odoo/enterprise#87884

…rrect data from MO operation

**Problem:**
lines of mrp.workcenter.productivity added from 
the workorder widget do not update the linked 
analytic account with the right amount

**Steps to reproduce:**
- enable "analytic accounting" setting
- Unarchive MTO route
- Create a new product
- In the inventory page check MTO and Manufacture routes
- click on the Bill of materials smart button and create 
a new BOM
- add a component and an operation
- Create another product, set "product type" as service
- in the "create on order" field select "project & task"
- create a new quotation with these two products and confirm
- click on the "manufacturing" smart button
- in the work orders page click on the "open work order" 
button at the right of the line
- click on add a line
- set a duration of 30:10 and clik elsewhere on the screen
- save
- click on the "analytic account" smart button
- select the only line and click on the "gross margin" 
smart button

**Current behavior:**
There is a single line with an amount of 0.01

**Expected behavior:**
The price should reflect the hourly rate of the employee
for the task (that's 50.28 with a 100$/hours rate for 
instance)

**Cause of the issue:**
There is two issue here.
First Issue : 
When clicking on save on the widget, this will 
modify the time_ids field of the mrp.workorder
this will create a new mrp.workcenter.productivity
with the values we wrote.
Consequently, on the vals_list when the create method
is triggered duration is set to the duration we wrote 
(so here 30.17)

Because of this, when the _compute_duration is the triggered
previous_durations will be [30.17] and _create_analytic_entry
will be called with a parameter of 30.17
https://github.com/odoo/enterprise/blob/8a21b4f8ee8d24ebbc9ac2eb08696a0de056357f/project_mrp_workorder_account/models/mrp_workcenter_productivity.py#L10-L14

Therefore, inside _create_analytic_entry 
duration will be 0 and amount will also be 0

This issue does not happen if the duration is set by changing
the "real duration" in the "work orders" page of the manufacturing 
order. 
This is because when doing it this way, we modify the duration 
of the mrp.workorder which triggers the set_duration_method
which also creates a new mrp.workcenter.productivity but 
here the _prepare_timeline_vals returns a dictonary without 
a duration field
https://github.com/odoo/odoo/blob/4fe90167266a92c3a5941eac9a6a2084a80056ac/addons/mrp/models/mrp_workorder.py#L352-L353

Second Issue: 
The line we see with a 0.01 amount is actually created 
before we save. 
It's created from the onchange method when we change the 
duration on the form.
The onchange of duration triggers an onchange of start date
which gets the value of duration and triggers of recomputation
of duration 
https://github.com/odoo/odoo/blob/4fe90167266a92c3a5941eac9a6a2084a80056ac/addons/mrp/models/mrp_workcenter.py#L522-L531
As a consequence, _compute_duration is called. 
self.duration is initially not rounded so in our exemple 
previous duration will be equal to 30.1666666666668
https://github.com/odoo/enterprise/blob/8a21b4f8ee8d24ebbc9ac2eb08696a0de056357f/project_mrp_workorder_account/models/mrp_workcenter_productivity.py#L10-L11
However after the call to super()._compute_duration(), self.duration
will be rounded thanks to the use of convert to duration inside 
the super method
https://github.com/odoo/odoo/blob/4fe90167266a92c3a5941eac9a6a2084a80056ac/addons/mrp/models/mrp_workcenter.py#L472

So when doing the difference here inside _create_analytic_entry
https://github.com/odoo/enterprise/blob/8a21b4f8ee8d24ebbc9ac2eb08696a0de056357f/project_mrp_workorder_account/models/mrp_workcenter_productivity.py#L38
duration will be 5.555555555556424e-05 and amount will be 
-0.005555555555556424 which results in the creation of this line 
with an amount of 0.01

**fix:**
Calling the creation of account.analytic.line from the compute method leads to other problems : 
For instance, if a line is added in the "open work order" widget and we change the end date but change our mind and don't save the line, the duration will have been computed and a new account analytic line will have been created

Whereas calling the method _create_analytic_entries from create() and write() ensures it's only called when the model is saved
opw-4715690

Forward-Port-Of: odoo/enterprise#85517

### Steps to reproduce:

- Create a product P with a bom with an operation in the Assembly line
- Create and confirm an MO for 1 unit of P
- Open Shop Floor, Mark the operation as Done
- Click on the All MO tab
> The operation was removed from the Assembly line
- Click on "close production"
#### > Nothing happends while the MO should be marked as done and disappear

### Cause of the issue:

The issue has been introduced by commit [X](10ed12241365942914885dff953049303b9ed94f)
To be more precise, clicking on the "Close production" button will launch a call of the `validate`. In case of `mrp.production` records, this call will first launch a call of the `pre_button_mark_done` and then (prior to the change) add the record to the validation Stack for real Validation:
https://github.com/odoo/enterprise/pull/79918/commits/10ed12241365942914885dff953049303b9ed94f#diff-7695d0af56f8efc3200fc5a693b797de9314165f4754bb2054d25809381c0ccdL504 https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L521-L530 Prior to commit [X](10ed12241365942914885dff953049303b9ed94f), in our use case, the `pre_button_mark_done` would simply return `True` as no action need to be proceed prior to the `button_mark_done` and the porduction would be added and closed by the real validation. However, since commit  [X](10ed12241365942914885dff953049303b9ed94f) the record is simply set to the validated state and not added to the validation stack... That satement is simply incorrect:
https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L503-L505 In the most general usecase, our mrp record is in `to_close` state and is not expected to be validated by the `pre_button_mark_done` even if this call returns `True``.

What is true however, is that in the exceptional use case treated in commit [X](10ed12241365942914885dff953049303b9ed94f) where you are in the `always` backorder setting and where you need to create a backorder, the MO will be entirely processed by the `pre_button_mark_done`:
https://github.com/odoo/odoo/blob/6542b0a5a58324f532a4ae1e0c630ca4fe2f77d7/addons/mrp/models/mrp_production.py#L2142-L2145 and hence should not be marked as done once more (otherwise it would raise multiple errors such as sn uniqueness,... (as the mo has already been validated)).

### Fix:

The double validation did not happen prior ot the change of commit [X](10ed12241365942914885dff953049303b9ed94f) because we did not skip redirection at the time:
https://github.com/odoo/enterprise/commit/154eec919faac0725b90b830adf499df375e8e81 https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L497-L502 returning the record before even adding it to the real validation stack. However, since we do not want to be redirected to the back end we propose to return the information that the record has been validated by the `pre_button_mark_done` and avoid the call of the real validation using the mechanism already in place:
https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L521-L524

Commit  [X](10ed12241365942914885dff953049303b9ed94f): 10ed12241365942914885dff953049303b9ed94f

Community: https://github.com/odoo/odoo/pull/212885

opw-4800147

Forward-Port-Of: odoo/enterprise#87540
Forward-Port-Of: odoo/enterprise#86905