**Description of the issue/feature this PR addresses:**
----------------------------------------------
The meeting chat UI exposed a generic three-dot (more actions) menu that
grouped actions which are not relevant in the context of short-term,
in-call conversations. At the same time, member management and invitation
actions were split across different entry points, and pinned messages were
only accessible through a separate panel, reducing their visibility during
a call.
Additionally, the chat panel title did not clearly reflect that the
conversation was happening in the context of an ongoing meeting.

**Current behavior before PR:**
----------------------------------------------
- The meeting chat displayed a three-dot (more actions) menu with actions that are not relevant during in-call conversations
- Member listing and invitation actions were exposed through a dedicated Invite button, separate from the members view
- Pinned messages were accessible via a separate panel instead of being visible directly in the chat message flow
- The chat panel title was displayed as “Chat”, regardless of the in-call context

**Desired behavior after PR is merged:**
----------------------------------------------
- The three-dot (more actions) menu is removed from the meeting chat, simplifying available actions and reducing visual noise during calls
- The Invite button is replaced by a unified Members button, allowing users to view current members and invite new participants from the same interface
- Pinned messages are integrated directly into the chat message flow, making them immediately visible alongside regular messages during a meeting
- The chat panel title is updated from “Chat” to “In-Call Messages” to better reflect its purpose in the meeting context

Together, these changes streamline the meeting chat experience, focus the UI on actions relevant during a call, and improve visibility of both pinned messages and participant management.

Task-5382645

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

**Steps to reproduce:**
* Install  `stock` module.
* Go to the > Settings*, enable *Packages* and
  *Storage Locations*(warehouse).
* Create a storable product and set *Tracking Inventory* to
  **By Quantity** and set some *barcode*
* Update the on-hand quantity for the product and assign it to one packages.
* Open *Barcode > Operations > Internal Transfer* and create a new
  transfer.
* Click the *gear icon* in the top-right corner to open the barcode
  scanning flow.
* manually enter the created product barcode and apply it.
* Click the **Back** button multiple times in quick succession.
* Go to the backend and open the created internal transfer.

**Observed behavior:**
* The internal transfer is created with *double quantities*
 compared to what was added in the barcode interface.

**Cause:**
* When clicking the *Back* button, the following flow is triggered:
  `exit()` → `beforeQuit()` → `save()`.
https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/components/main.js#L406-L414

https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L473-L475

https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_picking_model.js#L828-L832

https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L477-L483
* If the button is clicked multiple times rapidly, `exit()` is called
  again before the previous `save()` RPC completes.
* This results in multiple `save()` calls being executed, causing
  duplicated quantities on the picking.

reference - https://github.com/odoo/enterprise/pull/103999/changes/b791239c154deb6a25f85d65ebc72e3ac53b6c74

**Fix:**

 * Prevent rapidly clicking the Back button multiple times
 does not multiply quantities.

---
opw-5375899

Forward-Port-Of: odoo/enterprise#109013
Forward-Port-Of: odoo/enterprise#103130

**Steps to reproduce:**
- Create a combo, set the free and max to 3
- Create the product combo and set it's price to 50
- Go to PoS, order said combo and chose the same product 3 times
- The price is 49.98 instead of 50

**Problem:**
When ordering a combo and taking the same product multiple times, the method to adjust the price does not work as it should. In this case, the method would subtract too much from the total, leading it to be only 49.98 instead of 50.

**Why the fix:**
This happens because when ordering a combo, each line will get it's price_unit from the combo's price divided by the number of lines.
In the case where we have 3 different products, hence 3 different lines, the first two would have a unit_price of 16.67 and the last line will be adjusted as to make it equal to the combo's price, so the last line would be 16.66, making the sum 50. But in the case where there is only one line, the last line is still adjusted, making all the lines 16.66, introducing this error. 

The solution would be to take the line's qty into account when computing how much we should subtract.
Unfortunalty, doing so will, in some cases, introduce a rounding error. If the new unit_price does not round up well (like in this case where it is 16.666668 before rounding and 16.67 after), the rounding will cause a difference between what's shown in the frontend and what's written on the lines in the backend, as the lines are rounded up again before being saved to the backend.

