**Issue**:
Billing a PO containing kit with several components can lead to incorrect
valuation of its components

**Steps to reproduce**:
- Create a kit product (by creating a BOM with 2 components) with AVCO valuation
- Create a PO for 1 unit at unit price 10
- Confirm PO and validate the receipt
- Go to the BOM of the kit product and check BOM overview
-> The cost of the two components are 5, which is correct
- Go to Accounting > Vendors > Bill
- Create a new bill by indicating the PO in "Auto-Complete" field and validate
- Go back to the BOM of the kit product and check BOM overview
-> The cost of the two components are 10, which is correct

This also occurs with FIFO valuation

**Cause**:
While computing the value of the move:
https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L282
https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L313-L314
It checks the value of the Bill:
https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L357-L358
Which relies directly on the AML price of the kit:
https://github.com/odoo/odoo/blob/a2b3a10255dba290ea462b9193ae11c54d8dd5e0/addons/purchase_stock/models/stock_move.py#L170
This ignores the `cost_share` of each BOM component. As a result,
each component receives the full kit value instead of its proportional
share

This means that the value of the move is 10 instead of 10/2=5, which makes the valuation computation wrong:
https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/product.py#L393

**Aditionnal note**
The computation of the quantity is also incorrect:
https://github.com/odoo/odoo/blob/a2b3a10255dba290ea462b9193ae11c54d8dd5e0/addons/purchase_stock/models/stock_move.py#L169
since it assumes the quantity of component of the kit is the same than the quantity of the kit itself,
which is not true in the general case.

opw-5924940

Forward-Port-Of: odoo/odoo#249264

`l10n_mx_edi_pos` is now populating `pos_order_ids` [1]. l10n_mx_edi_pos is designed to send POS data into MX EDI without giving accounting users direct access to pos.order. So, we should consider that in this module we won't have access to:

- `pos_order_ids` m2m on `l10n_mx_edi.document` (caused problems before [2])
- `pos_order_ids` o2m on `account.move`
- `pos.order` model

We add a minimal `sudo()` in
`_create_update_invoice_document_from_invoice` to be able to read from the `pos_order_ids` field on `account.move`:

```
  File "/e19-1/l10n_mx_edi/models/account_move.py", line 1551, in _l10n_mx_edi_cfdi_invoice_document_cancel
    return self.env['l10n_mx_edi.document']._create_update_invoice_document_from_invoice(self, document_values)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/e19-1/l10n_mx_edi_pos/models/l10n_mx_edi_document.py", line 54, in _create_update_invoice_document_from_invoice
    if invoice.pos_order_ids:
       ^^^^^^^^^^^^^^^^^^^^^
  File "/c19-1/odoo/orm/fields_relational.py", line 967, in __get__
    return super().__get__(records, owner)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/c19-1/odoo/orm/fields_relational.py", line 45, in __get__
    return super().__get__(records, owner)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/c19-1/odoo/orm/fields.py", line 1743, in __get__
    recs._fetch_field(self)
  File "/c19-1/odoo/orm/models.py", line 3015, in _fetch_field
    self.fetch(fnames)
  File "/c19-1/odoo/orm/models.py", line 3055, in fetch
    fetched = self._fetch_query(query, fields_to_fetch)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/c19-1/odoo/orm/models.py", line 3193, in _fetch_query
    field.read(fetched)
  File "/c19-1/odoo/orm/fields_relational.py", line 985, in read
    raise AccessError(records.env._("Failed to read field %s", self) + '\n' + str(e)) from e
odoo.exceptions.AccessError: Failed to read field account.move.pos_order_ids
You are not allowed to access 'Point of Sale Order' (pos.order) records.

This operation is allowed for the following groups:
        - Inventory/User
        - Point of Sale/User
```

Afterwards `_create_update_document` in `l10n_mx_edi` will create or write this `pos_order_ids` value on the document without `sudo()`:

