Step to reproduce:
- install point_of_sale with demo
- have two company and 1 pos in each company
- install pos_hr
- install pos_sale

Observation:
- we get a traceback
```
File "/src/saas-19.2/odoo/orm/fields_misc.py", line 115, in __get__
    raise ValueError("Expected singleton: %s" % record) from None
ValueError: Expected singleton: res.company(7, 8)
 ```
- and pos_sale is not installed

Cause:
- when installing `pos_sale`  `_ensure_downpayment_product` is called.
- this sets downpayment product on every `pos.config` record.
- this triggers write call from pos_hr, which tries to identify users for pos
- this uses `with_company(self.company)`   <-----  actual issue
- here self has two config, each from different company, hence `with_company`
raises singleton error

why not in earlier verison:
- before commit [1] we only set downpayment product on only pos_config_main
- now we set it on every pos.config, so now self contain multiple records

[1] https://github.com/odoo/odoo/commit/a3f9114434c7cab8757b0283698662792e6b7946

Fix:
- compute users by first grouping them over company_id
related pr: https://github.com/odoo/odoo/pull/254026


opw-6217135

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

Forward-Port-Of: odoo/odoo#264962

Steps to produce:
---
- Install the `Accounting` module.
- Create several invoices for a portal user with different payment states (e.g., In Payment, Not Paid, Paid).
- Log in as the portal user.
- Navigate to the invoices list and attempt to sort by **Status**.

Issue:-
---
- Sorting by **Status** does not reflect the actual invoice payment status, resulting in incorrect ordering.

Root cause:
---
- At [1], the sorting field for Status is set to state, which corresponds to invoice states (Draft, Posted, Cancelled). However, the portal displays and expects sorting based on payment_state.

Fix:
---
- Update the sorting configuration to use payment_state instead of state,
  ensuring that invoices are sorted correctly according to their payment
  status on the portal.

[1]https://github.com/odoo/odoo/blob/5b85287ec4ea9f1b51e0f33402900777dfeeb725/addons/account/controllers/portal.py#L46-L52

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

Forward-Port-Of: odoo/odoo#262976

Currently invoices generated from pos orders do not show the product referense alongside the product name.

Steps to reproduce:
-------------------
* Open shop and select Cabinet with doors
* Add customer to order
* Pay the order
* Wether you selected to invoice or you didn't, does not matter, you can invoice from the backend
> Observe on the invoice that the product does not show the internal reference "Cabinet with Doors"
* Create a sale order for the same product, deliver and invoice
> Observe the invoice, the product shows reference "[E-COM11] Cabinet with Doors"

Why the fix:
------------
After this commit: https://github.com/odoo/odoo/commit/aff477805577cb7ed00fb94440dda5cf2f29cb44
we're using `full_product_name` to set the name on move line name.

We could simply add the reference when computing the product name but the logiq used to computed the display name is a bit more complex than simply adding it always.

Instead we use both display_name and full_product_name to build the final name. This way it has the reference if any and all information about variants are kept as well.

opw-5950016

Forward-Port-Of: odoo/odoo#266797
Forward-Port-Of: odoo/odoo#253540

**Steps to reproduce:**
1. Install l10n_es_edi_verifactu.
2. Switch to a ES company.
3. Create a customer invoice and send it to VeriFactu.
4. Enable Developer Mode.
5. Go to Settings > Technical > Sequences & Identifiers > Sequences.
6. Search for the `Sequence Code: l10n_es_edi_verifactu` and open it.
7. Set a prefix or suffix using any alphabetical character.
8. Create a new invoice and send it to VeriFactu

**Issue:**
Traceback on sending Veri*Factu:
`ValueError: invalid literal for int() with base 10: 'F260001'`

**Cause:**
The value returned by `ir.sequence.next_by_id()` may contain alphabetical characters (due to prefix/suffix), while the field `chain_index` expects an integer. The raw sequence value was directly assigned, causing the conversion to fail.

**Fix:**
Catch the ValueError raised by int() when the sequence value contains non-numeric characters (e.g. due to a prefix/suffix). Instead of crashing, surface a user-friendly error on the document telling the user to remove the prefix/suffix from the sequence configuration.

**opw-6037528**

Forward-Port-Of: odoo/odoo#255473

**Problem:**
When a combo product has a price but all of its combo components have a zero list price, the quotation shows the combo's price twice: once on the combo line itself and once on the last combo item line.

**Steps to reproduce:**
1. Create a combo product with a non-zero price and two or more combo groups whose component products have a zero list price.
2. Create a sale order, add the combo, pick one item per group.
3. Look at the quotation/order: the combo line total and the last combo-item line both show the full combo price.

**Current behavior:**
The full combo price ends up on the last combo item line; the other combo items show 0. The combo line then displays the same total via `_get_combo_totals`, so the same amount appears twice.

