Steps to reproduce:
=================
1. Go to eLearning > Courses and create a published course
2. In the Description tab, add a button with a link and save
3. Go to /slides on the website
4. The course card appears with a grey overlay (0.5 opacity)

=> Published course cards with a button in the description show a grey overlay
=> Only unpublished course cards should have the grey overlay

Cause:
======
In [1], the opacity for unpublished courses was moved from `.o_wslides_course_unpublished` to its container using a `:has()` selector. However, the selector `div:has(> .card + .card-body, ...)` was too broad: it matched any container whose `.card` child had a sibling `.card-body`, regardless of whether the course was unpublished.

When a course description contains a button (or any block-level element), the browser renders the button outside the `.card` element. This creates the structure `div > .card + .card-body` that the selector matches, applying a 0.5 opacity grey overlay to fully published courses.

Solution:
========
The fix restricts the first selector arm to only match when `.o_wslides_course_unpublished` is the sibling, ensuring published courses with buttons in their descriptions are not affected.

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

opw-5900287

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

Forward-Port-Of: odoo/odoo#258700

**Description of the issue/feature this PR addresses**:
web_read on x2many fields can reuse cached ids after write/web_save. Some of these cached ids may be inaccessible with the current record rules/context (cache pollution).

**Example**:
- **Context**:
  - Two companies exist: Company A and Company B.
  - Two users exist: User A and User B.
  - User A can only access Company A (company_ids=[A], company_id=A).
  - User B is linked to both companies (company_ids=[A, B], company_id=A).
  - The "res.company" record rule is the standard one: [('id', 'in', company_ids)] (company_ids comes from allowed_company_ids).
  - User A edits User B and saves the form.

- **Steps**:
  - User A performs a web_read to load User B: company_ids contains only Company A.
  - User A performs web_save (write + internal web_read in the same request): cached ids [A, B] are reused and the code attempts to read Company B.

**Current behavior before PR (without fix)**:
After saving a form with an x2many field, web_save calls write and then web_read. In this flow, web_read can include inaccessible x2many ids from cache and raise an AccessError.

**Desired behavior after PR is merged**:
x2many records are re-filtered with current read rules before formatting, and inaccessible ids are removed from values_list.

Forward-Port-Of: odoo/odoo#257517
Forward-Port-Of: odoo/odoo#250904

Steps to reproduce:
1. Create an invoice with a 0% tax (Exempt from VAT, category E)
2. Add two lines with 20% discount and fractional prices:
   - qty=4, price_unit=39.615 and qty=4 with price_unit=0.84
3. Send via Peppol
4. Peppol rejects with: [BR-E-08] VAT category taxable amount shall equal the sum of Invoice line net amounts

The TaxableAmount recalculation in _ubl_get_tax_subtotal_node was only applied for tax category 'S' (Standard Rate). However, Peppol schematron has identical rules for all tax categories: BR-E-08 (Exempt), BR-Z-08 (Zero), BR-AE-08 (Reverse Charge), etc.

When lines have discounts and fractional prices, the individually rounded LineExtensionAmount values can sum to a different total than the tax base_amount. This affects both rounding modes. For 'S' taxes this was already handled, but for 'E' (and others) it caused Peppol rejection.

Remove the 'S'-only filter and match dynamically against the actual tax category code so the recalculation applies universally.

opw-6093243

Forward-Port-Of: odoo/odoo#258909

**Contract Amendment & Versioning Logic**

* When an offer's contract start date falls within an existing contract period, it is treated as a contract amendment (new version) rather than a new contract.
* For contract amendments, the offer's contract end date is read-only and automatically inherited from the existing contract.
* When creating a new offer, any existing versions with effective dates **on or after** the new offer's contract start date are automatically archived, as they likely contain outdated data.
* Added a warning to notify users when a new offer will replace existing future versions.

**Technical Refactoring**