```
  File "/home/jvo/Code/odoo/trees/e19-1/l10n_mx_edi/models/account_move.py", line 1551, in _l10n_mx_edi_cfdi_invoice_document_cancel
    return self.env['l10n_mx_edi.document']._create_update_invoice_document_from_invoice(self, document_values)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jvo/Code/odoo/trees/e19-1/l10n_mx_edi_pos/models/l10n_mx_edi_document.py", line 56, in _create_update_invoice_document_from_invoice
    return super()._create_update_invoice_document_from_invoice(invoice, document_values)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jvo/Code/odoo/trees/e19-1/l10n_mx_edi/models/l10n_mx_edi_document.py", line 1969, in _create_update_invoice_document_from_invoice
    document = remaining_documents._create_update_document(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jvo/Code/odoo/trees/e19-1/l10n_mx_edi/models/l10n_mx_edi_document.py", line 1936, in _create_update_document
    result_document = self.create({
                      ^^^^^^^^^^^^^
  File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/decorators.py", line 365, in create
    return method(self, vals_list)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/models.py", line 4021, in create
    records = self._create(data_list)
              ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/models.py", line 4253, in _create
    field.create([
  File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/fields_relational.py", line 760, in create
    self.write_batch(record_values, True)
  File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/fields_relational.py", line 786, in write_batch
    self.write_real(records_commands_list, create)
  File "/home/jvo/Code/odoo/trees/c19-1/odoo/orm/fields_relational.py", line 1559, in write_real
    raise AccessError(model.env._("Failed to write field %s", self) + "\n" + str(e))
odoo.exceptions.AccessError: Failed to write field l10n_mx_edi.document.pos_order_ids
You are not allowed to access 'Point of Sale Order' (pos.order) records.

This operation is allowed for the following groups:
        - Inventory/User
        - Point of Sale/User
```

We therefore take out `pos_order_ids` in an override and write it ourselves with another minimal `sudo()`.

[1] https://github.com/odoo/enterprise/pull/97060
[2] https://github.com/odoo/enterprise/pull/99590

opw-6000974

**Steps to reproduce:**
1. Configure Working Hours: Set up a night-shift schedule that splits at midnight (Local Time):
- Thursday: 20:00 to 24:00
- Friday: 00:00 to 04:00
2. Assign the above calendar to an employee.
3. Set the Employee’s Timezone to Asia/Kolkata (UTC+5:30).
4. Assign an active Overtime Ruleset to the employee.
5. When the attendance calendar is in Europe/Brussels TZ 
- Check-in: Jan 15, 15:30 CET
- Check-out: Jan 15, 23:30 CET

Expected Behavior: Worked Hours = 8.0, Overtime (Extra Hours) = 0.0 
Actual Behavior (Bug): Worked Hours = 8.0, Overtime = 4.0

**Bug Cause:**
1. The _update_overtime function normalized the Ruleset version periods using time.min for both the start and end of the day.
This forced the validity period of the rules to end exactly at 00:00:00 UTC on the final day.
2. The overtime recalculation logic failed to delete existing overtime records because the search domain was incorrectly computed.
Specifically, using relativedelta(SU) and relativedelta(MO(-1)) without the weekday= keyword argument did not shift the dates to the week boundaries.
This resulted in an empty or incorrect deletion range, leading to duplicated overtime hours as new records were layered on top of un-removed old ones.

**Solution:**
1. Modified the version_periods_by_employee mapping to use time.max (23:59:59) for the end of the version period.
This ensures that the ruleset remains active through the entire final calendar day in UTC, allowing shifts that cross the midnight boundary to be fully captured.
2. Corrected the date range logic by explicitly passing the weekday argument to relativedelta.
This ensures the domain correctly targets the full week window - from the preceding Monday to the following Sunday, ensuring all relevant stale overtime lines are purged before recalculation.
3. Updated Manual Edit Handling: Refined the logic to detect days with manual overrides or "To Approve" statuses before unlinking. If an attendance change triggers a recalculation on such a day, the system now replaces the manual entry with the mathematically correct value but flags the new record with a to_approve status for manager review.
4. Adjusted the expected overtime in test_weekly_overtime to 18.0 to correctly reflect the cumulative calculation of daily overtime (2h/day) plus the weekly overtime threshold reached on Friday.

Task: 5710273

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

**Description of the issue this PR addresses:**
----------------------------------------------
Some livechat demo sessions included feedback/ratings but were still
displayed as active conversations in the info side panel. This created
inconsistent demo data where closed conversations appeared with options
meant for ongoing chats (e.g., status shown instead of outcome).