**Expected behavior:**
The combo's price is spread across its combo items so no single line duplicates the combo total.

**Cause of the issue:**
`_get_combo_item_display_price` prorates the combo price by each combo's base price. When every base price is 0, every prorated price is 0, so `combo_price_delta` equals the full combo price and is added to the last combo as a rounding correction, concentrating the whole price there instead of spreading it.

**Fix:**
Treat an all-zero base case as "no proration signal" and split the combo price evenly across combos before the delta adjustment runs. The delta correction then only handles rounding, as intended.

opw-6217945

Forward-Port-Of: odoo/odoo#265829
Forward-Port-Of: odoo/odoo#265010

When calling on a empty recordset action_mark_as_done, it creates a traceback.

**Observation**

When calling action_mark_as_done, the method first loops over each workorder to perform various safety checks, and then calls button_finish to close all workorders:
https://github.com/odoo/enterprise/blob/24008b550c5e7cf04cde2028c40f8a32d5b0e504/mrp_workorder/models/mrp_workorder.py#L881-L888 
Inside button_finish, it retrieves all open workorders and marks them as done:
 - Retrieve open workorders: https://github.com/odoo/odoo/blob/36a1c6300f52f408b6af3f769e26686e07810e5a/addons/mrp/models/mrp_workorder.py#L659 
 - mark them as done:
https://github.com/odoo/odoo/blob/36a1c6300f52f408b6af3f769e26686e07810e5a/addons/mrp/models/mrp_workorder.py#L675-L678

Returning to action_mark_as_done, it attempts to set the state to 'done' on the last workorder outside of the loop, referencing the loop variable:
https://github.com/odoo/enterprise/blob/24008b550c5e7cf04cde2028c40f8a32d5b0e504/mrp_workorder/models/mrp_workorder.py#L894 

-> If self is empty, the loop never executes. This leaves the loop variable empty, which ultimately triggers a traceback.

opw-6239910

Forward-Port-Of: odoo/enterprise#118718
Forward-Port-Of: odoo/enterprise#118403

Problem:
When selecting text containing `o_inline_code` and applying formatting such as bold, italic, or underline, the formatting cannot be removed.

Cause:
When applying formatting, nodes matching
`is_formattable_node_predicates` are ignored. However, when checking
whether the selection is already formatted, those nodes are not ignored,
so the selection is erroneously considered to be only partially
formatted.

Solution:
Take `is_formattable_node_predicates` into account when checking whether a selection is formatted.

Steps to reproduce:
- Go to To-Do → Create New.
- Type some text and add inline code on the same line.
- Select all content using Ctrl + A.
- Apply formatting such as bold, italic, or underline using keyboard shortcuts (Ctrl + B / Ctrl + I / Ctrl + U).
- Press the same shortcut again to remove the formatting.
- Observe that the formatting is not removed.

task-6229228

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

Forward-Port-Of: odoo/odoo#267455
Forward-Port-Of: odoo/odoo#265183

### Steps to Reproduce :

- Go to To-Do → Create New
- Type something
- Apply font color → then background color.
- Try to remove the font color.
- You will not be able to remove the font color.

### Description of the issue/feature this PR addresses:

- In getFonts, the closestElement predicate was used to find the nearest `<font>` element.
For nested structures like:
```html
<font style='color: ...'>
    <font style='background-color: ...'>test</font>
</font>
```
predicate would return inner `<font>` (background-color) since it is closest.
- As a result, when resetting the text color, the operation targeted the wrong element, and the outer color was not removed.

### Desired behavior after PR is merged:

- When resetting (i.e. mode is used), find the closest node that matches the specific mode. Then we apply or reset the color on that node.

task-6124432

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

Forward-Port-Of: odoo/odoo#262203

**Steps to reproduce:**
- Install Sales app
- Create a Sales Order
- Click on the 'Send by Email' action
- Add an attachment and send it
- Open the chatter to create a log note
- Attachment is attached to the new message
- It disappears on refresh

**Issue:**
Attachment upload widget was moved to the toolbar of the composer with [1], which split it into `mail_composer_attachment_selector` and `mail_composer_attachment_list`.

Then with [2] the selector logic was changed to use `FileUploader` instead of `FileInput` to get the attachment synced when switching back and forth between full and normal chatter composers.

But this should not impact action composers created with `'mail.email_compose_message_wizard_form'`.

**Fix:**
Restrict the attachment save to the full composer using context.

[1] https://github.com/odoo/odoo/commit/cee3c8146863300242f9f2d109743a50c2b91027
[2] https://github.com/odoo/odoo/commit/9f7249a141b618fc8640a65d1f7fc20023156ce3

opw-5164504

Forward-Port-Of: odoo/odoo#266994
Forward-Port-Of: odoo/odoo#265736