* Simplified the `employee_version_id` computation by delegating to the existing `_get_version` method on the employee model. This ensures the selected employee version correctly matches the contractual state effective at the new offer's
* Ensured cache invalidation after rollback savepoints to prevent stale data. The overridden `_get_version` in `hr_contract_salary_payroll` writes to `employee.version_id` and the `contract_template_id`; although rolled back, it polluted the cache. We now always invalidate the cache after rollbacks to avoid inconsistencies, including later module installation.

**Simulation & Chatter**

* Inside the simulation, when calling `_get_version`, we need to adjust the contract dates of the version being simulated. The main challenge is allocating this simulated version between existing employee versions without creating contract overlaps, since overlaps raise validation errors.
* To avoid this issue, we move to a new approach. We archive all versions after `employee.version_id` and set `employee.version_id.contract_date_end = False`.
* Then, instead of replacing the active version, we create the simulation version as an amendment to `employee.version_id`. The amendment's effective date is set to `max(fields.Date.today(), employee.version_id.contract_date_start, self.contract_start_date)` + 1 day. This ensures the current version remains unchanged, avoids contract overlaps, and prevents chatter pollution.

task: 5408192

Forward-Port-Of: odoo/enterprise#103846

## Context
On the website page of a product, users can transform a picture in various ways (shape, size, cropping, etc.) when uploading it.

## Issue
When uploading a new picture, users can only replace the image or reorder it, but they cannot reshape it, crop it, or edit its size.

## Steps to reproduce
1. Install the *eCommerce* (`website_sale`) app.
2. Create a product and set a picture for it.
3. Go to that product's page in the Website app and open the website editor.
4. Click on the picture and replace it.
5. **The options to transform the picture are not displayed.**

## Cause
The transformation options are disabled due to the following static `exclude` variable in `ImageToolOption`:

https://github.com/odoo/odoo/blob/2b6b937c1c6d92e4e8b4657ae62127f0f8a7eb56/addons/html_builder/static/src/plugins/image/image_tool_option.js#L16

## Solution
We should prevent the transformation options from being displayed **only** when the image is external. In such cases, certain options from the `ImageToolOption` (such as the `ImageTransformOption` or the `ImageShapeOption`) cannot be applied. This is confirmed by the message displayed when trying to crop an external image:

https://github.com/odoo/odoo/blob/2b6b937c1c6d92e4e8b4657ae62127f0f8a7eb56/addons/web_editor/static/src/js/wysiwyg/widgets/image_crop.js#L164-L173

We can determine whether an image is external by looking at its `data-attachment-id` property. If it is present, the image was recently uploaded to Odoo.

On top of updating the `exclude` variable, we need to filter out the options that cannot be used on images from the eCommerce. These options are:
- Description
- Tooltip
- Transform (*"Transform the picture"*)
- Size

## Tests
The test checks that the behavior matches the one from previous versions: the options to edit an image are not displayed before replacing the image, but are displayed after. Both the test `image field should not be editable, but the image can be replaced` (shown below) and the new test from this PR fail if the modified `exclude` variable allow to edit the image before replacing it.

https://github.com/odoo/odoo/blob/dea5a1d28a1935c2b4d87c3c6e8c07cd874c7d6b/addons/html_builder/static/tests/image_field.test.js#L7-L16

## Options displayed
|   | Before this commit  | After this commit  | Previous versions |
|---|---|---|---|
|  **Before replacing the image**  | Media, Re-order | Media, Re-order  | Media, Re-order
|  **After replacing the image**  | Media, Re-order | Media, Re-order, Shape, Transform (crop), Filter, Format, Quality | Media, Re-order, Shape, Transform (crop), Filter, Format, Quality


opw-5251864

Forward-Port-Of: odoo/odoo#247539
Forward-Port-Of: odoo/odoo#241071

**Description of the issue/feature this PR addresses**:
web_read on x2many fields can reuse cached ids after write/web_save. Some of these cached ids may be inaccessible with the current record rules/context (cache pollution).

