Main issue:

Prior to this commit, updateValue would guarantee that `body_arch` and
`body_html` were always updated in sync (to avoid an inconsistent state where
the user thinks they updated the mailing, and they see the new html in the
editor, but the email html is obsolete and would be sent as is).

However this caused another issue, that the user would lose their work when
switching tab in the Notebook, because computing the `body_html` may be slower
than the view patch to switch tab (`updateValue` is interrupted). In such a
case, neither `body_arch` nor `body_html` was updated on the record, and when
the user comes back to edit them, they see that all changes were lost.

To prevent this, a new strategy is adopted:
- `body_arch` is now updated as soon as possible to save the latest user
  changes
- `body_html` is set to an empty string to avoid inconsistencies, and in order
  to trigger `convert_inline` automatically the next time the
  `mass_mailing_html_field` is instanced without any user action.
- after `convert_inline`, if `updateValue` was not aborted, the record is
  updated again with the new value for `body_html`

Minor issues:

1) Prior to this commit, the iframe would flicker during `convert_inline`
because it was done inside that very iframe, and the `convert_inline` needs a
specific width (1320px) for it to work properly, meaning that if the iframe was
not at that specific dimension, it was resized temporarily for that process.
This commit introduces hooks to execute the `convert_inline` process in a
separate iframe, outside of the user view, which removes this flickering.

2) Prior to this commit, assets for readonly/basic editor/builder were all
loaded inside the iframe, and then toggled on/off depending on which were
needed. Since the `convert_inline` process is moved in another iframe, it's as
good time as any to deprecate this toggling (as it could be a bit unreliable and
could cause some flickering when unloading/reloading the style). There is now a
separate asset bundle for the 3 use case, and only one of them is loaded per
iframe depending on the needs.

3) Prior to this commit, `body_html` was hard-coded as a dependency of the
`mass_mailing_html_field`, and that dependency lacked the `required` attribute,
which should depend on the value of `body_arch`. The dependency is now added in
the related views, and the field is now generic. This also prevents the user
from leaving the view if `convert_inline` could not be completed successfully.

4) Prior to this commit, switching to another view through `doAction` could
throw an error if the field was dirty, as the `form view` would be destroyed
before `commitChanges` had the time to be completed. Now, `commitChanges`
promise is properly awaited by the `action_service` if the field is dirty before
`doAction` (unless `forceLeave` is true).

5) Prior to this commit, the record was updated through a `blur` event on the
iframe window. However, it means that every time the iframe looses focus when
the users interacts with the builder, a popover or the form status indicator,
that blur event would fire, triggering the `convert_inline` process. This commit
reduces the amount of such updates by only triggering the update outside of
these elements, as we don't need to update the record value while the user is
still actively editing the mailing.
Blur handlers/props are deprecated with this commit and will be removed further
down the line.

6) Ensure that in the rare case where a `html_field` value is exactly the same
on different records, the `html_field` state key is updated (triggers a
wysiwyg/mass_mailing_iframe reset).

7) Remove an erroneous part in `onWillUpdateProps` of `mass_mailing_html_field`
which could display the theme selector again on the same record just after
selecting a theme if props were updated.

8) Ensure `withBuilder` getter of `mass_mailing_html_field` properly reads the
state activeTheme every time it is used (if it does not, it could cause issues
with the reactivity, since reading on the state is required for a property
subscription).

9) Remove a useless `onWillUpdateProps` of `mass_mailing_iframe` which was never
used because when `props.showCodeView` changes, the iframe is always destroyed,
so there is no need to update its state.

10) Deprecate usage of `<meta http-equiv="X-UA-Compatible" content="IE=edge"/>`,
to be removed further down the line, as it is useless in the modern web.

11) Ignore errors during a builder "Operation" that was not finished before the
editor was destroyed. In `mass_mailing`, the editor is expected to be
destroyable synchronously to work inside an Odoo view, unlike in `website`.
What's already in the DOM just before destruction will be updated on the
`record`, and the rest of the operation will be lost. However, an attempt is
made to wait for ongoing operations at the start of the
`HtmlField.commitChanges`.