When calling on a empty recordset action_mark_as_done, it creates a traceback.

**Observation**

When calling action_mark_as_done, the method first loops over each workorder to perform various safety checks, and then calls button_finish to close all workorders:
https://github.com/odoo/enterprise/blob/24008b550c5e7cf04cde2028c40f8a32d5b0e504/mrp_workorder/models/mrp_workorder.py#L881-L888 
Inside button_finish, it retrieves all open workorders and marks them as done:
 - Retrieve open workorders: https://github.com/odoo/odoo/blob/36a1c6300f52f408b6af3f769e26686e07810e5a/addons/mrp/models/mrp_workorder.py#L659 
 - mark them as done:
https://github.com/odoo/odoo/blob/36a1c6300f52f408b6af3f769e26686e07810e5a/addons/mrp/models/mrp_workorder.py#L675-L678

Returning to action_mark_as_done, it attempts to set the state to 'done' on the last workorder outside of the loop, referencing the loop variable:
https://github.com/odoo/enterprise/blob/24008b550c5e7cf04cde2028c40f8a32d5b0e504/mrp_workorder/models/mrp_workorder.py#L894 

-> If self is empty, the loop never executes. This leaves the loop variable empty, which ultimately triggers a traceback.

opw-6239910

Forward-Port-Of: odoo/enterprise#118718
Forward-Port-Of: odoo/enterprise#118403

## [FIX] planning_field_service: avoid division by 0

Before this commit, when the shift is created during the weekend, the
allocated_percentage will be 0 percent because the resource assigned is
not supposed to work at that day and so a division by zero occured in
the onchange of break_time field in planning.slot model.

This commit checks if allocated_percentage is not equal to 0 before
computing the new allocated hours when the user alters break_time field
on a planning.slot.

## [FIX] planning_field_service: don't start test with onboarding tour with demo

Before this commit, the planning_field_service_tour tour does not work
when there is demo data because the tour will select the first slot in
the gantt view which will be an open shift instead of a shift assigned
to the current user because of that, the sign in button is not displayed
as expected.

This commit makes sure the test running the planning_field_service_tour
tour is skipped when demo data are installed.

runbot-error-242483

#### Description of the issue/feature this PR addresses:
The "Stock Account: Inventory Valuation Closing" cron is meant to post valuation journal entries for companies configured with periodic inventory valuation. Due to a faulty domain in ResCompany._cron_post_stock_valuation, monthly companies are never processed, and on the last day of the month daily companies are also skipped. As a result, no inventory valuation journal entries are ever generated by this cron for periodic-valuation companies.

#### Current behavior before PR:
The cron's domain requires inventory_period = 'daily', which excludes monthly companies on every non-last day of the month. On the last day of the month, an extra AND clause is added requiring inventory_period = 'monthly'. Combined with the existing 'daily' clause, this produces a contradiction (period = 'daily' AND period = 'monthly') that matches no records, so daily companies are dropped on that day as well. Net effect: monthly companies are never processed, and daily companies are skipped on month-end.

#### Desired behavior after PR is merged:
On a non-last day of the month, the cron processes companies with inventory_period = 'daily'. On the last day of the month, the cron processes both 'daily' and 'monthly' companies, so monthly valuation entries are posted at month-end without dropping daily companies.

opw-6115649

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

Forward-Port-Of: odoo/odoo#264782
Forward-Port-Of: odoo/odoo#264298

**Steps to reproduce:**
* Install *Türkiye - Nilvera* (`l10n_tr_nilvera`) module.
* Log in as *admin user*.
* Create a *partner* for the company.
  * Set *country* as Turkey.
  * Configure required *taxes*.
* Create a *demo user*.
* Grant the demo user *Accounting admin access*.
* Log in with the *demo user*.
* Navigate to *Contacts* → open the *Turkey company partner*.
* Navigate to *Nilvera Status* (via Invoicing/Accounting tab) click on *Verify*.

**Observed behavior:**
* A *company access error* is raised during partner verification.

**Cause:**
* The field *l10n_tr_nilvera_api_key* is restricted with `groups='base.group_system'`, requiring full system admin rights.
* Users with *module-level admin access* (e.g., Accounting) do not have sufficient rights, causing the access error.

**Fix:**
* Use `sudo()` on `env.company` to bypass the restrictive group access.
* This allows users with appropriate *functional admin rights* to perform verification without granting full system privileges.

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

Forward-Port-Of: odoo/odoo#262668

Problem:
When selecting text containing `o_inline_code` and applying formatting such as bold, italic, or underline, the formatting cannot be removed.

Cause:
When applying formatting, nodes matching
`is_formattable_node_predicates` are ignored. However, when checking
whether the selection is already formatted, those nodes are not ignored,
so the selection is erroneously considered to be only partially
formatted.