**Example**:
- **Context**:
  - Two companies exist: Company A and Company B.
  - Two users exist: User A and User B.
  - User A can only access Company A (company_ids=[A], company_id=A).
  - User B is linked to both companies (company_ids=[A, B], company_id=A).
  - The "res.company" record rule is the standard one: [('id', 'in', company_ids)] (company_ids comes from allowed_company_ids).
  - User A edits User B and saves the form.

- **Steps**:
  - User A performs a web_read to load User B: company_ids contains only Company A.
  - User A performs web_save (write + internal web_read in the same request): cached ids [A, B] are reused and the code attempts to read Company B.

**Current behavior before PR (without fix)**:
After saving a form with an x2many field, web_save calls write and then web_read. In this flow, web_read can include inaccessible x2many ids from cache and raise an AccessError.

**Desired behavior after PR is merged**:
x2many records are re-filtered with current read rules before formatting, and inaccessible ids are removed from values_list.

Forward-Port-Of: odoo/odoo#257517
Forward-Port-Of: odoo/odoo#250904

**Description of the issue this PR addresses:**

On mobile devices, the chat composer becomes unresponsive when the navigation menu `navbar-toggler` is open.


https://github.com/user-attachments/assets/8ef01ec6-4a44-41d3-8b86-74f68caf47ef


Steps to reproduce:
1. Open the website in a mobile view.
2. Tap the navbar toggler to open the mobile menu.
3. Without closing the menu, open the chat window.
4. Tap on the message composer text area.

→ The composer is not accessible.

This happens because the bootstrap `Offcanvas` (used by the `navbar-toggler`) traps focus by listening for `focusin` events bubbling up to the document. When the composer is tapped, the Offcanvas intercepts the event and immediately steals focus back to itself, dismissing the virtual keyboard.

This commit stops the event propagation at the composer level, ensuring the composer can reliably retain focus in responsive views without interference from active menus.

