### Issue before the commit:
In the product page of ecommerce app choosing the "boxed" style layout the price per unit was not displayed.

### Steps to reproduce the issue:
- Download website and create one
- Activate "Product reference type" from settings
- Create a product inserting selling price and base unit count
- Go to website with smart button
- Edit and go to "style" tab
- The "purchase style" is not working for "boxed" style

### Cause of the issue:
During the refactoring of the product page templates from version 18.4 to 19.0 (commit 670b1daa2254d7600b54bae675dd673f457aa8fa), in the website_sale.product template, the logic responsible for rendering the unit price information was omitted in the "boxed" layout, whereas it remains correctly implemented in the "default" and "large" views.

### Reason to introduce the fix:
To ensure UI uniformity across all available layout styles and to restore the visibility of critical unit price data for customers.

### Fix details:
Added the base_unit_price in the website_sale.cta_wrapper_boxed layout: 
```
<small t-if="combination_info.get('base_unit_price')"
    class="ms-1 text-muted o_base_unit_price_wrapper d-none">
    <t t-call="website_sale.base_unit_price">
        <t t-set="base_unit_price" t-value="combination_info['base_unit_price']"/>
    </t>
</small>
```
Before the change:
<img width="489" height="373" alt="image" src="https://github.com/user-attachments/assets/1cee4cfc-0109-4647-a925-b183a19cad48" />

After the change:
<img width="471" height="362" alt="image" src="https://github.com/user-attachments/assets/863e98b2-6297-4388-a538-5ee0c1a568fa" />

opw-5920598


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

Forward-Port-Of: odoo/odoo#253071
Forward-Port-Of: odoo/odoo#250319

**Problem:**
If you have group by carrier option in automatic batches, when you create an SO with a stocked product, confirm the order, and in the delivery step you set/change a carrier, it creates a new batch transfer, and it doesn't group it with the appropriate batch with that carrier.

**Steps to reproduce:**
1) In the settings enable: Batch, Wave & Cluster transfers
2) Inventory > Configuration > Warehouse Management > Operation types
3) Enable Auto-batches, Batch grouping by carrier on Delivery orders
4) Make sure there is no batches made before contains the carrier you're going to use (to cleanly test this issue)
5) Make a sales order, add storable product, press on 'Add shipping' button and add 'standard delivery'
6) Go to the delivery of the pick from the smart button > validate it
7) Go to the next transfer to see the batch number
8) Make a new sales order, add storable product > confirm it > go to the delivery step > additional info
9) Add 'standard delivery' in the carrier field > validate the delivery > go to the next transfer button
10) check the batch it got added to, you will find it is a new one and didn't get grouped to the last batch created with the same carrier.

**Expected behaviour:**
It should get grouped in the batch containing that same carrier.

**Cause:**
When the SO is confirmed without a carrier, and then you edit the carrier in the delivery step (pick) then press on validate, it gets the carrier from the vals in the SO (blank), then along the way while validating the pick, `find_auto_batch` gets called with the empty carrier, so it creates a new batch, *AND then* it propagates the carrier from the SO to the pick using `get_new_picking_values` method, but by then it's too late as the batch is already created with the blank carrier.


**Solution:**
The problem happened because of this commit: https://github.com/odoo/odoo/commit/7c32adcd82119c35485addd1b198a7fcc0053c9f
We need to add the propagation of the carrier_id to the vals if it was already changed or set before the validation of the pick.

opw-5882310

Forward-Port-Of: odoo/odoo#248490

revert the commit
as when we fetch archived warehouse's pos type
it will raise error for other source or destination loction for newly created stock operation type like

even functinally also there is no need to fetch
archived warehouse's operation type.
```
quality Control
cross Dock,
Storage type
```
we got this error during upgrade :
```
File "/home/odoo/src/odoo/saas-17.4/odoo/sql_db.py", line 347, in execute
    res = self._obj.execute(query, params)
psycopg2.errors.NotNullViolation: null value in column "default_location_src_id" of relation "stock_picking_type" violates not-null constraint
DETAIL:  Failing row contains (33, 0, 28, 56, null, null, null, 4, null, null, 1, 1, 1, QC, internal, at_confirm, FBAQC, ask, {"en_US": "Quality Control"}, null, f, f, t, null, f, null, 2024-10-16 05:14:53.18448, 2024-10-16 05:14:53.18448, optional, optional, no, optional, null, null, t, null, null, 2x7xprice, 4x12_lots, pdf, null, null, null, null, null, null, null, null, null, t, null).
```