Solution:
Take `is_formattable_node_predicates` into account when checking whether a selection is formatted.

Steps to reproduce:
- Go to To-Do → Create New.
- Type some text and add inline code on the same line.
- Select all content using Ctrl + A.
- Apply formatting such as bold, italic, or underline using keyboard shortcuts (Ctrl + B / Ctrl + I / Ctrl + U).
- Press the same shortcut again to remove the formatting.
- Observe that the formatting is not removed.

task-6229228

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

Forward-Port-Of: odoo/odoo#267455
Forward-Port-Of: odoo/odoo#265183

**Steps to reproduce:**
- Install Sales app
- Create a Sales Order
- Click on the 'Send by Email' action
- Add an attachment and send it
- Open the chatter to create a log note
- Attachment is attached to the new message
- It disappears on refresh

**Issue:**
Attachment upload widget was moved to the toolbar of the composer with [1], which split it into `mail_composer_attachment_selector` and `mail_composer_attachment_list`.

Then with [2] the selector logic was changed to use `FileUploader` instead of `FileInput` to get the attachment synced when switching back and forth between full and normal chatter composers.

But this should not impact action composers created with `'mail.email_compose_message_wizard_form'`.

**Fix:**
Restrict the attachment save to the full composer using context.

[1] https://github.com/odoo/odoo/commit/cee3c8146863300242f9f2d109743a50c2b91027
[2] https://github.com/odoo/odoo/commit/9f7249a141b618fc8640a65d1f7fc20023156ce3

opw-5164504

Forward-Port-Of: odoo/odoo#266994
Forward-Port-Of: odoo/odoo#265736

__

## Short functional explanation of the error
When setting a time off for an employee who has a flexible schedule, in the attendance app, on the calendar with the 'days' view. We can see that the hours are grayed out from 8 hours to 16 hours. However, according to this message:
https://www.odoo.com/mail/message/1027495005
"[...] the entire day of absence might not be represented as such, which is an issue (for example if a flexible employee with 8h/day takes a day off, the duration of the leave should be 1 day/8 hours but on the gantt view everything should be gray from midnight to midnight)".
Moreover, when we select the Week or Month view on the calendar, the day off isn't grayed out. This comes from the fact that, for a flexible schedule, we consider that any time of the day can be a working hour; and we only grey out days in the calendar where no hour has been worked at all. Hence, the hours considered during a flexible day off should be from midnight to 23:59:59.

## Reproduction Steps
1. Go to an employee's profile and set their schedule to flexible.
2. Create a time off of a one-day duration for this employee.
3. Go to the attendance app and see the calendar.

### Expected behavior
When clicking on the Day view, all hours from midnight to 11pm should be grayed out.

When clicking on the Week/month view, the day of the time off should be grayed out.

### Unexpected behavior
When clicking on the Day view, hours from 8am to 4pm are grayed out.

When clicking on the Week/month view, the day of the time off isn't grayed out.

## Origin of the issue
First, we only consider the leave if the resource is fully flexible, i.e if the employee has no working calendar set:
 https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/resource/models/resource_calendar.py#L546
However, if the schedule of the employee is flexible, the leave resource isn't considered as fully flexible, thus leading us to a leave from 8 am to 4 pm.

Moreover, when processing flexible leaves, we return the unavailable intervals with the timezone of the employee:
https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/resource/models/resource_calendar.py#L589-L592 Whereas when we process fixed leaves, we return the unavailable intervals under utc:
https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/resource/models/resource_calendar.py#L597-L601

This leads us to display problems: when the user is under European/ Brussels time in summer, the leave starts at 2 am and ends at 11pm, instead of starting at midnight.

Note: after discussion with AJU, it has been agreed that the behavior
should be the same on the Planning app.
__
opw-6030212



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

Forward-Port-Of: odoo/odoo#264154
Forward-Port-Of: odoo/odoo#256636

__

## Short functional explanation of the error
When setting a time off for an employee who has a flexible schedule, in the attendance app, on the calendar with the 'days' view. We can see that the hours are grayed out from 8 hours to 16 hours. However, according to this message:
https://www.odoo.com/mail/message/1027495005
"[...] the entire day of absence might not be represented as such, which is an issue (for example if a flexible employee with 8h/day takes a day off, the duration of the leave should be 1 day/8 hours but on the gantt view everything should be gray from midnight to midnight)".
Moreover, when we select the Week or Month view on the calendar, the day off isn't grayed out. This comes from the fact that, for a flexible schedule, we consider that any time of the day can be a working hour; and we only grey out days in the calendar where no hour has been worked at all. Hence, the hours considered during a flexible day off should be from midnight to 23:59:59.

## Reproduction Steps
1. Go to an employee's profile and set their schedule to flexible.
2. Create a time off of a one-day duration for this employee.
3. Go to the attendance app and see the calendar.