**Current behavior before PR:**
----------------------------------------------
- Certain demo livechat sessions had ratings applied but no explicit livechat_end_dt set.
- As a result, the info side panel treated them as ongoing conversations.
- This caused mismatched UI information for demo data.

**Desired behavior after PR is merged:**
----------------------------------------------
- Demo livechat sessions that received feedback are explicitly marked as ended using livechat_end_dt.
- The info side panel correctly reflects closed conversations with coherent outcome information.

Task-5412081

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

Forward-Port-Of: odoo/odoo#250001

## Description

There was a desync issue with popup states between normal mode and edit mode. That caused:
- Hidden popups contributed extra dropzones during drag-and-drop
- Hidden popups lost `d-none` class after dropping unrelated snippets

## How to reproduce

### Bug 1: extra dropzones from hidden popup desync
1. Enter website edit mode.
2. Drop popup in the page
3. Drag another snippet as you were adding it to the page
4. An additional dropzone appears below the invisible popup snippet

### Bug 2: hidden popup loses `d-none` class
1. Enter edit mode.
2. Drop a popup.
3. Close it so `.s_popup` gets `d-none`.
4. Drop any other snippet on the page arbitrarily.
5. Popup loses `d-none` class.

## Expected behavior after fix

- Popup hidden/shown state remains stable across editor refreshes and
snippet drops.
- Drag-and-drop no longer creates extra dropzones from hidden popups.

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

Forward-Port-Of: odoo/odoo#251517
Forward-Port-Of: odoo/odoo#250625

An error is generated in the logs when a user opens a record after saving a computed field used in the domain, as demonstrated in the steps below.

Step1:
- install `crm` and `base_automation`
- Create a new automation rule for the `Activity` module and set the `Apply On` domain as below: `[("res_model", "=", "crm.lead"), ("state","=","done")]`
- An error will occur in the log when you open this record.

Step 2:
- Install `mass_mailing`
- Go to Email Marketing and create a record as below data
    - Recipients: `Contact`
    - Set domain as `[("vat_label", "=", 'test')]`
- An error will occur in the log when user open this record.


This issue occurred because the recently refactored commit [1] used `validate` of Domain for the domain instead of `search_count`. The `validate` method only checks the structure of the domain and does not verify whether the domain is actually executed or not.

This commit fixes the issue by reverting commit [1], restoring the previous behavior where the domain is evaluated using `search_count`.

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

sentry-7004977102

When a user sets the inventory quantity to 0 on a quant while
the product’s Inventory Location is unset, a traceback is raised.

Steps to reproduce the error:
- Install ``stock`` module with demo data
- Open ``Cabinet with Doors`` product
- In Inventory tab, unset Inventory Location > Open forecast report > click the On Hand quantity
- Select the quant > Actions > Set to 0

Traceback:
```py
ValueError: NotNullViolation('null value in column "location_dest_id"
of relation "stock_move" violates not-null constraint
```

https://github.com/odoo/odoo/blob/bc790e13ddf3ceacead40cc6ff8d27f1a5f5364d/addons/stock/models/stock_quant.py#L1005-L1016
When property_stock_inventory is unset,
the ``_get_inventory_move_values`` method assigns a NULL value to ``location_dest_id`` in ``move_vals``.
As a result, creating the stock move with a NULL ``location_dest_id`` leads to the above traceback.

sentry-7117991902

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

Forward-Port-Of: odoo/odoo#245245

# How to reproduce
- A reverse proxy needs to be set up between the client and the backend (for localhost, you can use nginx)
- This reverse proxy needs to have a request max body size set below 128mb (for nginx : client_max_body_size)
- If the system parameter web.max_file_upload_size is set, delete it and refresh your page
- Pick any form view and add a file field with studio
- Upload a file larger than the limit set in the proxy, but smaller than 128mb
- Save the form

# The problem
The form is not saved and depending on the version, a Traceback will be shown (18.X) or a Connection Lost notification will be shown for a short period of time (19.0+)

# Why
When the system parameter web.max_file_upload_size is not set, the check for file size uses the default 128mb. A binary field added to a form via studio will upload its file in the json of the post request. This is done by encoding the file in base64. Our nginx servers set a limit for the request body size (usually 64mb).