due to this two fix:
https://github.com/odoo/odoo/pull/151719/commits
https://github.com/odoo/odoo/pull/175838/files

so we need to avoid to fetch archived warehouse's picking type.

ref:
odoo/upgrade#6631

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#191652
Forward-Port-Of: odoo/odoo#185244

### Steps to reproduce:

- In the settings enable: Lots & Serial Numbers and Multi-Step routes
- Settings > Technical > Sequences & Identifiers > Sequences
- On the stock.lot.serial sequence enable: `Use subsequences per date_range`, add a range date containing today
- Create a product tracked by Serial numbers
- Create and confirm a receipt for 3 units of your product
- Detailed of the move > Generate Serials/Lots > New > Generate
#### > 3 serial numbers were created but the date specific sequence has only been updated once. This can be checked by creating a new receipt and processing the same exact flow.

### Cause of the issue:

Generating the serial numbers will call the
`action_generate_lot_line_vals`. However, this method is not tailored to deal with the `use_date_range` and increments the main sequence rather than the actual subsequence:
https://github.com/odoo/odoo/blob/441a6d1b928a44b9a760f926180a925159edff3e/addons/stock/models/stock_move.py#L1103-L1106

### Fix:

We rely on the apparently unused `_get_current_sequence` method to recover the appropriate sequence by date range to update: https://github.com/odoo/odoo/blob/441a6d1b928a44b9a760f926180a925159edff3e/odoo/addons/base/models/ir_sequence.py#L114-L128 This method has been introduced in an accounting naming IMP: 915aa9e4db3169a4767617b5310721f0d9c16812 and is unused since the accounting is no more relying on name sequences:
dfd01b8c5c7e1177f37bf199790a0732a61eed78

In addition, we fine tune the current version of the code updating the serial sequence on lot generation since it is currently updating the sequence only if the first generated lot has been set via the`New` button and hence has incremented the sequence via a `next_by_id` call: https://github.com/odoo/odoo/blob/ec9343376597a4bffe9d2fd2f68777fe11b93267/addons/stock/static/src/widgets/lots_dialog.xml#L33 https://github.com/odoo/odoo/blob/ec9343376597a4bffe9d2fd2f68777fe11b93267/addons/stock/static/src/widgets/generate_serial.js#L48-L56 https://github.com/odoo/odoo/blob/ec9343376597a4bffe9d2fd2f68777fe11b93267/odoo/addons/base/models/ir_sequence.py#L261-L275 https://github.com/odoo/odoo/blob/ec9343376597a4bffe9d2fd2f68777fe11b93267/odoo/addons/base/models/ir_sequence.py#L335-L337 https://github.com/odoo/odoo/blob/ec9343376597a4bffe9d2fd2f68777fe11b93267/odoo/addons/base/models/ir_sequence.py#L53-L55 While if the value of first lot is given manually to the wizzard is given manually to the wizzard, the sequence does not get incremented by the nextval.

opw-5931056

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

Forward-Port-Of: odoo/odoo#253618

Problem:
After https://github.com/odoo/odoo/commit/e809b492c1b138c1af7bb1d4aa61b39d87686df9 typing spaces inside an
"Add to cart" button label in the website editor triggers the button
click instead of inserting a space character.

Cause:
Browsers natively intercept the space key on `button[contenteditable="true"]`
elements and fire a click event instead of inserting the character, making it
impossible to type spaces in the button label.

Solution:
Introduce an `EditableButtonPlugin` that moves the `contenteditable`
attribute from the button up to a wrapping `<span>`. This preserves full text
editing capability (including spaces) without triggering the button's click handler.

Steps to reproduce:
* Go to a product page on the website.
* Open the editor.
* Try to add a space in the "Add to cart" button label.
* Observe that the button is triggered instead of inserting a space.

opw-5994828

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

Forward-Port-Of: odoo/odoo#252675

When browsing an eCommerce in any language but English and trying to filter on an attribute with more than 8 values and at most 20, the "View more" and "View less" options are not translated