### Expected behavior
When clicking on the Day view, all hours from midnight to 11pm should be grayed out.

When clicking on the Week/month view, the day of the time off should be grayed out.

### Unexpected behavior
When clicking on the Day view, hours from 8am to 4pm are grayed out.

When clicking on the Week/month view, the day of the time off isn't grayed out.

## Origin of the issue
First, we only consider the leave if the resource is fully flexible, i.e if the employee has no working calendar set:
 https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/resource/models/resource_calendar.py#L546
However, if the schedule of the employee is flexible, the leave resource isn't considered as fully flexible, thus leading us to a leave from 8 am to 4 pm.

Moreover, when processing flexible leaves, we return the unavailable intervals with the timezone of the employee:
https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/resource/models/resource_calendar.py#L589-L592 Whereas when we process fixed leaves, we return the unavailable intervals under utc:
https://github.com/odoo/odoo/blob/394a30f8a2814d460cfe220b5017e7ac95d8cddc/addons/resource/models/resource_calendar.py#L597-L601

This leads us to display problems: when the user is under European/ Brussels time in summer, the leave starts at 2 am and ends at 11pm, instead of starting at midnight.
Note: after discussion with AJU, it has been agreed that the behavior
should be the same on the Planning app.
__
opw-6030212

Forward-Port-Of: odoo/enterprise#117112
Forward-Port-Of: odoo/enterprise#112482

**Steps to reproduce:**
1. Install l10n_es_edi_verifactu.
2. Switch to a ES company.
3. Create a customer invoice and send it to VeriFactu.
4. Enable Developer Mode.
5. Go to Settings > Technical > Sequences & Identifiers > Sequences.
6. Search for the `Sequence Code: l10n_es_edi_verifactu` and open it.
7. Set a prefix or suffix using any alphabetical character.
8. Create a new invoice and send it to VeriFactu

**Issue:**
Traceback on sending Veri*Factu:
`ValueError: invalid literal for int() with base 10: 'F260001'`

**Cause:**
The value returned by `ir.sequence.next_by_id()` may contain alphabetical characters (due to prefix/suffix), while the field `chain_index` expects an integer. The raw sequence value was directly assigned, causing the conversion to fail.

**Fix:**
Catch the ValueError raised by int() when the sequence value contains non-numeric characters (e.g. due to a prefix/suffix). Instead of crashing, surface a user-friendly error on the document telling the user to remove the prefix/suffix from the sequence configuration.

**opw-6037528**

Forward-Port-Of: odoo/odoo#255473

When calling on a empty recordset action_mark_as_done, it creates a traceback.

**Observation**

When calling action_mark_as_done, the method first loops over each workorder to perform various safety checks, and then calls button_finish to close all workorders:
https://github.com/odoo/enterprise/blob/24008b550c5e7cf04cde2028c40f8a32d5b0e504/mrp_workorder/models/mrp_workorder.py#L881-L888 
Inside button_finish, it retrieves all open workorders and marks them as done:
 - Retrieve open workorders: https://github.com/odoo/odoo/blob/36a1c6300f52f408b6af3f769e26686e07810e5a/addons/mrp/models/mrp_workorder.py#L659 
 - mark them as done:
https://github.com/odoo/odoo/blob/36a1c6300f52f408b6af3f769e26686e07810e5a/addons/mrp/models/mrp_workorder.py#L675-L678

Returning to action_mark_as_done, it attempts to set the state to 'done' on the last workorder outside of the loop, referencing the loop variable:
https://github.com/odoo/enterprise/blob/24008b550c5e7cf04cde2028c40f8a32d5b0e504/mrp_workorder/models/mrp_workorder.py#L894 

-> If self is empty, the loop never executes. This leaves the loop variable empty, which ultimately triggers a traceback.

opw-6239910

Forward-Port-Of: odoo/enterprise#118718
Forward-Port-Of: odoo/enterprise#118403

**Steps to reproduce:**
* Install *Türkiye - Nilvera* (`l10n_tr_nilvera`) module.
* Log in as *admin user*.
* Create a *partner* for the company.
  * Set *country* as Turkey.
  * Configure required *taxes*.
* Create a *demo user*.
* Grant the demo user *Accounting admin access*.
* Log in with the *demo user*.
* Navigate to *Contacts* → open the *Turkey company partner*.
* Navigate to *Nilvera Status* (via Invoicing/Accounting tab) click on *Verify*.

**Observed behavior:**
* A *company access error* is raised during partner verification.

**Cause:**
* The field *l10n_tr_nilvera_api_key* is restricted with `groups='base.group_system'`, requiring full system admin rights.
* Users with *module-level admin access* (e.g., Accounting) do not have sufficient rights, causing the access error.