12) Ensure correct visibility option state
Prior to this commit, the `dataAttributeChangeAction` selected item depended on
the domain value computed during the last template rendering, compared to the
current edited element value. The issue is that when an edited element receives
a new `data-filter-domain`, the selected options are evaluated before the
component can register the new domain in its state, so the wrong values are
compared. In this particular case, since we only need 2 values (on/off), an
acceptable trade-off is to choose the selected item ("always visible" vs
"conditionally") based on the Boolean value of the attribute.

13) Remove deprecated assets toggle test
The toggle assets feature was deprecated in a prior [commit1].
The test is removed as its outcome is non-deterministic, because it depends on
the `target` property of `event` returned as a promise resolution value by
`loadBundle`, however the browser can set that target to `null` after the event
was dispatched, so relying on the target value to keep track of the inserted
link is not reliable.
Since that `toggle` feature is not used anymore, it is not needed to run a test
for it. The feature will be removed in the latest `dev` branch.

[commit1]: https://github.com/odoo/odoo/commit/a0aa581636e257894c6c7e87c3793edebecad303

14) Prevent crash on commitChanges if editor is not ready
Prior to this commit, various checks in `commitChanges` did not take into
account that the editor could be instanced but not ready yet (meaning that
plugins are not available, and it is not possible to extract the editable
content).
This commit ensures that `commitChanges` can not crash if called when the editor
is not ready.

15) Properly keep track of dirtiness
mass_mailing changes related to [commit2], which added a way to keep track of a
specific change handled during one `commitChanges` call. The field should stay
dirty if it received changes during a `commitChanges` execution.
In mass_mailing specifically, there were 2 other situations with invalid
tracking of dirtiness:
a) A new record with no change could not be discarded as it was incorrectly
marked as dirty since the `inlineField` value is "".
After this commit, the field is marked as dirty only if the edited field value
is not "" while the `inlineField` value is "", which is the problematic
situation where both values are desynchronized. A new record with both values at
"" is not marked as dirty anymore.
b) Setting a new theme in mass_mailing did not communicate properly with the
relational model about dirtiness.
After this commit, using `setThemeHTML` triggers `onChange`, and the record
update properly tracks that change to communicate with the
`FormStatusIndicator`. The field `isDirty` property stays at `true` though,
because it still needs to execute `convertToEmailHtml` to compute the
`inlineField` value, and it needs the `editor` for that. A `commitChanges`
occurs `onEditorReady` to execute this computation, at the end of which the
field is finally set as not dirty.

[commit2]: https://github.com/odoo/odoo/commit/378580735c785bdcf8b184342834d2b3ddaaaedd

16) Prevent crash with null selection
`document.getSelection()` returns `null` when the selection is not in the
document. However the selection plugin `isSelectionInEditable` function only
support a selection object or `undefined` as an argument, and will crash with
`null`.
This commit ensures that a valid value is provided to the plugin function to
prevent crashes where the selection is moved outside of the `mass_mailing`
iframe before `normalize_handlers` execution.

task-5976348

Forward-Port-Of: odoo/odoo#252571
Forward-Port-Of: odoo/odoo#250883

Problem:
When content is added to the editor, icons are not surrounded by
`feff`s.

Cause:
The selector used to pad elements with `feff`s relies on
`o-paragraph`, which is added during normalization.
However, `BaseContainerPlugin.normalize_handlers` runs last, so when
`FeffPlugin.normalize_handlers` executes, it cannot find icons through
`selectors_for_feff_providers` because the expected paragraph-related
parent is not yet in place.

Solution:
Execute `FeffPlugin.normalize_handlers` immediately after
`BaseContainerPlugin.normalize_handlers`, ensuring the DOM structure is
ready before attempting to add surrounding `feff`s.

Steps to reproduce:
- Add an icon.
- Reload the page.
- Do not make any changes (so normalization is not triggered again).
- Inspect the icon and observe that it does not have surrounding
  `feff`s.

task-5960097

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

