Currently, On removing a product name and its description from the account move line causing an error.

Steps to Reproduce:
- Install Invoicing app
- Navigate to Invoicing>Customers>Invoices
- Create New Invoice and add a product.
- Now remove only product name and its description from the account move line(Invoice Line)
- click anywhere on the screen.

Error:
`KeyError: 'name'`

Root Cause:
since [this commit](https://github.com/odoo/odoo/commit/7e553d25890d1e236123f0fa7e11ce86f59448ab),
the method `updateLabel` was removed from the [product_label_section_and_note_field](https://github.com/odoo/odoo/blob/547167ca3ed2ee727ce81c18afaae8aee7a436b4/addons/account/static/src/components/product_label_section_and_note_field/product_label_section_and_note_field.js) component
Now, when a user removes the product's description from the invoice line, the
`updateLabel` method at [1] is called. In this scenario the value of
`[this.descriptionColumn]: value || this.productName` looks like
`name= '' || undefined` since this is a falsy condition JS assigns
undefined as the value of `name` which is recieved by the onchange
method causing an error

[1]- https://github.com/odoo/odoo/blob/c04bcaac02b97583f06265e98be8a721538830f6/addons/product/static/src/product_name_and_description/product_name_and_description.js#L131-L135

Solution:
This commit prevents the error by ensuring `undefined` value is not
sent to the server.

sentry-6327760196

Steps to reproduce:
1. Enable the cookie bar.
2. Edit the cookie bar to have a link/button at the center.
3. Go to /shop.
4. Click the "compare" button on one product.
5. Scroll down and click "compare" on another product.

Issue 1:
Product animation goes to the top-left corner.

Issue 2:
After accepting the cookie bar, the compare button appears but overlaps with the popover.

Reason:
To cover bottom fixed elements when any modal is open, we added the `o_bottom_fixed_element_hidden` class with the `d-none` property to hide those elements, making them visible once the modal closes. As a result, the compare button hides when scrolled, leading it to redirect to the top-left corner. Additionally, adding a product triggers the applyStyles function of popper.js to handle popover styles. When the cookie bar is accepted and the modal closes, this method doesn't trigger until scroll.

This PR aims to resolve animation of product comparision when modal is open by remove the `o_bottom_fixed_element_hidden` class when added to compare products. Additionally, we add debounce leading and trailing params to the `_hideBottomFixedElements` to call function accordingly.

task-3877807

Forward-Port-Of: odoo/odoo#214776
Forward-Port-Of: odoo/odoo#182874

Currently, with an MTSO rule, the smart button from the Sale Order
to the Manufacturing Order was available. However, the reverse link
(from the MO to the SO) was missing.

But they share the same link between object and people don't
understand. So we copy the condition to have the same SO<->MO
link.

It was missing the sale_id on the procurement group itself. Before
production.procurement_group_id.move_dest_ids.group_id.sale_id
was enough since mtso share move links but with the new MTSO it's
not the case anymore. But the sale_id is copied from a procurement
to the new ones.

Steps to reproduce:
- Enable multi-step routes in Inventory settings
- Unarchive the MTO route:
    - Select the rule with the production usage
        - Set its supply method to "MTSO"
- Create a storable product “P1”:
    - routes: MTO + Manufacture
- Create and confirm a Sale Order with one unit of P1
- Confirm the SO

Problem:
The smart button from the SO to the MO appears correctly,
but the reverse link from the MO to the SO is missing.

opw-4619136
opw-4557138
opw-4875937
opw-4854581
opw-4887746

Forward-Port-Of: odoo/odoo#217947
Forward-Port-Of: odoo/odoo#204276

Steps to Reproduce : 
- Open the Discord app
- Copy the text written in multiple lines
- Paste it in the Odoo Editor
- Click below any line or empty space
- You will notice that the placeholder "Type '/' for commands" is getting destroyed.

Description of the issue this PR addresses:
- The issue was caused by visually empty `<div>` elements included in pasted content and not converted into baseContainer.
- This regression was introduced in commit [#196481](https://github.com/odoo/odoo/pull/196481/files?diff=split&w=0#diff-1b8ed5b7d66a870806b1e7400a0d6cb9ba8810327824244eca868be9583b7fd9L467-L477), which stopped replacing blacklisted tags like `<div>` with `<p>`. 
- As a result, cleanForPaste no longer strips inline styles from `<div>` elements.

Current behavior before PR:
- Pasted content includes non-visible `<div>` elements.
- These empty blocks occupy space without contributing visual content.
- Inline styles from copied content remain intact.
- `<div>` elements are not replaced with valid block tags.
- Placeholder rendering is broken in these ghost spaces.

Desired behavior after PR is merged:
- Non-empty `<div>` elements are replaced with a baseContainer element.
- Empty `<div>` elements are automatically removed from pasted content.
- This restores the expected cleaning behavior, removes unwanted styles, and preserves line breaks.

task-4805536

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

Forward-Port-Of: odoo/odoo#210797

### Steps to reproduce:
- In the settings enable by-products
- Create a product FP with a bill of material:
	- 1 operation: op 1
	- 1 By-product line: cost share 3.3%, produced in op 1
- Create aand confirm an MO for 1 unit of FP
- On the by product line produce 10 instead of 1
- Produce All
#### > 19 units of by products were produced: The initial by-product move was validated for 10 units and an extra move with a quantity of 9 was automatically created and validated aswell.

### Cause of the issue:

Since the quantity of the by-product move exceed its initial demand, its validation will create an extra move that is expected to be merge into the main move during its confirmation:
https://github.com/odoo/odoo/blob/474ac02d03c17af0274422ecb1e97ca14a3e80e7/addons/stock/models/stock_move.py#L1922 https://github.com/odoo/odoo/blob/474ac02d03c17af0274422ecb1e97ca14a3e80e7/addons/stock/models/stock_move.py#L1844-L1865 However, while `cost_share` value of the original move floats is correctly encoded as 3.3, the copied value of the extra is 3.3000000000000003. This discrepency is a well known issue of the way the orm handles float and convert them to cache as it calls the `float_round` method, which can effectively change its value: https://github.com/odoo/odoo/blob/8c22e358840f02c5b1596e1fbe0d6cf7315754f7/odoo/fields.py#L1553-L1557 In particular, the `cost_share` of both moves differs in terms of strict equality and the move will not be merged with its extra move.

### Note:

The issue should not be reproducible in saas17.4+ because the float_round issues have been erased by
commit 784f1511acc4352905a61f9bd90aecb78e8558ec

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

Forward-Port-Of: odoo/odoo#217806
Forward-Port-Of: odoo/odoo#215372

### 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#215848
Forward-Port-Of: odoo/odoo#212885

…ith manual confirmation

**Steps to reproduce:**
- Install Appointement app
- Edit an appointement appointment type
- Set manual confirmation for the appointement type
- Add CC contact as well
- Go to the appointement website (/appointement)
- Create an appointement and submit it
- Nothing is sent to CC contact when the request is made

**Issue:**
Process was designed to only send notification mails to the CC contacts (`message_partner_ids`) when the request was approved or cancelled (`booked` or `cancelled` appointment_status) but not for `request` when using manual confirmation.

This is also quite problematic if `Availability on` is set to resources, as no confirmation mail is sent to anyone in that case (when no CC is specified, there is no other user than the requester).

The observed behavior is due to the new process used when making appointement, previously in 17.0 the state was directly set to 'booked' so the mail was directly created and no further mail was sent unless the user explicitly cancelled its appointment.

**Fix:**
Added 'request' to the filtering on 'appointment_status' when adding the mail templates. Adapted field description and mail templates for clarity.

related:
cc field description https://github.com/odoo/enterprise/commit/adf47c32ee190dbf98c266d0816c8d03c8cd3e4f 
appointment_status https://github.com/odoo/enterprise/commit/3c64aa6dcd191248f0806c0b84ffa416d455fde4 
request template https://github.com/odoo/enterprise/commit/2316947a0251709f3e469fea996ffac8f4623d98

opw-4658521

Forward-Port-Of: odoo/enterprise#88042
Forward-Port-Of: odoo/enterprise#86710

Before this commit
------------------
if a user had a multi-company setup with a different alias domain set for each company, a multi-company error could happen. It happens when sending a mail with attachment to an accounting journal alias.
The exact conditions required to enable the option to centralise all attachments in Documents for the journal in question.

steps to reproduce:
1. clean DB with documents_account installed
2. create a 2nd company "company 2"
3. create an alias domain for company 1 "alias.company1.com" and another alias domain for company 2 "alias.company2.com"
4. in documents, create a "finance" folder for company 1 (i.e. set the company_id field on the folder) and another folder for company 2
5. configure the settings for both companies so that all attachments are centralized in documents for accounting, in the respective folder for that company
6. create an alias for some journals in company 2 (e.g. vendor-bills@alias.company2.com)
7. send an email with attachment to that alias -> you will get a multi-company error

After this commit
------------------
Sending a mail with attachment to an accounting journal alias creates the account_move as expected. The attachment is parsed as expected.

opw-4727873
opw-4655559
opw-4746321
opw-4766895

Forward-Port-Of: odoo/enterprise#89411
Forward-Port-Of: odoo/enterprise#84997

### Issue:

When processing a picking form the barcode, uncompleted lines refering to a product are not updated by scanning a different packaging.

### Steps to reproduce:
- In the settings enable "Units of Measure & Packagings"
- Create a product using the base Unit as uom and allowing pack of 6 aspackaging (optional)
- Inventory > Configuration > Product > Units & Pacakagings
- Click on pack of 6 > Packaging Barcodes > New
- Create a new one for your product
- Create and confirma  receipt for 6 units of your product
- Go to the barcode app and scan a pack of 6

#### > A new line 1 pack of 6 was created rather than updating the already existing one.

### Cause of the issue:

When the packaging is scanned, we will call the `findLine` of the `BarcodeModel` in order to determine if there is already an existing line that could absorb the scanned qty. However, this call currently requires the uom of the barcodeData to coincide either with the line uom or its referred packaging to be a valid candidate: https://github.com/odoo/enterprise/blob/fb405cee9b183d697e3cf0e33bb49371b87cb1ac/stock_barcode/static/src/models/barcode_model.js#L1748-L1753

### Note:

This additional check was added in a9a20f8ec5a7883a08eb4bea15dbf3c4cc97caac when the uom and packagings were refactored and merged together. However, it is really unecessary since the system can handle different uoms via these lines:
https://github.com/odoo/enterprise/blob/fb405cee9b183d697e3cf0e33bb49371b87cb1ac/stock_barcode/static/src/models/barcode_model.js#L1450-L1466

### opw-4866981

Forward-Port-Of: odoo/enterprise#89453
Forward-Port-Of: odoo/enterprise#88494

### 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#88525
Forward-Port-Of: odoo/enterprise#86905