**Fix:**
* Use `sudo()` on `env.company` to bypass the restrictive group access.
* This allows users with appropriate *functional admin rights* to perform verification without granting full system privileges.

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

Forward-Port-Of: odoo/odoo#262668

Problem:
When selecting text containing `o_inline_code` and applying formatting such as bold, italic, or underline, the formatting cannot be removed.

Cause:
When applying formatting, nodes matching
`is_formattable_node_predicates` are ignored. However, when checking
whether the selection is already formatted, those nodes are not ignored,
so the selection is erroneously considered to be only partially
formatted.

Solution:
Take `is_formattable_node_predicates` into account when checking whether a selection is formatted.

Steps to reproduce:
- Go to To-Do → Create New.
- Type some text and add inline code on the same line.
- Select all content using Ctrl + A.
- Apply formatting such as bold, italic, or underline using keyboard shortcuts (Ctrl + B / Ctrl + I / Ctrl + U).
- Press the same shortcut again to remove the formatting.
- Observe that the formatting is not removed.

task-6229228

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

Forward-Port-Of: odoo/odoo#267455
Forward-Port-Of: odoo/odoo#265183

If expanding a line in the General Ledger report using a prefix group (defined on `prefix_groups_threshold`) users experience a crash due to a bad domain.

This bad domain is caused by a custom groupby key that is not a real field name, which causes the invalid domain name to be generated here https://github.com/odoo/enterprise/blob/e9a920d62a5894d8198fdbf2e35032de555d0bd7/account_reports/models/account_report.py#L5895-L5898

The solution adds mapping of the groupby names to the actual field names and adjusts `_report_expand_unfoldable_line_groupby_prefix_group()` to read the custom groupby keys from this mapping, thus creating valid domains.

This also changes the `forced_domain` to use `display_name` instead of `name` , allowing the lines to expand properly. https://github.com/odoo/enterprise/blob/da6ab7eedfa1b326cc6e01876dfff30e50a1c578/account_reports/models/account_report.py#L5896

Reproduction steps:
Runbot 18.4
Debug/Developer mode
Accounting -> General Ledger Report
Gear icon in top bar
Options -> Lower the prefix_groups_threshold to 1
Go back to the general ledger, try expanding some lines and see crash

**Only affects 18.4**

opw-6231127

**Steps to reproduce:**
1. Install l10n_es_edi_verifactu.
2. Switch to a ES company.
3. Create a customer invoice and send it to VeriFactu.
4. Enable Developer Mode.
5. Go to Settings > Technical > Sequences & Identifiers > Sequences.
6. Search for the `Sequence Code: l10n_es_edi_verifactu` and open it.
7. Set a prefix or suffix using any alphabetical character.
8. Create a new invoice and send it to VeriFactu

**Issue:**
Traceback on sending Veri*Factu:
`ValueError: invalid literal for int() with base 10: 'F260001'`

**Cause:**
The value returned by `ir.sequence.next_by_id()` may contain alphabetical characters (due to prefix/suffix), while the field `chain_index` expects an integer. The raw sequence value was directly assigned, causing the conversion to fail.

**Fix:**
Catch the ValueError raised by int() when the sequence value contains non-numeric characters (e.g. due to a prefix/suffix). Instead of crashing, surface a user-friendly error on the document telling the user to remove the prefix/suffix from the sequence configuration.

**opw-6037528**

Forward-Port-Of: odoo/odoo#255473

Currently when user adds adds quantity in barcode using lots it leads to incorrect sale order quantities.

## Steps to replicate:
- Install Sales and Barcode (no demo data).
- Enable Lots & Serial Numbers in settings.
- Create Test Product with Tracking by Lots.
- Go to Inventory > Products>Lots & Serial Numbers and create 3 lots for the product.
- Update each lot’s on-hand quantity to 10 from the product page.
- Create and confirm a Sales Order for the product (lines: qty 3 and 2 units).
- Open the delivery in the Barcode app:
   - Scan lot 2 > increase qty to 3 using +1 button
   - Scan lot 3 > increase qty to 2 using +1 button
- Validate and go to the sale order.

## Observed Behavior:
The sale order delivered quantities are flipped and a backorder is created even though the quantity for the product is satisfied.

## Root cause:
The issue occurs because when a sales order is confirmed, the system defaults to
 using lot 1 on the delivery receipt. When a user scans lot 2, the `_processBarcode` function is triggered, which calls `_findLine` at [1] to select the appropriate line on the receipt.

As the loop in `_findLine` iterates through `pageLines` with values like: 
```
[{display_name: "Test product", quantity: 3, lot_id: { name: 'lot1' }}, 
{display_name: "Test product", quantity: 2, lot_id: { name: 'lot1' }}]
```