Forward-Port-Of: odoo/odoo#252278
Forward-Port-Of: odoo/odoo#250855

Currently, if we try to update the existing `l10n_it_edi_attachment_file` with the signed data received during the submission of an invoice (Invoices for Italian Public Administration businesses must be signed, handled on the IAP side), it fails.

The problem is that in this specific flow, the 'attachment' variable contains a binary rather than attachment_data.

Unfortunately, I could not find a complete flow to reproduce the issue, as there is no flow that sends an invoice to SdI while the l10n_it_edi_attachment_file variable is already set in the move, except maybe via manual import of an attachment into the invoice.

Expected flow:
- User creates a move with `l10n_it_edi_attachment_file` (unspecified how)
- User sends the move to SdI for a Public Administration partner
- IAP signs the attachment and sends it back to Odoo
- Odoo raises an error because it tries to use dictionary features on a binary field
- Odoo does not save the transaction ID, and if the user tries to resend the move, a Duplicate Error occurs from the SdI side.

Ticket [link](https://www.odoo.com/odoo/project.task/5954645)
opw-5954645

Forward-Port-Of: odoo/odoo#253459
Forward-Port-Of: odoo/odoo#252966

Steps to reproduce:
--------------------------------
1. Install Subscription module
2. Create a new subscription quotation and confirm it
3. Generate an invoice for the subscription
4. Attempt to cancel the subscription
   * A ValidationError is correctly raised
5. Close the subscription by selecting any close (churn) reason
6. Attempt to cancel the same closed subscription again

Observation:
--------------------------------
The subscription is successfully cancelled even though it already has invoices

Issue:
--------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/9e39b4b85fcb9f6ed5b21b942796b76b8a6eefdb/sale_subscription/models/sale_order.py#L741-L742 The cancellation logic does not check whether a subscription is already churned and still has active invoices

Solution:
--------------------------------
Added an additional condition to prevent cancelling churned subscriptions that still have active invoices

opw-5479719

Forward-Port-Of: odoo/enterprise#109755
Forward-Port-Of: odoo/enterprise#106596

Steps to Reproduce:
1. Open the website module.
2. Open the media upload dialog to upload an image by either
double-clicking the logo or replacing the existing image.
3. Upload a large file.
4. Abort the upload before it finishes by clicking the 'Discard'
button in the media dialog box.
After performing these steps, a traceback is observed.

Before this commit:
- Image upload failures would throw uncaught exceptions.
- These exceptions would interrupt the flow and result in a poor user
experience with no clear feedback.
- Even after clicking the discard button the image was still
getting uploaded.

After this commit:
- Uploads can be safely aborted when the media dialog is discarded.
- Ongoing XHR requests and RPC calls are properly cancelled.
- The upload loop stops immediately when an abort is triggered with
no traceback.
- Users get a predictable and clean exit instead of a broken state.
- Files are no longer uploaded after clicking Discard.

### task-4752497

Forward-Port-Of: odoo/odoo#250065
Forward-Port-Of: odoo/odoo#219081

When writing to a PoS config, it will automatically set an
`advanced_employee_ids` if none is set. But it will take any employee
that is part of `point_of_sale.group_pos_manager`. If the employee
selected is not part of the same company as the PoS config, and the
current user doesn't have HR employee access it will trigger an ir.rule
that block the user from opening the settings.

Steps to reproduce:
-------------------
* Create a new company
* Create a new user that only have access to this company and no HR
  access
* Create a PoS in the new company
* Login as the new user
* Try to open the settings
> Observation: You will get an access error because the employee set in
  `advanced_employee_ids` is from the other company

Why the fix:
------------
We make sure that when automatically setting the advanced_employee_ids
we filter out the ones that are not from the correct company. If no
employee exist that satisfies the requirements, we take a user from the
`group_pos_manager` and create an employee for him.

opw-5885417

Forward-Port-Of: odoo/odoo#253687
Forward-Port-Of: odoo/odoo#252402

[FIX] planning_field_service: fix follow-up (round 4)
This commit continues to fix the various issues found due to the
refactoring of Field Service feature to integrate it into planning
instead of being an extension of project.

This commit will:
- fix 'Print' action and ticket to intervention portal access
- always display in range mode for planned dates in planning.slot view
- update billable and non-billable filters to take into account
  `under_warranty` field
- review search view of planning.slot, some filters have been renamed
  and moved.
- use employees instead of resources in portal list (no need to display
  the material resource in the portal views in other words)
- add "Send mail", "Send SMS", "Send Report" and "Add/Remove followers" buttons
  in cog menu of list and kanban views of planning.slot model.
- remove helper in ticket button since it does not bring useful
  information.
- add ticket description on related shift, when the user plans an
  intervention from a helpdesk ticket, the new shift created from that
  action, will have the description of the related ticket inside Note
  field (name field)
- fix display_name, to avoid displaying the field used in the group by
  in the display name since it is a bit redundant
- take into account worksheet set in product as default
- fix some labels, visibility conditions, dates format, group_expand
- add default company of the slot when the user creates a resource from
  the form view of planning.slot model
- show customer preview stat button once the intervention is completed
  and a report is available for that intervention
- update tooltip for employee product to bring more context to explain
  how that new field works.
- make sure the SOL for timesheet is not generated when we complete an
  intervention if the project linked is non billable
- add icon on stat button of timesheet
- make sure the user can only create service product in product field in employee
- show "X Products" button to non sale user in the form view of
  planning.slot
- make project billable and timesheetable by default when the user wants
  to create a new project from the project_id field inside the form view
  of planning.slot model
- hide schedule stat button in the form view of project.task if the task
  is a template or linked to a project template
- update visibility condition of sign in in calendar, to make visible
  for planning manager when the slot is published even if the shift is
  not assigned to that user and the slot is in the past.

task-6009593

__

## Error description
The test fails when it is launched at 23h.
We obtain an assertion error:
`AssertionError: datetime.datetime(2026, 2, 26, 11, 0) != datetime.datetime(2026, 2, 25, 11, 0)`

## Origin of the issue
In the `_default_start_datetime()` method of planning, we return `return datetime.combine(fields.Date.context_today(self), time.min)`. So, we call context_today. which is implemented this way: https://github.com/odoo/odoo/blob/f3ec2aa4514c03874aae96ae975e2617e8260c72/odoo/orm/fields_temporal.py#L154-L158 Let's say the hour of the test is 23h50 in GMT+0. The slot will be created at 23h50 in GMT+0. But if the time zone of the environment is set at GMT+1, at the moment of the `_compute_datetime`, we will call this piece of code, where we will translate 23h50 to GMT+1, we will obtain 00h50, then only return the day, which offsets the result of one day in the future.

X-original-commit: d91c53869842f65a60088ffa101f67404af6e58e

note:
backport of
https://github.com/odoo/enterprise/pull/108891

Forward-Port-Of: odoo/enterprise#110126

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

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#110414
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#244231
Forward-Port-Of: odoo/odoo#239988

The field `res_users.pin` is restricted to members of `hr.group_hr_user` but is added to the form view, so if a user with HR access rights tries to view another user, it will trigger an access error:

```
odoo.exceptions.AccessError: You do not have enough rights to access the field "pin" on Employee (hr.employee). Please contact your system administrator.
```

To reproduce:
- With `hr` installed, remove its access rights from the admin and try to view another user.

This error is related to recent changes[^1] in the access of employee fields, it might be possible to have a different approach to this error. It will break while trying to access the employee field for which the user doesn't have access:
https://github.com/odoo/odoo/blob/012f510e70d7d0afd226e4198b2e1759db3ca18d/addons/hr/models/res_users.py#L29-L36

In earlier versions, the field was not accessed directly. It was just automatically hidden from the view if the user didn't have the right group.
[^1]:https://github.com/odoo/odoo/commit/012f510e70d7d0afd226e4198b2e1759db3ca18d

Steps to reproduce:
--------------------------------
1. Install Subscription module
2. Create a new subscription quotation and confirm it
3. Generate an invoice for the subscription
4. Attempt to cancel the subscription
   * A ValidationError is correctly raised
5. Close the subscription by selecting any close (churn) reason
6. Attempt to cancel the same closed subscription again

Observation:
--------------------------------
The subscription is successfully cancelled even though it already has invoices

Issue:
--------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/9e39b4b85fcb9f6ed5b21b942796b76b8a6eefdb/sale_subscription/models/sale_order.py#L741-L742 The cancellation logic does not check whether a subscription is already churned and still has active invoices

Solution:
--------------------------------
Added an additional condition to prevent cancelling churned subscriptions that still have active invoices

opw-5479719

Forward-Port-Of: odoo/enterprise#109755
Forward-Port-Of: odoo/enterprise#106596

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:
- Activate the GS1 nomenclature
- Create a product "P1" with the barcode: 15099590225865
- Create an internal transfer with one unit of P1
- Go to Barcode > Operations > Internal Transfers
- Scan the barcode: 15099590225865 to filter transfers by this product barcode

Problem:
An validation error is raised:
A ValidationError is raised:
"A GS1 barcode nomenclature pattern was matched. However, the barcode failed to be converted to a valid date."

Explanation:
GS1 barcodes must follow a strict nomenclature based on well-defined rules.
For example, a GS1 product barcode should start with the Application Identifier 01 followed by 14 digits.

The GS1 parser processes the barcode rule by rule and applies the first matching rule. In this case, the barcode 15099590483921 is interpreted as a date because it starts with "15", which corresponds to a GS1 Application Identifier for a date. As a result, the parser attempts to convert the first six digits into a date and raises a ValidationError.

Solution:
Catch the ValidationError raised during GS1 date parsing in   filter_on_barcode
and explicitly reset parsed_results to False, allowing the normal filter
on product resolution logic to continue. This prevents GS1 parsing errors
from blocking valid barcodes and ensures that product is correctly filtered

opw-5929064

Forward-Port-Of: odoo/enterprise#110636

The interaction for filling the dynamic content of dynamic snippets
did not run inside the iframe to preview the snippet to add. This is
not an issue for the initial dynamic snippet, as they are filled with
fake content. But when saving a custom snippet, the dynamic content is
cleared, and they seem empty when previewed. This is the case since the
[website builder refactor] as the previous builder re-used the preview
of the initial snippet.

This commit adds the interaction to fill dynamic content in the preview
iframe, and changes the interaction to avoid emptying the fake content
from initial dynamic snippets during preview.

Steps to reproduce:
- Open website builder
- Add a dynamic snippet (for example "Events")
- Save the snippet as a custom snippet
- Click on "Custom" snippet category
- Bug: The preview for the custom snippet does not have the dynamic part
(there is no event, just the title)

[website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2

task-5427353

Forward-Port-Of: odoo/enterprise#108912

Create an interactive PDF form in Adobe Acrobat containing a standard Text Field (/FT /Tx).

- Fill the text field with a value (e.g., "John Doe") and save the PDF.
- (Note: Adobe Acrobat will often automatically assign an Appearance State (/AS /N) to this text field).
- Upload this PDF to the Sign app.

**Current behavior:**
The text field's string value is ignored and replaced with a checkmark (✓).

**Expected behavior:**
The text field should correctly render the string value that the user entered.

**Cause of the issue:**
In the _draw_field_value function, the parser checks if an /AS (Appearance State) tag exists and is not set to /Off. If true, it assumes the field is a checked box and draws a chr(0x2713).
However, it fails to check the Field Type (/FT) first. Because Adobe Acrobat sometimes assigns /AS tags to standard Text Fields (/FT /Tx), we misinterprets these populated text fields as checked buttons.

**Solution:**
This PR fixes the issue safely for stable versions across two commits:

[REF]: Extracts the value extraction logic into a dedicated _get_field_value helper method to allow isolated unit testing without requiring a canvas or physical PDF files. No behavioral changes in this commit.

[FIX]: Wraps the /AS check within an if field_type == "/Btn": condition. This ensures only actual Checkboxes and Radio Buttons render as checkmarks, allowing Text Fields to fall through and properly return their /V string values. 

Task: 6018260

**Steps to reproduce:**
- Install accountant and l10n_gt_edi

- Switch to a Guatemalan company (e.g. GT Company)
- In Accounting settings, set "Web Services" of Guatemala Localization to "Test" or "Production" ("Demo" mode doesn't trigger any error)
- Set "Infile Credentials" (real credentials are required)

- Create a "Timbre de prensa" tax:
  * Tax Name: [anything]
  * Tax Computation: Percentage
  * Amount: 0.5000 %
  * Included in Price: Tax Excluded
  * GT Taxable Unit Code: 1
  * GT Tax Short Name: TIMBRE DE PRENSA

- Create an invoice:
  * Customer: [a Guatemalan customer] (e.g. Empresa Guatemalteca S. A.)
  * GT Document Type: FACT - Factura Electrónica
  * Invoice Lines:
    - Taxes: [the default 12% IVA tax (incl) and "Timbre de prensa" (excl)]
- Confirm the invoice
- Send the invoice to SAT

**Issue:**
Several errors are returned by the SAT service:
- "FEL-GUI-24 | 2.7 | 2.7.1 | No. 2 | Error - Monto Gravable calculado incorrectamente para el impuesto [IVA]. Cod. Unidad Gravable [1] (Detalle linea No. 1)."
- "FEL-GUI-37 | 2.11 | 2.11.1 | No. 2 | Error - Monto Gravable calculado incorrectamente para el impuesto [TIMBRE DE PRENSA]. (Detalle linea No. 1)."

**Cause 1:**
In the XML sent to the SAT, the amount of the "Timbre de prensa" is included in the unit price, but it should not.

**Cause 2:**
Depending on the sequence of the taxes, the "Timbre de prensa" tax can be declared before the IVA tax in the XML, which seems to also raise this error.

**Solution 1:**
If there is a "Timbre de prensa" tax, its amount is excluded from the gross unit price that is computed.

**Solution 2:**
Order the IVA taxes first.

opw-5208714

**Steps to reproduce**
1. Have an employee using a flexible schedule
2. Create a slot from e.g. 20PM to 4AM for this employee. Make
sure this is the only slot that week for the employee.
3. Publish the Schedule and send it to the employee. Open the
outgoing mail to access the link to the planning view.

Issue: the slot is not visible in the week view.

**Cause**
https://github.com/odoo/enterprise/blob/04a885dbb6eed96297cb5ce9a155ebf8e169427c/planning/controllers/main.py#L193-L194
The `event_hour_min` and `event_hour_max` returned by `planning_get`
and used to control the min/max hours displayed in the week view,
didn't account for slots over multiple days.
For a slot between 20pm and 4am, the `event_hour_max` should be the
end of the day, and the `event_hour_min` should be the start of the
day.

**Solution**
- we change the `event_hour_min` and `event_hour_max` for multi-day
slots to display the full days in the week view
- the previous point has the drawback of displaying the full days
for non-flexible employees even when not necessary. This is because
`slots_start_datetime` and `slots_end_datetime` contained the
`planning.slot` start and end. Instead, we can look at the actual
slot values displayed (by `_get_slots_vals`). For example, a 5 day
slot for a non-flexible employee may contain actual slot values
corresponding to a typical 8-17 working day.

opw-5245985

Prerequisites:
------------------------------
1. Set up incoming mail server with Create a New Record set to Helpdesk Ticket
2. From Settings, create one Alias Domain

Steps to reproduce:
------------------------------
1. Install Helpdesk module
2. Open Helpdesk Team > Settings
3. Inside Channels, Set the mail used for the incoming server and the alias created
4. Set Accept Emails From to Everyone
5. Create a new contact with multiple emails (eg: `a@b.com`, `c@d.com`)
6. From Fiest mail (eg: `a@b.com`), Send one mail to mail set in the helpdesk team alias mail.
7. Open Incoming mail sever  > Click on Fetch Now
8. Open Created Contact

Observation:
------------------------------
The contact's email field is overwritten. The second email address (e.g. `c@d.com`) is lost

Issue:
------------------------------
After `create`, since `partner_email` was stored with a value that differs from `partner_id.email`, the inverse method `_inverse_partner_email` kicks in. This is where `_get_partner_email_update()` is called. In `_get_partner_email_update()` `tools.email_normalize()` only handles a single email. When the partner has multiple email, the normalization keeps both, while the ticket email normalizes to just have one mail. The strict `!=` comparison fails, triggering the unwanted update.

https://github.com/odoo/enterprise/blob/7c23efafe368787c858db31cec075f642ae6715b/helpdesk/models/helpdesk_ticket.py#L363-L369

Solution:
------------------------------
Instead of comparing the full normalized strings, we should check whether the ticket's normalized email is contained within the set of the partner's normalized emails

Note for reviewer
-----------------------------
After discussion with the PO (LNA), his opinion is that having multiple email addresses in a single field is not a good practice. This use case is only semi-supported in Odoo, it may work in some cases, but it is not reliable. The recommended approach is to create separate contacts for each email address.

That said, we should also avoid automatically clearing or altering the existing value in the field.

Based on this, I have implemented a minimal fix that prevents altering the existing value in the field. I am leaving it up to the review to decide whether this fix is worth keeping from a technical standpoint.


opw-5478067

### Issue:
When a kit BoM has `product_qty` > 1 (e.g. 12 Kit X = 12 Comp A + 12 Comp B), the SO line cost after confirmation is multiplied by the batch size. Selling 1 Kit X shows a cost of 360 instead of 30.

### Cause:
The method `_compute_average_price` uses `bom.explode(self, 1)`, which returns raw BoM line quantities for one full batch. It accumulates the total batch cost but returns it without dividing by `bom.product_qty`.

### Steps to Reproduce:
- Costing Method = AVCO, Inventory Valuation = Automated
- Comp A (cost 10), Comp B (cost 20), Kit X (cost 0)
- Kit BoM: 12 Kit X = 12 x Comp A + 12 x Comp B
- Create and confirm a SO for 1 x Kit X
- Expected SO line cost: 30
- Actual SO line cost: 360

Solution:
This fix mirrors the normalization already done in `_compute_bom_price`, which correctly divides by `bom.product_qty` and converts UoMs.

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

Forward-Port-Of: odoo/odoo#253406

**Issue**
Lots manually indicated on stock move lines can be overridden when producing a
Manufacturing Order.

**Steps to reproduce**
- Create a storable product P tracked by lot
- Create two lots for product P with 2 units each
- Create a MO for a product consuming two units P and confirm it
- On the raw move, manually set 1 unit for each lot
- Click on "Produce All"
- Check the move line associated to the product P
-> 2 units associated to the first lot consumed instead of 1 unit each

**Cause**
While producing:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2109-L2110
It sets the quantities:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2246
This calls `_set_quantity_done_prepare_vals` with a qty of 2:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2264
which will, for each move line:
- Take the quantity indicated by move line:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2274
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2296-L2297
- Then take all the available quantity left for the lot associated to the move line:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2302-L2309
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2326-L2327
Instead of first taking all the quantity indicated by the move line, before checking available quantity

**Solution**
Assume that move lines being created in mrp without changing the producing quantity are manually created

opw-[5946439](https://www.odoo.com/web#id=5946439&view_type=form&model=project.task)

**Issue**
Lots manually indicated on stock move lines can be overridden when producing a
Manufacturing Order.

**Steps to reproduce**
- Create a storable product P tracked by lot
- Create two lots for product P with 2 units each
- Create a MO for a product consuming two units P and confirm it
- On the raw move, manually set 1 unit for each lot
- Click on "Produce All"
- Check the move line associated to the product P
-> 2 units associated to the first lot consumed instead of 1 unit each

**Cause**
While producing:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2109-L2110
It sets the quantities:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2246
This calls `_set_quantity_done_prepare_vals` with a qty of 2:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2264
which will, for each move line:
- Take the quantity indicated by move line:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2274
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2296-L2297
- Then take all the available quantity left for the lot associated to the move line:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2302-L2309
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2326-L2327
Instead of first taking all the quantity indicated by the move line, before checking available quantity

**Solution**
Assume that move lines being created in mrp without changing the producing quantity are manually created

opw-[5946439](https://www.odoo.com/web#id=5946439&view_type=form&model=project.task)

When the user sends a push notification through Social Marketing, the application displays two notification popups because:

1. The Firebase SDK automatically displays a notification popup if the request made to Firebase includes a `notification` field.
2. Our service worker displays a notification popup when receiving a background message from Firebase.

To prevent duplicate notifications, we will remove the custom event listeners in the service worker and update the request made to Firebase so that the Firebase SDK opens a notification for us.

Furthermore, this PR fixes the error `Failed to execute 'subscribe' on 'PushManager': Subscription failed - no active Service Worker` occurring when the user accepts the push notifications.

To fix that issue, we will:
1. Ensure that the service worker reaches the `ready` state before communicating with it.
2. Set the service worker's scope to `/` so it controls all pages on the origin, ensuring push subscriptions succeed and the worker can communicate with any page.

Finally, we will use the legacy `importScripts` syntax to load Firebase dependencies because the ECMAScript module syntax is not supported for service workers in Firefox. This approach improves push notification compatibility across browsers.

Task-5124645

Forward-Port-Of: odoo/enterprise#96029

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

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

When the user sends a push notification through Social Marketing, the application displays two notification popups because:

1. The Firebase SDK automatically displays a notification popup if the request made to Firebase includes a `notification` field.
2. Our service worker displays a notification popup when receiving a background message from Firebase.

To prevent duplicate notifications, we will remove the custom event listeners in the service worker and update the request made to Firebase so that the Firebase SDK opens a notification for us.

Furthermore, this PR fixes the error `Failed to execute 'subscribe' on 'PushManager': Subscription failed - no active Service Worker` occurring when the user accepts the push notifications.

To fix that issue, we will:
1. Ensure that the service worker reaches the `ready` state before communicating with it.
2. Set the service worker's scope to `/` so it controls all pages on the origin, ensuring push subscriptions succeed and the worker can communicate with any page.

Finally, we will use the legacy `importScripts` syntax to load Firebase dependencies because the ECMAScript module syntax is not supported for service workers in Firefox. This approach improves push notification compatibility across browsers.

Task-5124645

Forward-Port-Of: odoo/enterprise#96029

Use `with_context(prefetch_fields=False)` when evaluating `filtered('email_normalized')` to prevent the ORM from prefetching a large group of fields. This avoids fetching heavy fields such as `description` for the whole batch, as by default all the stored fields share the same prefetch group.
which could lead to excessive memory usage and `MemoryError` during recomputation.

```sql
apan_3928644=> select pg_size_pretty(sum(pg_column_size(description))) from crm_lead where description is not null;
 pg_size_pretty
----------------
 18 GB
(1 row)
```

MemoryError faced with target db:
```py
File "/home/odoo/src/odoo/17.0/addons/crm/models/crm_lead.py", line 465, in _compute_email_domain_criterion
    for lead in self.filtered('email_normalized'):
  File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6166, in filtered
    return self.browse([rec.id for rec in self if func(rec)])
  File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6166, in <listcomp>
    return self.browse([rec.id for rec in self if func(rec)])
  File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6165, in <lambda>
    func = lambda rec: any(rec.mapped(name))
  File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6142, in mapped
    recs = recs._fields[name].mapped(recs)
  File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1293, in mapped
    self.__get__(first(remaining), type(remaining))
  File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1182, in __get__
    recs._fetch_field(self)
  File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3824, in _fetch_field
    self.fetch(fnames)
  File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3874, in fetch
    fetched = self._fetch_query(query, fields_to_fetch)
  File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3967, in _fetch_query
    rows = self.env.cr.fetchall()
MemoryError
```




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