Task-[5954657](https://www.odoo.com/odoo/project/1519/tasks/5954657)

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

Forward-Port-Of: odoo/odoo#259257
Forward-Port-Of: odoo/odoo#250294

Steps to reproduce:
1. Create an invoice with a 0% tax (Exempt from VAT, category E)
2. Add two lines with 20% discount and fractional prices:
   - qty=4, price_unit=39.615 and qty=4 with price_unit=0.84
3. Send via Peppol
4. Peppol rejects with: [BR-E-08] VAT category taxable amount shall equal the sum of Invoice line net amounts

The TaxableAmount recalculation in _ubl_get_tax_subtotal_node was only applied for tax category 'S' (Standard Rate). However, Peppol schematron has identical rules for all tax categories: BR-E-08 (Exempt), BR-Z-08 (Zero), BR-AE-08 (Reverse Charge), etc.

When lines have discounts and fractional prices, the individually rounded LineExtensionAmount values can sum to a different total than the tax base_amount. This affects both rounding modes. For 'S' taxes this was already handled, but for 'E' (and others) it caused Peppol rejection.

Remove the 'S'-only filter and match dynamically against the actual tax category code so the recalculation applies universally.

opw-6093243

Forward-Port-Of: odoo/odoo#258909

Steps to reproduce:
----------------------------------------
1. Install the `hr_recruitment` module
2. Create a new user and configure the following access rights:
    * Employees: No
    * Recruitment: Officer Manage all applicants
3. Create new job position > Set created user in Recruiter
4. Log in with the created user
5. Go to Recruitment > Click on the Configure button of that job position

Observation:
----------------------------------------
The Trackers page is not visible on the job position form for the recruitment officer user.
If the user is additionally granted the Employees → Officer: Manage all employees group, the Trackers page becomes visible. The access to the recruitment Trackers should not depend on the Employee 'Officer: Manage all employees' access right.

Issue:
----------------------------------------
The visibility of the Trackers page depends on the Employees → Officer: Manage all employees group instead of the recruitment officer access rights

Solution:
----------------------------------------
Grant access to the Trackers page using the Recruitment Officer group so recruitment officers can access it without requiring the employee officer privileges

opw-5969416

Forward-Port-Of: odoo/odoo#252209

**Steps to reproduce:**
- Set up an event, go put it's state to Annonced
- Set up any online payment method (Demo also triggers the bug)
- Go to a PoS that sells the event tickets
- Purchase one and pay with the online payment method
- Once on the ticket screen, the button to download the event tickets is not displayed

**Why the fix:**
The normal flow only works for offline payment methods, because we check if the ordered is either paid or invoiced before setting all the values needed by the frontend regarding the ticket registration.

The problem is that with an online payment method, once we enter the **read_pos_data** method that sets
the values for the frontend, the order is still in draft, so we just return without doing anything.

We now set the values regardless of the order's status and send the confirmation mail in the same way as if it was an online payment.
In the case of an online payment, the mail will be sent by the **action_pos_order_paid** function that is called once the payment is processed.

A test might be a bit weird to make as we don't have a bridge for pos_online_payment and pos_event, and that we would need to mock the server's answer to be able to pay for the online payment and check that we have the needed values. So the setup for pos_event would have to be copied into pos_online_payment to test it and it would only be ran if both modules are installed.

opw-5438432

Forward-Port-Of: odoo/odoo#258986
Forward-Port-Of: odoo/odoo#249306

Upon chart reload, accounts will not be updated (except for tax_ids), but tax groups are. If a tax group was changed to relate to a different account and this account was re-purposed (e.g. account_type changed from an incompatible to a compatible type, the fact that the account is not updated will trigger constraints in the tax group when it is written. IOW, if the purpose of an account is not changed, its use should not be changed either.

E.g.: 1f4710deb206736cd71580d8fd95552d9b7c8014 changed the value of `tax_payable_account_id` on tax group `tax_group_cofins_incl_goods` to `account_template_202011005` and the same commit changed the value of `account_type` on `account_template_202011005` from `liability_non_current` to `liability_payable`, triggering `_constrains_payable_receivable_account` (in 19.2: https://github.com/odoo/odoo/blob/e00dd21880c3c4e5c22d65567c700e02541f7259/addons/account/models/account_tax.py#L68).

So here, we skip the update of relations to accounts on tax groups, if the account already exists.

Forward-Port-Of: odoo/odoo#259160

In German location with Fiskaly setup.
POS users hit an AccessError on read when closing the session from the frontend,
then had to finish closing in the backend with admin (base.group_erp_manager) rights.

Steps to reproduce:
-------------------
* Enable Germany + Fiskaly POS (l10n_de_pos_cert), with a company registered for Fiskaly
* Use a user with POS rights only (no Access Rights)
* Open POS, sell, then close the session from the POS UI

> Observation:
A warning redirects to the back end; manual close shows: insufficient rights to read l10n_de_fiskaly_api_secret on res.company (operation read).

Why the fix:
------------
The guard only needs to know whether the company is in the Germany + Fiskaly flow; that is
already expressed by l10n_de_is_germany_and_fiskaly(), without reading API credentials.
Fiskaly RPC helpers on res.company continue to use sudo() where secrets are required;
this change fixes unnecessary reads of protected fields in the tax helper,
not the security model of the credentials themselves.

opw-6074960

Forward-Port-Of: odoo/enterprise#112618

**Description of the issue/feature this PR addresses**:
web_read on x2many fields can reuse cached ids after write/web_save. Some of these cached ids may be inaccessible with the current record rules/context (cache pollution).

**Example**:
- **Context**:
  - Two companies exist: Company A and Company B.
  - Two users exist: User A and User B.
  - User A can only access Company A (company_ids=[A], company_id=A).
  - User B is linked to both companies (company_ids=[A, B], company_id=A).
  - The "res.company" record rule is the standard one: [('id', 'in', company_ids)] (company_ids comes from allowed_company_ids).
  - User A edits User B and saves the form.

- **Steps**:
  - User A performs a web_read to load User B: company_ids contains only Company A.
  - User A performs web_save (write + internal web_read in the same request): cached ids [A, B] are reused and the code attempts to read Company B.

**Current behavior before PR (without fix)**:
After saving a form with an x2many field, web_save calls write and then web_read. In this flow, web_read can include inaccessible x2many ids from cache and raise an AccessError.

**Desired behavior after PR is merged**:
x2many records are re-filtered with current read rules before formatting, and inaccessible ids are removed from values_list.

Forward-Port-Of: odoo/odoo#257517
Forward-Port-Of: odoo/odoo#250904

Relativedelta on UTC dates or time-zoned dates doesn't return the same result. 
In order to calculate consistent prices (price for 1 month in December = price for 1 month in January), we need to work on time-zoned dates.

Example: 
Consider a website in UTC+1 (Brussels timezone DST off).
And a rental from the 01/12/2025 to the 31/12/2025 = by design, from the 01/01/2025 00h00 (start_date) to the 31/12/2025 23h59 (end_date). 
Converted in UTC for the back-end, we have:
from the 30/11/2025 23h00 to the 31/12/2025 22h59.
relativedelta(end_date, start_date) = time between the 2 dates is calculated as follow:
30/11/2025  23h00 + 1 month = 30/12/2025 23h00 +23h59 = 31/12/2025 22h59. 
Time difference = 1 month, 23 hours, 59 minutes. 
Price = 2 months. 

Consider a second rental from the 01/01/2026 to the 31/01/2026. 
31/12/2025 23h00 + 30 days = 30/01/2026 23h + 23h59 = 31/01/2026 22h59. 
Time difference = 30 days, 23 hours, 59 minutes.
Price = 1 month. 

opw-5130762

Forward-Port-Of: odoo/enterprise#101714
Forward-Port-Of: odoo/enterprise#98571

**Steps to reproduce:**
- Install Documents app
- As admin, share a folder to a portal user with editor access
- Log as portal user on mobile view
- Try to upload a new file from the control panel
- File dialog appears, but selected file is not saved

**Issue:**
Seems like changing the boostraps dropdown to the owl component created this issue. It is caused by Upload button trying to use the `<input>` of its parent dropdown. When the dialog opens, the current dropdown and its parent are removed (with the surrounding overlay) due to the default closingMode.
`onSelected="() => this.uploadFileInputRef.el.click()"`

Also the page has multiple time the same `<input>` element due to the duplication of the actions for the bottom drawer.

**Fix:**
Put the `<input>` element in a place where it won't be duplicated on mobile when creating the overlay with the upload interactions. This ensures we always use the same `<input>` element for the dropdown, so that files are properly added even if the dropdown is removed.

We could also change the closingMode to `closest` or `none` and manually close the remaining dropdown(s) on file upload.

dropdown component: https://github.com/odoo/enterprise/commit/06802d3d6cc5141842adba74f7c9f1970feeb263
similar issue for non-portal user: https://github.com/odoo/odoo/commit/8a871a120b75f7c09c70dbf07530239244dbb5d6

opw-6042353

Currently an error is generated when the user tries to save an
appointment as follows:
- Install the appointment_google_calendar module without demo data
- Create a new appointment as below:
      - Remove Organizer (user_id)
      - Set the Google Meet link inside VideocallURL, e.g., https://meet.google.com/aaa-aaa-aaa
- An error occurs in the log and a message is shown to the user when save the record
- Also, an error occurs when trying to preview `Appointment: Attendee Invitation`
  after creating appointment as follows:
      - Set the Google Meet link inside Videocall URL > save
      - Remove Organizer (user_id)

Error: 
```
test odoo.addons.mail.models.mail_render_mixin: Failed to render QWeb template for Mail Template: 'Appointment: Appointment Booked' (ID: 12) - Context language:en_US
Target Model: calendar.event
Error: Error while render the template
ValueError: Expected singleton: res.users()
```


This is because the method `is_google_calendar_synced` expected a single
record, but since we removed `user_id` from the event (appointment),
it will generate a singleton error.

This commit will fix the above issue by not calling `is_google_calendar_synced`
when the event does not have `user_id`.

sentry-7393595716

**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 raw move lines being created in mrp without changing the producing quantity are manually created

opw-5946439

Currently, when the user takes a component product from different lots for manufacturing, after producing the product, the stock moves are modified in such a way that only the first lot is used for consumption, ignoring the intended selection across multiple lots.

## Steps to replicate:
- Install mrp without demo data
- Enable Lots and Serial Numbers
- Create two products: Car and Bolt, and set Bolt to be tracked by lots
- Update the on-hand quantity of Bolt by creating two lots with 10 units each
- Create a BoM for Car with Bolt as a component and quantity set to 4
- Create and confirm a Manufacturing Order for Car, see Components and open More Details
- Assign Lot 1 with quantity 2 and Lot 2 with quantity 2, then save the MO
- Click on Produce All

## Observed Behavior:
Even though the user manually selected 2 units from lot 2 and 2 units from lot 1 , after producing the product, all 4 units are taken from lot 1 instead of being split evenly. This can also be verified in the traceability report.

## Root cause:
This issue was introduced after commit [1], which added support for considering physical inventory (stock quants) when updating quantities on stock moves and automatically creating or adjusting stock move lines.

When the `Produce All` button is pressed, the `button_mark_done` method is triggered This calls `pre_button_mark_done`, which in turn invokes `_set_quantities` [2]. That method calls `_set_qty_producing`, eventually leading to `_set_quantity_done`  [3], which marks the move as done. During this process, `_set_quantity_done_prepare_vals` is executed.

Inside `_set_quantity_done_prepare_vals` [4], the system assigns quantities to move lines based on the move and its reservations. In this scenario, the stock move has a total quantity of 4. The first move line has a quantity of 2, which is subtracted as the consumed (taken) quantity.

At this point, the reserved (available) quantity is also 2, so the final condition is satisfied. This condition subtracts the available quantity from the remaining required quantity for the move, which is 2 for the next move line. As a result, the remaining required quantity becomes 0.

Because of this, the next move line ends up with a required quantity of 0 and is removed at [5], effectively prioritizing the first move line.

[1]:
https://github.com/odoo/odoo/commit/eed96007f9032d1a9e30211c8bdcf53f8ce96a49 
[2]:
https://github.com/odoo/odoo/blob/a9a63976372d3b5411fd798a48cc5302c2de8af0/addons/mrp/models/mrp_production.py#L2821-L2830 [3]:
https://github.com/odoo/odoo/blob/a9a63976372d3b5411fd798a48cc5302c2de8af0/addons/mrp/models/mrp_production.py#L1342-L1343 [4]:
https://github.com/odoo/odoo/blob/a9a63976372d3b5411fd798a48cc5302c2de8af0/addons/stock/models/stock_move.py#L2301-L2322 [5]:
https://github.com/odoo/odoo/blob/a9a63976372d3b5411fd798a48cc5302c2de8af0/addons/stock/models/stock_move.py#L2286-L2288
## Solution:
Since manual selection of lots is possible, the total available quantity across all lots should be checked before prioritizing any specific move line for updates.

Updates should only occur when lots are not being used and the maximum possible quantity has already been reserved from the total available inventory.

This prevents all quantities from being assigned to the first stock move line associated with a lot and ensures manually added lots remain on the move lines.



opw-6058908

When sending an invoice by email template, dynamic report attachments do not use their configured Printed Report Name. Instead, they fall back to a default naming pattern (e.g. report name + invoice number).

This is due to a difference in flow: sales use the standard mail.compose.message wizard, which correctly applies each report’s print_report_name, while invoices use the dedicated account.move.send flow. In this flow, dynamic report filenames are not computed from the report itself.

To fix this, the send flow is updated so _get_placeholder_mail_template_dynamic_attachments_data computes the filename from each dynamic report. When a print_report_name is defined, it is used. Otherwise, the previous fallback behavior is preserved.

The fix will ensure extra dynamic reports follow their configured printed name.

Steps to reproduce:
1. Go to Settings > Technical > Reporting > Reports and duplicate the standard Invoice report.
2. In the duplicated report, set a custom value in Printed Report Name (e.g. 'CUSTOM_NAME_TEST').
3. Go to Settings > Technical > Email > Templates and open “Invoice: Sending”.
4. Add the duplicated report under Dynamic Reports.
5. Create a customer invoice and confirm it.
3. Click Send (or Send & Print) to open the email preview.

Related Ticket:
opw-6058716

### Problem:
When returning a delivery or receipt for an inter-company transaction, the journal entry created for the return will account on the opposite stock interim account. That is, a delivery to another company will debit the stock output account, but returning the delivery will create an account move that credits the stock input account. Compare this to normal return behavior which will credit the stock output account to reverse the original delivery's entry.

### Solution:
When deciding whether a stock move is a return, we will include transit locations as valid locations.

### Steps to reproduce (Runbot v18)
- Automatic accounting
1. Create a SO for the automatically accounted product, selling to another company in the system
2. Validate the delivery, check the valuation and note there is a debit on the stock output account
3. Create a return for the delivery and validate it, check the valuation and note the credit on the stock input account

To clarify, this differs from when the customer on the SO is anything other than a res.company, where we will see a credit on the stock output account when the return is validated.
Also, this flow is the same for POs, and the same bug is addressed by this fix.

### Before
<table>
	<th>Move type</th>
	<th>Account</th>
	<th>Debit</th>
	<th>Credit</th>
	<tr>
		<td>Delivery</td>
		<td>Stock output</td>
		<td>100</td>
		<td>0</td>
	</tr>
	<tr>
		<td>Delivery Return</td>
		<td style="{color: red}">Stock input</td>
		<td>0</td>
		<td>100</td>
	</tr>
</table>

### After
(Or normal behavior without inter-company transfer)
<table>
	<th>Move type</th>
	<th>Account</th>
	<th>Debit</th>
	<th>Credit</th>
	<tr>
		<td>Delivery</td>
		<td>Stock output</td>
		<td>100</td>
		<td>0</td>
	</tr>
	<tr>
		<td>Delivery Return</td>
		<td>Stock output</td>
		<td>0</td>
		<td>100</td>
	</tr>
</table>

opw-5993147

**Issue:**
When a user posts a credit note with a currency exchange difference relative to the reversed move,
the resulting exchange move lines lack the mandatory analytic distribution.
This triggers a validation error, preventing the credit note from being posted.

**Steps to reproduce:**
- Set "mandatory" applicability on any analytic plan.
- Set two different currency rates on two different dates for any foreign currency.
- Create and post an invoice on the first date (ensure the mandatory analytic distribution is set).
- Create a credit note from that invoice using the second date.
- Click on the post button on the credit note.

Result: A validation error occurs even though the credit note itself has the mandatory analytic plan set,
because the auto-generated exchange move does not.

**Fix:**
Since the context key validate_analytic is set to True by the post button action,
it must be manually set to False during the automatic creation of exchange difference moves to bypass the mandatory plan check.

OPW-6081632

Forward-Port-Of: odoo/odoo#259381

Steps to reproduce:
-------------------
1. Install Time Off.
2. Create a user and employee without Time Off access rights.
3. Create another employee and set the first employee as the manager.
(This automatically sets them as the Time Off approver.)
4. Create a time off request for the second employee from Time Off > Management.
5. Ensure that "Employee's Manager" is set as the approver in the corresponding Time Off type.
6. Log in with the first user, go to Overview and try to approve the leave.

Issue:
------
An AccessError occurs when approving the leave from the overview:

```python
You do not have enough rights to access the fields 'leave_id'
on Time Off Calendar (hr.leave.report.calendar)
```

Cause:
------
In `hr_leave_report_calendar`, the `leave_id` field is restricted to `hr_holidays.group_hr_holidays_user`.
When a leave manager without Time Off user rights tries to approve a leave from the overview,
the field access restriction triggers an AccessError.

related commit: https://github.com/odoo/odoo/commit/b5c9420543bdaae52b191e518c5e0f31ba925e46

Solution:
---------
Remove the group restriction on the `leave_id` field and introduce record rules
on `hr.leave.report.calendar` to control access.

- Leave managers can read records related to their employees.
- Time Off officers retain full read access.

This prevents the AccessError while still restricting the visibility of leave information for unauthorized users.

opw-5921263



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

**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 raw move lines being created in mrp without changing the producing quantity are manually created

opw-5946439

**Description of the issue/feature this PR addresses**:
web_read on x2many fields can reuse cached ids after write/web_save. Some of these cached ids may be inaccessible with the current record rules/context (cache pollution).

**Example**:
- **Context**:
  - Two companies exist: Company A and Company B.
  - Two users exist: User A and User B.
  - User A can only access Company A (company_ids=[A], company_id=A).
  - User B is linked to both companies (company_ids=[A, B], company_id=A).
  - The "res.company" record rule is the standard one: [('id', 'in', company_ids)] (company_ids comes from allowed_company_ids).
  - User A edits User B and saves the form.

- **Steps**:
  - User A performs a web_read to load User B: company_ids contains only Company A.
  - User A performs web_save (write + internal web_read in the same request): cached ids [A, B] are reused and the code attempts to read Company B.

**Current behavior before PR (without fix)**:
After saving a form with an x2many field, web_save calls write and then web_read. In this flow, web_read can include inaccessible x2many ids from cache and raise an AccessError.

**Desired behavior after PR is merged**:
x2many records are re-filtered with current read rules before formatting, and inaccessible ids are removed from values_list.

Forward-Port-Of: odoo/odoo#250904

### Issue before this commit:
When setting a product price intended to result in a clean tax-included amount (e.g., 24€ with a 21% tax), the computed “price including taxes” displayed in the UI was slightly off due to rounding issues. Instead of returning exactly 24.00, the system would display values such as 23.99 or 24.01.

### Steps to reproduce the issue:
1. Download l10n_be and switch to the BE company
2. Create a new product and be sure the tax is setted on 21%
3. Try to insert a price =24/1.21
4. The computed price Incl. taxes inside the brackets is never 24.0 but or 23.99 or 24.01

### Cause of the issue:
When the base_round was not setted to False the calculation was taking t he currency precision to round the number from the start of the calculations even if the number of digits setted was higher. This way the rounding will be computed only at the end of the calculations instead of being already setted from the start.

### Reason to introduce the fix:
Be able to represent all the numbers as the final price for one product.

opw-6024520

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

Steps to reproduce:
- Set the cookies bar
- Do not accept nor reject it
- On the website homepage, click on the search button => Check the cookies: website_cookies_bar=true is set.

`Popup` initializes `cookieValue` to `true` and writes it in `onHideModal()`. If the cookies bar is closed before any explicit consent choice, it can therefore recreate the legacy invalid value `website_cookies_bar=true`.

This happens because the search button uses `data-bs-toggle="modal"`, which is controlled by Bootstrap: if it is opened while another bootstrap modal is already open on the page, the latter is hidden. This in turn calls the popup interaction's `onHideModal()`, which sets `website_cookies_bar=true` as `cookieValue` hasn't been changed.

That value is later treated as invalid and cleared repeatedly during website rendering, which can accumulate duplicate `Set-Cookie` headers in the same response and lead to `upstream sent too big header` behind nginx.

Avoid persisting that legacy value by returning early from `CookiesBar.onHideModal()` while `cookieValue` is still the inherited default `true`.

opw-6037573

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

Backport of: https://github.com/odoo/odoo/pull/258938