During the first iteration, `foundLine` is set at [2] for the line with quantity 3 . Since the subsequent if condition is not satisfied, the loop hits the continue block at [3].
On the next iteration, the line with quantity 2 causes `foundLine` to be overwritten at [2], and the continue block is executed again at [3].

This results in the line with quantity 2 being selected as the line to update at the end of the function.

When the user manually increases the quantity to 3, the line that originally required quantity 2 is updated and fulfilled.
Later, when lot 3 is scanned, the line that required quantity 3 is selected for update, and manually increasing the quantity to 2 before validating the order leads to a backorder and causes the delivered quantities to be flipped.

[1]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1335-L1337 [2]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1690-L1699 [3]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1727-L1729

## Solution:
Avoid grouping lines from different moves unless using batch transfers. This ensures that backorders are not created when the barcode lines are fulfilled.

opw-5423943

Forward-Port-Of: odoo/enterprise#117722
Forward-Port-Of: odoo/enterprise#109032

### Issue:
When the company `tax_periodicity` is set to quarterly, the generated SII invoice JSON still uses the monthly period format

According to the documentation, the options for Periodo include distinction between monthly and trimester (p224 - 225):
https://sede.agenciatributaria.gob.es/static_files/Sede/Procedimiento_ayuda/G417/FicherosSuministros/V_1_1/SII-Descripcion-ServicioWeb-v1-1_es_es.pdf

### Cause:
The invoice JSON generation does not consider the company's `tax_periodicity`

This logic was probably omitted because `account_reports` may not be installed
However, when the periodicity is configured, the generated SII document should reflect it correctly

### Steps to reproduce:
- Install `l10n_es_edi_sii` and `account_reports`
- In Settings, set `Tax Periodicity` to `Quarterly`
- In Settings, set `Tax Agency for SII` to `Agencia Tributaria Española`
- Change ES Company vat number to `ESA12345674`
- Create an invoice (Date: 01/05/2026, Customer: ES Company)
- Open the generated JSON document
- Check the Periodo value, it should be 2T in May

opw-6050587

Forward-Port-Of: odoo/odoo#264063

Steps to reproduce:
------------------------------------
1. Install `ai` and `contacts` modules
2. Create an automation rule on Contact model:
    * Trigger: On Creation
    * Action To Do: Execute AI Action
    * Add a server action tool with 'Create Next Activity' action
    * Set Activity User Type to Dynamic
    * Set User Field to a dotted path (e.g., user_ids or partner_id.user_id)
3. Create a contact with a linked user

Observation:
------------------------------------
The activity description in the toast message fails to retrieve the user when using dotted field paths

Issue:
------------------------------------
The direct field access `record[self.activity_user_field_name]` in `_ai_get_action_description` method doesn't support dotted paths like 'partner_id.user_id'. This causes the same issue as in the mail module where relational field chains cannot be traversed

Solution:
------------------------------------
Use `record.mapped()` to support dotted paths by traversing the relational chain, consistent with the fix applied to the mail module

opw-6191715
Related Community PR: https://github.com/odoo/odoo/pull/263530

**Steps to reproduce:**
- Install Accounting and l10n_ro_edi
- Switch to a Romanian localization (e.g. RO Company)
- Configure Romanian E-Factura

- Create an invoice with a product having a name longer than 100 chars
- Confirm the invoice
- Send E-Factura to SPV
- Fetch E-Factura status

**Issue:**
The invoice is rejected with the following error:
"[BR-RO-L100]-The allowed maximum number of characters for the Item name (BT-153) is 100."

**Similar issue with the product description:**
"[BR-RO-L200]-The allowed maximum number of characters for the Item description (BT-154) is 200."

**Similar issue with the note (i.e. Terms and Conditions):**
"[BR-RO-L300]-The allowed maximum number of characters for the Invoice note (BT-22) is 300."

**Solution:**
Truncate the name of the product to 100 chars in the electronic invoice, the description of the product to 200 and the note to 300.

opw-5964904




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

Steps to produce:
---
- Install the `Accounting` module.
- Create several invoices for a portal user with different payment states (e.g., In Payment, Not Paid, Paid).
- Log in as the portal user.
- Navigate to the invoices list and attempt to sort by **Status**.

Issue:-
---
- Sorting by **Status** does not reflect the actual invoice payment status, resulting in incorrect ordering.

Root cause:
---
- At [1], the sorting field for Status is set to state, which corresponds to invoice states (Draft, Posted, Cancelled). However, the portal displays and expects sorting based on payment_state.

Fix:
---
- Update the sorting configuration to use payment_state instead of state,
  ensuring that invoices are sorted correctly according to their payment
  status on the portal.

[1]https://github.com/odoo/odoo/blob/5b85287ec4ea9f1b51e0f33402900777dfeeb725/addons/account/controllers/portal.py#L46-L52

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