So if you add a file between 64mb and 128mb, it will bypass the default front-end size check but be stopped by the nginx reverse proxy. The proxy will send back an HTTP response with error code 413 to the client. Theses http responses are not correctly handled by the framework and are interpreted as a Connection Lost error because the response content cannot be parsed to json.

Additionally, since we use base64 for the encoding and then use gzip to compress the json request, it's not really feasible to synchronize the front-end limit with the nginx one.

opw-5891662

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

Forward-Port-Of: odoo/odoo#252325
Forward-Port-Of: odoo/odoo#249025

### Issue:
When in the Gantt view of service projects, grouping by project results in a traceback.

### Steps to reproduce:
- Create another field service project 
- Create a task in the new project and add start and end dates
- Go to Field service > my tasks > gantt view > group by project 
- Error with traceback `time data 'today' does not match format '%Y-%m-%d %H:%M:%S'`

### Cause:
This [commit](https://github.com/odoo/odoo/commit/d1ea43f6721116914762ea323d8a5987f043e87f) added the possibility to use dynamic dates in domains. Then all domains were changed in 42b1fca8e127926a06f503d79c8baeddf7d5ae82

But `_expand_domain_dates()` is trying to parse the dates as if they were written in ISO format:

https://github.com/odoo/enterprise/blob/be853cc1ee544dda580960d94417cfdff2c8a7db/project_enterprise/models/project_task.py#L626

### Solution:
We use the method `parse_date()`, which was added with dynamic dates, to parse them.

opw-5955317

Forward-Port-Of: odoo/enterprise#109236

****Behavior:****
**Current:**
In a multi company environment, when a sale contains multiple tasks in some project, and the user has billing rates indicating they should be assigned to a specific task, creating a new timesheet for the project does not set the correct SOL. This only happens if the sale is happening from a company that does not have an employee linked to the user.

**Expected:**
The new timesheet should be able to connect the current user to the related employee in the billing rates to find the right SOL. In the situation in which multiple companies have created an employee for the same user, and more than one of these has been linked to a SOL in the billing rates (unlikely workflow): We choose the SOL linked to the employee record created for the currently activated company, otherwise, we default to the first employee in the list.

**Steps to reproduce:**
- Be in a multicompany environment: company A and B
- Create User with access to both but only one employee record for company A
- Switch to company B
- Create 2 services product, both creating a task in the same project.
- Activate Billable Rate Indicators in the settings
- Create a quote with both services and confirm
- Go to the related project, and in the Invoicing tab, link employee from company A to SOL2
- As the user, check both companies but set company B as current active
- Go to timesheet and create a new timesheet, when setting the project from the quote, you should see SOL1 by default, however we would want SOL2 as it was configured.

opw-5159195

Forward-Port-Of: odoo/odoo#234200

# How to reproduce
- Use a browser extension to manage your browser's timezone
- Set your browser's timezone to a timezone with quite a big delay (like "America/Grand_Turk" if you live in Europe)
- Go to the form view of an opportunity
- Click on the smart button for meetings (Should be "No Meeting" if it is a new Opportunity)
- In the calendar view, add a new meeting for very late in the day (Example : 2026-02-10 22:00:00 => 23:00:00)
- Go back to the opportunity for view

# The problem
The date displayed is a day after the meeting that was just set up. Taking back our example, the date displayed would be 2026-02-11

# Why
The calendar view uses the browser's timezone to manage the dates. The smart button does not.

It is not possible to make the smart button use the browser's timezone, atleast in a clean way. That is because the smart button's data is managed by a python template, which does not have access to the browser's data. Trying to change the data displayed by the framework would be clunky as the html would need to be edited directly.

The fix that I implemented follows what the hr_appraisal module does for it's smart button with a date: use the timezone set in the user's preferences.

opw-5898520

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

Forward-Port-Of: odoo/odoo#251840
Forward-Port-Of: odoo/odoo#247984

__

## Short functional explanation of the error
When setting the start date for a time off allocation to the previous year, it is not taken into account when computing the count of employee allocations on the time off type page.

## Reproduction Steps
1. Go to Time off > Configuration > Time off Types and click on any time off type.
2. A smart button Allocations should appear with a number in it. Note the number and click on the button.
3. If no allocation exists yet, create one. Otherwise, click on an already existing allocation.
4. Set the start date of the validity period to any date last year. Set the ending date so that the allocation is still valid as of now.
5. Go back to the Time off type page and look at the number on the Allocations smart button.

### Expected behavior
As the allocation we set is still valid, the number shouldn't have changed.

### Unexpected behavior
The allocation number has been decreased. However, when we click on the smart button, the same number of valid allocations will show. This creates an inconsistency between the smart button and the allocation page, as the smart button should show the number of valid allocations, and when landing on the allocation page, the results are automatically filtered by validity.

## Origin of the issue
The domain of the allocations to take into account when computing the count of valid allocations is defined here:
https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/hr_holidays/models/hr_leave_type.py#L297-L304 This doesn't take into account valid allocations that started during the previous year.
The inconsistency with the allocation page can be seen here: https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/hr_holidays/views/hr_leave_allocation_views.xml#L40-L46 Where the filter is defined based on today, rather than on the whole year, unlike above.
__
opw-5504272

Forward-Port-Of: odoo/odoo#250992
Forward-Port-Of: odoo/odoo#248482

Steps to reproduce:
1. Add a Dynamic Snippet Carousel(Products).
2. Set the number of records to 4.
3. Enable Single Scroll mode.

Issue:
When a dynamic snippet carousel is in single scroll mode
(`o_carousel_multi_items`) and the number of fetched items is less than
or equal to the visible slots per slide (`chunkSize`,
typically 4 on desktop), the carousel still slides one item at a time.

Cause:
When `scrollMode` is single, the QWeb template generates each data item
in its own `carousel-item` div. So with 3 products and 4 visible slots,
we got 3 separate slides(this is the usual behavior of single scroll
mode). But due to this bootstrap would slide between them one by one.

Fix:
If the number of fetched records is less than or equal to the number of
elements per slide (chunkSize), use "all" scroll mode so that all items
are grouped in a single slide instead of being split into individual
carousel-items (which would cause unwanted sliding).

Forward-Port-Of: odoo/odoo#251916
Forward-Port-Of: odoo/odoo#251700

# Steps to reproduce:
* Enable **Developer Mode**.
* Go to **Accounting → Configuration → Accounting → Accounting Reports**.
* Create a new report and enable **Composite Report**.
* Add a new line of type **Journal Report**.
* Save the report and create a menu item from the gear icon.
* Open the report from the reporting menu.
* Try to download the report in **PDF** format.

# Observed behavior:
* PDF export fails with a traceback.
* Composite reports containing journal report sections cannot be exported as PDF.

# Cause
When exporting a composite report to PDF, the export flow iterates over each embedded sub-report and generates the HTML body used for PDF rendering.

* The composite export relies on the base [`export_to_pdf`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_report.py#L5875) implementation from `account.report`, which directly calls `_get_pdf_export_html()` for each sub-report.

* For standard reports, this works as expected because they use the base [`_get_pdf_export_html`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_report.py#L5944) method, which renders flat report lines into the default PDF template.

* Journal reports, however, rely on a completely different PDF structure. Their templates expect `document_data` (journal entries grouped by journal/document) instead of flat report lines.

* This `document_data` is generated exclusively by the journal report’s custom handler via its own [`export_to_pdf`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_journal_report.py#L240) flow.

* The handler builds the required `document_data` using [`_generate_document_data_for_export`](https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/account_reports/models/account_journal_report.py#L261C9-L261C22).

* When a journal report is embedded inside a composite report, the composite export logic bypasses the custom handler and forces the report through the base `_get_pdf_export_html()` pipeline.

* Since the base pipeline does not generate `document_data`, the journal report PDF template fails at render time with `KeyError: 'document_data'`.

In short, journal reports embedded in composite reports were incorrectly routed through the standard PDF export pipeline instead of their specialized handler-based one.



# Fix:
* Add PDF export support to the journal report custom handler.
* Centralize common print option logic in a shared helper.
* Update composite report export logic to delegate PDF generation to custom handlers when available.
* Journal reports inside composite reports now export to PDF correctly.

opw-5477551

Forward-Port-Of: odoo/enterprise#109790
Forward-Port-Of: odoo/enterprise#105040

Creating a POS order with negative quantity to manually refund a product (without using the Refund action, e.g. when the original order is not in the POS) and then requesting an invoice produced a customer invoice (INV) instead of a credit note (RINV).

Steps to reproduce:
-------------------
* Open a POS session.
* Create a new order (do not use "Refund" from an existing order).
* Add a product with negative quantity to simulate a manual refund.
* Set a customer and request an invoice for the order.
* Pay the order (negative amount).

> Observation:
The system creates a customer invoice (INV) instead of a credit note (RINV).

Why the fix:
------------
* Invoice type was decided only from the `is_refund` flag, which is set only when the order is created via the Refund action. Manual refunds (negative qty) never had `is_refund` set, so they were treated as sales and got `out_invoice`.
* `_prepare_invoice_vals` now treats an order as a refund when `is_refund` is True or `amount_total < 0`, so `move_type` is `out_refund` for manual refunds and a RINV is created.
* `_get_invoice_lines_values` now uses the same condition (`is_refund or amount_total < 0`) to compute `is_refund_order` for the quantity sign. That way invoice lines keep positive quantities and the credit note has a positive total.

opw-5898700

Forward-Port-Of: odoo/odoo#248791

Steps to reproduce:
---------------------------
1. Install the `project_account_budget` and `account_accountant` modules.
2. Create a new project and add an Analytic Account for it from the settings page
3. Open the Project Kanban, click the three dots on the project card, and select Project's Updates.
4. Click Add Budget button and open the budget wizard.
5. Add a budget line in the wizard with a planned amount expressed as a negative value for an expense (for example: -10000).
6. Create a Vendor Bill using the same analytic account with an amount of 1000.
5. Confirm the bill.
6. Go back to Project's Updates and click New button to view the budget summary.

Observation:
---------------------------
The budget summary displays incorrect signs and percentages in Activities summary, for example:
```
-10.0% (-1,000.00) of the -10,000.00 budget has been spent. 110.0% (-11,000.00) of the budget is remaining.
```
This incorrectly shows -10% spent and 110% remaining instead of 10% spent and 90% remaining (-9,000).

Issue:
---------------------------
The project cost (already negative) was negated again when computing the spent amount in
https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/project_account_budget/models/project_update.py#L16 Double-negating the cost makes it positive, which then gets added to the expense budget instead of reducing it, producing inverted percentages and signs.

Solution:
---------------------------
For expense budgets (negative budgets), do not apply an extra negative sign when calculating the project cost so the spent, remaining, and percentage values are computed correctly.

After the fix:
```
10.0% ($ 1,000.00) of the $ -10,000.00 budget has been spent. 90.0% ($ -9,000.00) of the budget is remaining.
```

opw-5357854

Forward-Port-Of: odoo/enterprise#109880
Forward-Port-Of: odoo/enterprise#102126

Currently some providers require a customer to be registered on the order because the email address needs to be sent with the request. We the order does not have a customer the payment cannot be made using that provider.

Step to reproduce:
------------------
- Set up Amazon payment services on a online pos payment method
- Set this method as the online payment method for a self and also set is as payment method of the pos
- Place an order in the self or without a customer on the normal pos
- Try to pay it
> Observation: When the page is redirected to provider's checkout page,
an error occurs: Signature mismatch

Why the fix:
------------
On a normal pos shop we are simply ensuring that a customer with an address mail is registered on the order if the provider of an online payment method requires customer identification.
- When selecting the payment method on the payment screen if the payment method is online, requires customer identification and there's no customer on the order, the validate order button will be unavailable and the customer button is highlighted.
- When there is a customer the validate button is highlighted
- When validating the order if the customer does not have an email it will not go through and warn the cashier that the customer needs an email. This behavior is similar to the present "Delivery" which, if the cashier disregarded all popups, will not have the validate button available until a cashier is registered. Also if the selected customer doesn't have an address it will show a popup upon validation.

We are not doing anything regarding the self order as using presets like "Delivery" is compatible since the information required filled by the customer creates a partner in the db and sets it on the order. This preset ensures we always have a partner.

Other preset don't but we don't want to block flows that are currently working.

The list of providers requiring customer identification can be extended.

opw-5406501

Forward-Port-Of: odoo/odoo#245016

When the product category valuation is set to `real_time` but the
company is set to `periodic`, the POS session closing was not posting
COGS entries as expected. If the product category valuation is set to
`real_time`, it should always prevail over the company setting. And if
no valuation is set on the product category, then the company setting
should be used.

Steps to reproduce:
-------------------
* Create a product category with `Inventory Valuation` set to
  `real_time` (Perpetual).
* Create a product in this category and make sure it is storable and has
  a cost price.
* Set the company `Inventory Valuation` to `periodic` (Periodic).
* Create a POS order with this product and pay it.
* Close the POS session.
> Observation: In the session no COGS entries are created for the sold
  product.

Why the fix:
------------
We adapt the `_search_valuation` to correctly fallback on the company
setting only if the product category valuation is not set. It was not
working before because in some cases the product had no company set
(it means that it is visible to all companies) and the domain was not
matching. To fix that we check that the current company matches the
search value, and if it does we also match all the products without
company set.

We also adapt the PoS code to use the `product_id.valuation` field to
filter all the stock_moves that should create COGS entries when
closing the session.

opw-5885960

Forward-Port-Of: odoo/odoo#247011

**Step to reproduce:**
1. Install `sale_management`
2. Open any email template (e.g., Sale: Order Confirmation).
3. Add an attachment to it
4. Create a Sale Order, confirm it, and click "Send by Email".
5. In the mail composer, remove the template attachment

**Issue:**
- The removed attachment is deleted from the database (`ir.attachment`). Consequently, the attachment is permanently removed from the source Email Template and will not appear in future emails.

**Cause:**
- The `onFileRemove` function in `MailComposerAttachmentList` calls the `unlink` method of the `attachmentUploadService` for every file removed, without considering the existing template attachment.

**Solution:**
1. Update `mailComposerAttachmentList` to include `res_model` in `relatedFields` so it is fetched from the server.
2. In `onFileRemove`, check the `res_model` of the attachment.
3. If the `res_model` is not "mail.compose.message", skip the database deletion (unlink)
   and only remove it from the composer view.

opw-5163679

Forward-Port-Of: odoo/odoo#249257
Forward-Port-Of: odoo/odoo#238692

### Issue:
When having a part-time flexible employee (`hours_per_week` < `full_time_required_hours`), some values still show `full_time_required_hours` as the total hours they should work in a week.

### Steps to reproduce:
- Have an employee with a part-time flexible schedule
    - `full_time_required_hours`: 40
    - `hours_per_week`: 24
    - `hours_per_day`: 8
- Go in Attendances
- Hover the employee
- It shows ...h/40h but it should show ...h/24h

### Cause:
In `_attendance_intervals_batch()` we build theoretical attendances for flexible employees. Starting at the start of the week, we add an attendance of `hours_per_day` each day until we reached `full_time_required_hours`.

In the case above, we would return five attendances of 8h, ignoring `hours_per_week`.

Then `_get_attendance_intervals_days_data()` counts the hours to display them in the Gantt view.

### Solution:
In `_attendance_intervals_batch()` we use `hours_per_week` instead of `full_time_required_hours` as the weekly limit of hours per week.

A lot of tests needed to be adapted, as they were specifying `full_time_required_hours` but not `hours_per_week` when creating calendars.

opw-5973117

Forward-Port-Of: odoo/odoo#252190

### Issue:
When having a part-time flexible employee (`hours_per_week` < `full_time_required_hours`), some values still show `full_time_required_hours` as the total hours they should work in a week.

Steps to reproduce:
- Have an employee with a part-time flexible schedule
    - `full_time_required_hours`: 40
    - `hours_per_week`: 24
    - `hours_per_day`: 8
- Go in Attendances
- Hover the employee
- It shows ...h/40h but it should show ...h/24h

Cause:
In `_attendance_intervals_batch()` we build theoretical attendances for flexible employees. Starting at the start of the week, we add an attendance of `hours_per_day` each day until we reached `full_time_required_hours`.

In the case above, we would return five attendances of 8h, ignoring `hours_per_week`.

Then `_get_attendance_intervals_days_data()` counts the hours to display them in the Gantt view.

Solution:
In `_attendance_intervals_batch()` we use `hours_per_week` instead of `full_time_required_hours` as the weekly limit of hours per week.

A lot of tests needed to be adapted, as they were specifying `full_time_required_hours` but not `hours_per_week` when creating calendars.

opw-5973117

Forward-Port-Of: odoo/enterprise#109645