Steps to reproduce:
1. Install eCommerce
2. Create a product with one attribute that has 9 to 20 values and publish the product to the eCommerce (the attribute should have radio display type and should be visible in the eCommerce)
3. Add a language (e.g. French) and translate the eCommerce's website
4. Open the website and set the language to French
5. In the left column, open the filter for the attribute previously created
6. Click on "Voir plus"
7. "View less" is not translated, if you click on it, "View more" is not translated anymore

Issue:
The translation for "View more" is generated because it is present in the template `filter_radio_and_multi_attributes` but when we update the text in website_sale.js, the terms are not translated anymore

Solution:
Use `_t` to translate the "View more" and "View less" terms

opw-5985712

Forward-Port-Of: odoo/odoo#253684
Forward-Port-Of: odoo/odoo#252828

**Steps to Reproduce:**
- Revert the commit 2ff35d598346798bd00fd40687e0e214c0190c1f.
- Install the Planning module.
- Restore the original commit
- Install 'planning_holidays' module.

**Error:**
```
ParseError: while parsing /home/odoo/src/enterprise/saas-19.2/planning_holidays/views/planning_slot_views.xml:26, somewhere inside <record id="planning_view_kanban_inherit_planning_holidays" model="ir.ui.view">
        <field name="name">planning.slot.kanban</field>
        <field name="model">planning.slot</field>
        <field name="inherit_id" ref="planning.planning_view_kanban_inherit"/>
        <field name="arch" type="xml">
            <xpath expr="//span[@t-if='record.overlap_slot_count.raw_value']" position="after">
                <field name="leave_warning" class="text-danger mb-2"/>
           </xpath>
        </field>
    </record>
```

**Cause:**
The `planning_holidays` module targets a `<span>` element in its XPath, while the `overlap_slot_count` element is located in a `<p>` in the planning module. Since view changes in stable do not update already-installed databases, the old XPath cannot be found, and a ParseError is raised during module installation.

**Fix:**
Revert the changes in stable to restore the original view.

sentry-7338367664

Steps to reproduce:
-------------------------------------
1. Install `hr_appraisal_skills` module
2. Create a new employee and assign at least one skill to the employee
3. Set the Next Appraisal Date to today
4. Go to Scheduled Actions > Appraisal: Run employee appraisal > Run Manually
5. Open the newly created appraisal for the employee

Observation:
-------------------------------------
In the Skills tab, the employee's skills are not populated even though the appraisal is already in the confirmed stage

Issue:
-------------------------------------
When the cron  `_run_employee_appraisal_plans` creates an appraisal, it is created directly in `pending` state via  `create()`. The skill-copying logic only lived in the  `write()` override, which triggers on state transitions from 'new' to 'pending'. Since  `create()` bypasses  `write()`, Employee skills were never copied to cron-created appraisals

https://github.com/odoo/enterprise/blob/451dce92a087086fc3d5d5f610626312f32bcd13/hr_appraisal_skills/models/hr_skills.py#L12-L15

Solution:
-------------------------------------
Add a `create()` override to call `_copy_skills_when_confirmed` when an appraisal is created directly in the `pending` state, ensuring employee skills are properly copied.

opw-5491433

Forward-Port-Of: odoo/enterprise#110601
Forward-Port-Of: odoo/enterprise#107760

**Steps to produce:**
- Install the `Accounting` module.
- Enable analytic accounting in settings.
- Create an analytic account (e.g., "test").
- Create a journal entry and assign the analytic account in the analytic
  distribution.
- Post the entry and export it(Make sure `journal items/account` and
  `journal items/analytic distribution` are also included).
- `Archive` the analytic account.
- Import the exported entry `OR` Duplicate the previous created entry.
- Try to post the imported entry.

**Issue:**
- The entry is posted even if the analytic account used in the analytic distribution is inactive.

**Root cause:**
- The `analytic_distribution` field is stored as JSON.
- At [1], the `_str_to_json` method only attempts `json.loads(value)`, and if parsing fails, it raises an error.

**Solution:**
- Add a validation when posting journal entries to ensure that all analytic accounts referenced in the analytic distribution are active.

[1]: https://github.com/odoo/odoo/blob/13e8b462e74f144e085492857bfaa7b0d1f88f93/odoo/addons/base/models/ir_fields.py#L196-L202

opw-5350980

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

Forward-Port-Of: odoo/odoo#253752
Forward-Port-Of: odoo/odoo#239988