Forward-Port-Of: odoo/odoo#262976

When creating a calendar event by dragging on the calendar view, modifying the end time in the quick-create popover, and then clicking "More Options", the duration shown in the full form is the original drag value instead of the value implied by the user's updated stop.

calendar's makeContextDefaults seeds default_start, default_stop, default_duration, and default_allday from the drag extent. In the quick-create popover, changing stop triggers _compute_duration on that record so its duration becomes correct. On "More Options", goToFullEvent extracts a whitelist of fields from the quick-create record as default_X and merges them with the original drag context.

https://github.com/odoo/odoo/blob/c82341c503ac/addons/calendar/static/src/views/calendar_form/calendar_quick_create.js#L9-L19

duration is missing from that whitelist, so the merged context still carries the stale default_duration from the drag. In the full form, that default is applied to the duration field and _compute_duration does not run because a default was provided for a stored, writable field.

Adding duration to the whitelist forwards the quick-create's recomputed value as default_duration so the full form opens with the correct duration.

Steps to reproduce:
1. Open Calendar, drag to create a 2-hour event (e.g. 10:00-12:00)
2. In the quick-create popover, change the end time to 14:00
3. Click "More Options"
4. Check the Duration field in the full form

=> Duration shows the original drag value (02:00) instead of 04:00

opw-6087449

Forward-Port-Of: odoo/odoo#257294

Problem:
When the selection is inside a `contenteditable="true"` element that is not the root editable, focusing away does not trigger a save.

Cause:
When the DOM contains a nested contenteditable structure like:

```html
<div class="odoo-editor-editable" contenteditable="true">
  abc
  <div contenteditable="false">
    ac
    <div contenteditable="true">a</div>
  </div>
</div>
```

With the selection inside the inner `contenteditable="true"`, the `blur` event is not triggered on `.odoo-editor-editable` when focusing away, because the active element is the inner div and `blur` does not bubble.

Solution:
Replace the `blur` listener with `focusout`, which bubbles from the inner `contenteditable="true"` up to `.odoo-editor-editable`, allowing `onBlur` to be called correctly.

Steps to reproduce:
- Open Project > Task.
- Add a `/column` block in the description.
- Focus inside any column and write some text.
- Click away to change tab.
- Reopen the description tab.
- The latest changes inside the columns were not saved.

opw-6227922

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

### Description of the issue/feature this PR addresses:

getLocalYearAndWeek is used to get the year and week number for a given date. When a week overlaps 2 years, the week number is taken based on the year where the week has most days.

So if a week has 5 days in year Y and 2 in Y+1. The week is taken counting from Y (probably week 53). If a week has 3 days in Y and 4 in Y+1, then the week number is reset to 1.

The year, however did not follow the same logic, and was taken as the year of the last day of the ISO week.

### Current behavior before PR:

At the end of 2026, this will cause problems because the week number will run as:

* 2026, week 52 (all days in 2026, OK)
* 2027, week 53 (most days in 2026, last day in 2027, Not OK)
* 2027, week 1 (all days in 2027, OK)

### Desired behavior after PR is merged:

This commit aims to solve this issue by following the same logic for week number and year, so that the end of 2026 will go as:

* 2026, week 52 (no changes)
* 2026, week 53 (year is not incremented if week number is not reset)
* 2027, week 1 (no changes, but year is incremented when week number is reset)

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

This PR is one of many triggered by responses from Luxembourg auditors. See PR #113316 for a full list of these PRs.

As described in PR #117799, the \CustomerID and \SupplierID elements on \Transaction\Line elements is determined by a partner's `customer_rank` and `supplier_rank`.  This is a binary designation, one or the other.

The Luxembourg FAIA report requires that less than 30% of \Transaction\Line elements with payable accounts (class 6) can not have \SupplierID. The same applies for \Transaction\Line elements with receivable accounts (class 7) and the \CustomerID element.

TSB clarified that any partner on an receivable or payable line should be added to the Customer list or Supplier list respectively https://github.com/odoo/enterprise/pull/100749#issuecomment-3655127511. In addition, I verified that Luxembourg's analysis of four separate FAIA files (from ticket 5427296) aligns with this expectation. 

<img width="1322" height="690" alt="image" src="https://github.com/user-attachments/assets/1a82f99e-5b32-4dbb-96e1-1b25bab2629b" />

This commit adds partners to the \Supplier and \Customer lists if they have any payable or receivable lines, respectively. It also picks between the \CustomerID and \SupplierID based on a line's `account_type`. This logic is applied to `account_saft` and updates the other, country-specific SAFT reports where appropriate. 

It also retains the previous `customer_rank` and `supplier_rank` logic as a fallback for older XML reports and for accounts other than `asset_receivable` or `liability_payable`.

opw-6118024