The introduced solution is to split the lines, and each have a quantity of 1. With this solution, we can have a different price_unit for each line, which resolves our problem, as the first two lines will have 16.67 and the last one will have 16.66 as price_unit. 
This is how it was done up until version 18.0, showing every line with a quantity of 1 instead of grouping them.
As the grouped lines are now single, some rounding with taxes might differ from what it was before, which is why a test was altered.

opw-4931215

Forward-Port-Of: odoo/odoo#247995
Forward-Port-Of: odoo/odoo#221189

This pr restores the previous behaviour of the dimona and part-time activities creation when the cron is ran or when a version or employee is updated.

The original bug was:
create an instance on saas-18.4 with l10n_be_hr_payroll settings > company > my company > update infos > country: Belgium
employee > new > payroll > contract > start_date: any date (this should create a first dimona activity)
settings > technical > automation > scheduled actions > "HR Employee: Update Current Version" > run manually

`_trigger_l10n_be_next_activities` in `hr.version` of `l10n_be_hr_payroll` is duplicating Dimona activities on records that already have one.

We check if a dimona activity already exists for a given `hr.employee` before creating the new activity. Same is done for dimona declaration of part times. The activity now redirects to the employee form (instead of the version form) and appears in it.

[tasks-5134380](https://www.odoo.com/odoo/project/1251/tasks/5134380)

Forward-Port-Of: odoo/enterprise#109605
Forward-Port-Of: odoo/enterprise#96423

## Short functional explanation of the error
When a candidate is refused, an email isn't sent to their email address.

## Reproduction Steps
1. Open Mailhog in a separate tab.
2. Go to the Recruitment app and select any job position.
3. Click on new to create a new application. Enter an applicant name and an applicant email.
4. Check Mailhog: a job application has been sent to the applicant.
5. Go back on the Recruitment app and click on Refuse. In the wizard, make sure you toggle Send Email and click on Refuse.

### Expected behavior
In Mailhog, a refusal mail has been sent to the applicant.

### Unexpected behavior
Nothing is sent.

## Origin of the issue
When refusing a candidate, we create a notification in the chatter but an email isn't sent. This is due to the `incoming_email_to` field, which is checked here:

https://github.com/odoo/odoo/blob/bfc1c210eca65de1116aa09cdd62749ed9192407/addons/mail/models/mail_thread.py#L4040-L4053

but because this field is already retrieved here:
https://github.com/odoo/odoo/blob/bfc1c210eca65de1116aa09cdd62749ed9192407/addons/mail/models/mail_thread.py#L4025 the last condition will always be true, preventing the recipient's data to be added to the message, thus preventing the message to be sent correctly.

Note: as of 19.0, the field `outgoing_email_to` can be used to determine the recipient's email address.
Note: we remove `'body_is_html': True` because this field
is misused in this case: when set at true, the field is always
considered as HTML
__
opw-5980079

Forward-Port-Of: odoo/odoo#252036

When the "pre fill lot/serial numbers in shopfloor" setting is enabled on the manufacturing operation type, by-products tracked by serial number were incorrectly showing extra empty lines in shopfloor MO cards (both in overview and work center views).

Steps to reproduce:
1. Create a bill of materials for a final product
2. Add a consumable component
3. Create an operation without steps
4. Add a by-product tracked by serial number
5. Specify that the by-product is produced in the operation above
6. In Inventory > Configuration > Operations Types, open the Manufacturing operation type, go to the Traceability section and enable "Pre fill lot/serial numbers in shop floor moves"
7. Create a manufacturing order for the BOM and confirm it
8. Open the Shop Floor view from the MO
9. Observe the extra line for the by-product in both overview and work center views

Root cause:
The visibleMoveLines getter in stock_move.js was showing ALL move lines (including unpicked ones) when picking_type_prefill_shop_floor_lots was enabled, without distinguishing between raw materials/components and by-products. By-products should never show pre-filled lines since users must register them manually by clicking the + button.

Solution:
Modified the visibleMoveLines getter to always filter by-products to show only picked move lines, regardless of the prefill_shop_floor_lots setting. This ensures by-products only display lines that have been explicitly registered by the user, while regular components continue to show pre-filled lines when the setting is enabled.

Task-5431295

Forward-Port-Of: odoo/enterprise#109689
Forward-Port-Of: odoo/enterprise#103260

Steps to reproduce the issue:
- Create a storable product P1 with the following BoM:
    - A component consumed in an operation.

- Create a MO to produce one unit of P1 and confirm it.
- Modify the BoM so that the component is no longer consumed in the operation.
- Update the BoM on the MO.
- Start and finish the operation.

Problem:
The MO cannot be closed because the component is not consumed.

The `manual_consumption` field on the stock move is set to True when the move is linked to a BoM line consumed in an operation. However, when the BoM is modified so that the component is no longer consumed in the operation, this field should be updated to False when the MO is updated from the BoM.

https://github.com/odoo/odoo/blob/1305c7262fff762c00159377a9ce1ca09d423625/addons/mrp/models/mrp_production.py#L1193

https://github.com/odoo/odoo/blob/1305c7262fff762c00159377a9ce1ca09d423625/addons/mrp/models/stock_move.py#L611-L612

opw-5993652

Forward-Port-Of: odoo/odoo#251796

Bug introduced by: 341928ca477843d92bf7a084f738cf9dcfd3593a

Steps to reproduce:
- Create a storable product “C1”
  - Cost: $1
- Create a storable product “P1”
  - Type: Kit
  - Category: AVCO
  - BoM:
    - Component: C1 (qty: 20)

- Create a sale order for 1 unit of P1
- Confirm the SO
- Validate the delivery
- Create and post the invoice
- Check the journal items

Problem:
The total COGS posted is $400 instead of $200.

When posting the invoice, `_get_cogs_value` is triggered. It retrieves the price unit of each component based on the stock move quantity of the sale order:

https://github.com/odoo/odoo/blob/963bdc5d8a7cc7d3235a52ac2a2282d95a0da400/addons/sale_mrp/models/account_move.py#L39

However, since commit: https://github.com/odoo/odoo/commit/341928ca477843d92bf7a084f738cf9dcfd3593a#diff-bb93bc1c1d7fd07978c5081adc6dc21dc3eb4c37b5e8f44342fe34b61ee060b5R44

, `_get_price_unit` returns the total cost of the component required to produce one kit (i.e., 20 units * $1 = $20).

Later, `_get_cogs_value` multiplies this value again by the component quantity defined in the BoM (20), resulting in a double multiplication: (20 units * $1) * 20 = $400

opw-5946749

Forward-Port-Of: odoo/odoo#251509

**Steps to reproduce:**
- Go to mass_mailing app
- Add Columns block with multiple content size
- Increase Round Corners (e.g. 20 px)
- In "Vert. Alignment" field > Select the "Stretch to Equal Height" option
- Add color background for the columns
- Save the record and send test mail
- Round corners are not applied
- Background color doesn't expand to the bottom of the body

**Issue:**
Default table style used for the inline conversion of 
`await toInline($(editableClone), { $iframe: $(iframe), wysiwyg: this.wysiwyg });` in `mass_mailing_html_field`,
has its 'border-collapse' attribute set to 'collapse' by default in `enforceTablesResponsivity`.

This attribute doesn't work with `border-radius` and the resulting display differs from the preview of the editor.

Relevant links:
https://stackoverflow.com/questions/628301/the-border-radius-property-and-border-collapsecollapse-dont-mix-how-can-i-use https://stackoverflow.com/questions/36035461/what-is-the-difference-between-border-collapse-collapse-and-border-spacing-0

**Fix:**
Use `'border-collapse': 'separate'` and `'border-spacing': 0` but this can
introduce border stacking inside the table element where the original collapse
was needed.

Add back the `overflow` inherited by the card attributes to ensure
inside border are visually properly contained inside the border (but not
sure as to why it was removed 4 years ago).

Also set the height of table sub-elements to `100%` to ensure background
property is properly applied on the whole card body.

opw-5218581

Forward-Port-Of: odoo/odoo#251863
Forward-Port-Of: odoo/odoo#242001