## Issue:
When computing the product tree, the system would use `_bom_find` to find the BoM. However, it's possible to have multiple BoM for the same product, and the user should have chosen which BoM he wants to use. `_bom_find` ignores the user configuration in MPS, and simply select the first (oldest) BoM in the list. This means that the components in the MPS would not be correctly updated.

---

## How to reproduce:


https://github.com/user-attachments/assets/c7e6f4d4-332a-4e2b-a40a-1b831daeb6c8


- Create Products FNS & CMP
- Create BoM for FNS without bom line (V1)
- Create BoM for FNS with CMP in bom lines (V2)
- Add FNS to MPS using bom V2
- Set Forecast Qty of FNS to 10 
- => Indirect Demand Qty for CMP is not shown (because it's 0)

---

## Test Result without fix:
```
2026-03-05 15:00:24,601 52396 INFO oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: Starting TestMpsMps.test_indirect_multiple_boms ... 
2026-03-05 15:00:24,742 52396 INFO oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: ====================================================================== 
2026-03-05 15:00:24,742 52396 ERROR oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: FAIL: TestMpsMps.test_indirect_multiple_boms
Traceback (most recent call last):
  File "/home/odoo/Odoo/src/18.0/enterprise/mrp_mps/tests/test_mrp_mps.py", line 1556, in test_indirect_multiple_boms
    self.assertEqual(forecast_cmp['forecast_ids'][0]['indirect_demand_qty'], 10)
AssertionError: 0.0 != 10
 ```

---

OPW-5979738

Forward-Port-Of: odoo/enterprise#110526
Forward-Port-Of: odoo/enterprise#109693

Commit [1] introduced the country selector on the VoIP keypad, for
saas-19.1. However, for saas-19.2, the auto-focus of the country search
input once the country selector dropdown is opened was broken. This is
because of [2] which trapped the focus inside the softphone to improve
various keyboard behaviors... but the country selector is considered to
be outside of the country selector as it is a dropdown, which broke the
auto-focus.

We now trap the focus inside the country selector once it opens, the
same way [2] traps the focus inside the softphone once it opens. Doing
that, using `useAutofocus` becomes actually useless as the input is
the first focusable element of the dropdown and will thus automatically
be focused when the menu becomes the active element.

Also, the auto-focus introduced by [1] was not working on mobile. This
commit changes that but does not consider that to be a bug so this still
target 19.2+.

Note: a tour already existed and wanted to check that feature works but
it was not properly written. This commit adds a unit test about this
only too, and for the mobile usecase.

[1]: https://github.com/odoo/enterprise/commit/708aea78760392207f9148c31c67212dacaf3294
[2]: https://github.com/odoo/enterprise/commit/df1772e877a508150fd3f549526dec9d867354be

task-5999452

Step to reproduce:
- Install point_of_sale
- Enable Identify Customer on the Card payment method
- Create an order with a customer and refund it
- Use Card as the payment method
- Close the POS session
- Go to Invoicing → Customers → Payments

Observation:
- Two payment records are created
- Both payments have payment_type = inbound
- The refund payment should be outbound

Cause:
- When Identify Customer is enabled, `_create_split_account_payment` is used to create payment records
- The method does not adjust payment_type for refund transactions

Fix:
- Add helpers to swap destination and outstanding accounts
- Set `force_outstanding_account_id` instead of `outstanding_account_id`, as the former has priority
- Ensure refund payments are created as `outbound`

few related fix: https://github.com/odoo/odoo/commit/303a9061da85048f14a3ca7b1e13df0ab34da99e
https://github.com/odoo/odoo/commit/718fac6832ecd343bf26d41fa5ae5b1ab74f4228
https://github.com/odoo/odoo/commit/684415b9ff2e151506da561016dbfa991bfa8dc8

opw-5437456


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

Forward-Port-Of: odoo/odoo#254079
Forward-Port-Of: odoo/odoo#247760

This commit ensures that there is always information linked to a
`res.session` record.
This causes an error, for example, if `user_agent` is `False`:
```py
... = self.__user_agent_parser(device.user_agent)
```

We ensure that if we have a `is_current` `res.session` record which does
not have a `is_current` `res.device`, we have information (`ip_address`,
`user_agent`, `country`, `city`).

Scenario:
- device A detected at time T0: info A in session + new log A
- device B detected at time T1: info B in session + new log B
- log B is unlink (or marked as revoked)
- device B detected at time T2: nothing ==> `web_read` on `res_users` ==> error
T2 < T1 + `DEVICE_ACTIVITY_UPDATE_FREQUENCY`
- device B detected at time T3: info B updated in session + new log B
T3 > T1 + `DEVICE_ACTIVITY_UPDATE_FREQUENCY`

Explanation:
At this moment, T2, because log A exists, a `res.session` record exists.
When we compute information for the `res.session` record, as this record
is the current session, we must get the current device.
To retrieve the current device, we use the `res.device` model.
Unfortunately, no current device is present (because log B has been deleted)
and `DEVICE_ACTIVITY_UPDATE_FREQUENCY` has not been exceeded.
In this case, we have a current session without current device.

Note:
However, we are certain that there is at least one device for this session
record because session records are built with device records.

Task-6023651

Forward-Port-Of: odoo/odoo#253058

Currently, certain `valid GSTINs` for Non-Resident taxpayers are not 
recognized by the partner `autocomplete` feature.

**Steps to reproduce:**
- Install the `l10n_in` and `partner_autocomplete` modules.
- Navigate to Settings > Users & Companies > Companies.
- Click `New` and set `Tax ID` to `9922JPN29001OSU`.
- Wait for 5–10 seconds.

**Observation:**
The partner autocomplete does not trigger, although it is valid and verifiable 
on the official GST portal: https://services.gst.gov.in/services/searchtp

**Root Cause:**
The issue was already fixed in core validation by PR [1], but the 
GSTIN validation logic used in partner autocomplete was not updated.

At [2], the GSTIN validation regex for NRI taxpayers only supports 
formats ending with `NRX` (X = any alphanumeric character). However, 
certain valid GSTINs follow a revised structure and therefore are not 
matched by the existing regex.

**Fix**:
This commit ensures that valid NRI GSTIN formats are accepted 
during validation by applying a fix similar to [1] to the partner 
autocomplete GSTIN validation at [2].

Related IAP PR: https://github.com/odoo/iap-apps/pull/1491

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

[2]:
https://github.com/odoo/odoo/blob/3016c08a7aa8701ec9b0092b5aafc282b16dd9f3/addons/partner_autocomplete/static/src/js/partner_autocomplete_core.js#L36-L52

Forward-Port-Of: odoo/odoo#253799

Before this commit, test 'Can scroll to notification' may fail non-deterministically with the following error:

```
[toBe] expected values to be strictly equal (Element .o-mail-NotificationMessage:contains(notification 0) not found in viewport of .o-mail-Thread)
```

This happens because while the test is awaiting the scrolling to unread, this is made with just an `await tick()` after opening discuss app. This is not enough: messages need to be loaded and then there's a tick with scroll to unread message.

The awaiting of messages being loaded was missing in the test, which this error is fixing. This is important because the opening of pinned panel and click on jump may be triggered before the auto-scroll to unread message, and this is a problem because the jump to pinned message would be cancelled by the scroll to bottom.

Also instead of awaiting the tick for scroll to unread message, this commit replaces it by assertion of message list being at the bottom. This asserts precisely the scroll has happen, and its ok to have it scroll at bottom as the last message is short and is necessarily smaller than viewport, thus the auto-scroll to this unread message implies this scrolls to the bottom of message list.

Fixes runbot-error-238427

Forward-Port-Of: odoo/odoo#253928

The "rpc service" API (xmlrpc/jsonrpc) have been deprecated in 19.0, JSON-2 acting as replacement. It was at first planned to be removed in 19.1/20 but we succeeded in convicing the management It Was A Bad Idea.

The removal is postponed to Odoo 21.1/22. This makes so that if the [Standard and extended support] policy remains the same until the release of Odoo 22, all versions supported with no additional fees (20, 21, 22) at that time will have JSON-2:

| version | supported at 22 release | rpc services          | JSON-2 |
| ------- | ----------------------- | --------------------- | ------ |
| 18.0    | no[^1]                  | active                | absent |
| 19.0    | no[^1]                  | active but deprecated | active |
| 20.0    | yes                     | active but deprecated | active |
| 21.0    | yes                     | active but deprecated | active |
| 22.0    | yes                     | absent                | active |

[Standard and extended support]: https://www.odoo.com/documentation/19.0/administration/standard_extended_support.html

[^1]: with no additionnal fees.

Forward-Port-Of: odoo/odoo#252721

To reproduce:
- Register your company on Peppol (even sender).
- Change the VAT on your company (will be done if you choose your document layout).
- Send an invoice on the network 
- => The invoice will be refused by the AP.

The issue is that the EAS and Endpoint are automatically re-computed when you write on the VAT. It causes issues as the UBL will be filled with the values on the partner, resulting in a non-synchronised SBD and UBL, which will result in all new invoices to be in error.

Their only solution would be to revert back the EAS/Endpoint on the partner, which will sometimes be blocked meaning they have to un-register->re-register

Also adapt the query count, as we need to do a search in each compute.

opw-5923552
opw-5924552

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#254057
Forward-Port-Of: odoo/odoo#249017

## Issue
In the POS of a Mexican company, when requesting an invoice, the user is asked to set the invoice to public or not. If the customer is missing a recognized ZIP code or country, setting the invoice to public **should not** raise an error, but it does. This is because the `l10n_mx_edi_cfdi_to_public` field is not correctly updated in the ORM, which leads to the UserError below being triggered, as `l10n_mx_edi_cfdi_to_public` is always set to `False` if it's not updated by its `_compute` method.

https://github.com/odoo/enterprise/blob/dd89c2c72039c9910cc0a303bca332f4103c08f6/l10n_mx_edi/models/account_move_send.py#L54-L55

## Cause
The said field is not properly updated because it is a *compute field*. Such fields are not transferred to the ORM because of the two following conditions from the POS:
1. https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L205-L206
2. https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L895-L896

## Solution
To minimize behavioral changes, the required field (`l10n_mx_edi_cfdi_to_public`) is simply added at the end of the
serialization process.

Once this field is correctly shared with the ORM, the UserError is not longer raised when the *Invoice to Public* field is set to "Yes" in the POS.

## Versions >= 19.1
Since https://github.com/odoo/odoo/pull/216523, the error would only be displayed **after** moving onto the FeedbackScreen. Since then, the validation is only computed after moving the POS to the next screen.
**To correctly prevent the user from confirming an order with invalid data, we now check the constraints everytime the customer or the invoicing method is updated:**
- If a customer is selected, trying to set *"Invoice to public"* to *"No"*
will raise an error if the user does not have a ZIP code and a country set.
- If *"Invoice to public"* is set to *"No"*, trying to remove the current
customer or select a customer with a missing ZIP code or country will raise an error.

## Steps to reproduce the initial error:
1. Install the following app and module:
    - Point of Sale (`point_of_sale`)
    - Mexican Localization for the Point of Sale (`l10n_mx_edi_pos`)
2. Set the company to a Mexican one (e.g., *ESCUELA KEMPER URGATE*)
3. Open the POS app
4. Open a register
5. Select a product and click *Add*
6. Click *Payment*
7. Set the Customer to a new customer with only a name
(no Country/ZIP Code)
    - Click "Cash" to set the Remaining to 0
8. Toggle the *Invoice* button, set the *Invoice to Public* to *"Yes"* and click *Ok*
9. Click *Validate*.
10. An error *"Invalid Operation, CFDI not set to Public"* appears.

opw-5171035

Forward-Port-Of: odoo/enterprise#101365
Forward-Port-Of: odoo/enterprise#99871

Steps to reproduce:
-------------------------
1. Install Planning and Contacts.
2. Install any language other than English (e.g., Arabic).
3. Change an employee's contact language to that language.
4. Create a shift for that employee and click "Send".
5. Check the message in Settings > Technical > Discuss > Messages.

Issue:
---------
The email is sent in the language of the current user rather than the
language of the employee receiving the shift.

Cause:
---------
The mail template rendering logic ([_render_lang](https://github.com/odoo/odoo/blob/0dbfa8b99d5c28a7d84e781a7f23b226fd964e95/addons/mail/models/mail_render_mixin.py#L549-L566)) fails to determine a valid language
on the planning slot record because it is not directly linked to a `partner_id`.
As a result, it falls back to the current user's language.


Solution:
------------
Explicitly pass the employee partner's language in the mail context
so that the email is sent in the correct language.

opw-5928676

Forward-Port-Of: odoo/enterprise#110778
Forward-Port-Of: odoo/enterprise#109619