Step to reproduce:
- have a trusted pos and a loyalty program which gives points per $ spent
- start pos and select order and a partner (he should already have some LPs)
- notice the loyalty points assgined
- save the order, you are redirected to new order
- switch back to original order

Observation:
- Notice, the loyalty points are reassigned for example :
- if initially partner's LP = 50,  product added is 100$ , LP = 50+100 = 150
- After saving, LP becomes 150 + 100 = 250

Cause:
- LP's are processed after every `sync_from_ui` call from `_postProcessLoyalty` which updates the customer's lp, even before the order is fullfilled or when order is still in `draft` state

Fix:
- Issue is fixed in https://github.com/odoo/odoo/commit/a4b37ec474656c7af23d0134251d589e9a6a61ca
- This commit adds related test for the fix
    

opw-5609964

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

Forward-Port-Of: odoo/odoo#248184
Forward-Port-Of: odoo/odoo#245400

## Short functional explanation of the error
When setting a shift spread on multiple days for an employee who has a flexible schedule and previewing the planning of this employee, on the shown calendar, the color dot doesn't show. Instead, 'null' appears.

## Reproduction Steps
1. Go to planning and create a shift extended on multiple days for an employee who has a flexible schedule.
2. Click Publish and Send.
3. Click on Actions on the left top side and click Preview.
4. Select the employee you just created the shift for.
5. Click on Preview.
6. It opens a window with the employee's planning. On the left top side, click Month.

### Expected behavior
A shift spread on multiple days should show, with a color dot on the left of the schedule.

### Unexpected behavior
Null appears instead of the color dot. Moreover, the background of the shift has the color of the color dot that should be there.

## Origin of the issue
For employees with specified working schedules, multiple-days shifts are limited to their schedule. Thus, these shifts are split on the working hours of the employee.
But flexible employees have no specified working hours, so the shifts aren't split. This creates multiple day slots. FullCalendar generates different html codes for such slots, which don't contain class ```fc-daygrid-event-dot```, responsible for the creation of the color dot next to the shift schedule. However, even if this color dot isn't created, we still mention it here:
https://github.com/odoo/enterprise/blob/59cec3e8c6a0880178aa93651dca66c367d36841/planning/static/src/js/planning_calendar_front.js#L116 to display shifts. Therefore, we have to create it if it doesn't exist.
__
opw-5437257

Forward-Port-Of: odoo/enterprise#104822

Currently, an error occurs when a user opens the Tax Returns report.

**Steps to Reproduce:**

 - Install the `Accounting` module.
 - Go to `Journal Entries` and create a journal entry with lines, `Ex:`
   - One `Receivable` line with a positive debit.
   - One `Income` line with the same credit.
 - `Post` the journal entry.
 - Go to `Accounting > Closing > Tax Returns`.
 - Set the `date` and click `Apply`.

`AssertionError: Invalid falsy real id`

When opening the Tax Returns report, it going generates the Annual Closing Checklist. During this 
process, it tries to get the unknown partner’s account line ID [1]. However, if the line_id does not 
contain anything related to the target model (account.move.line), the method returns None [2]. Later, 
it attempts to browse using this None value which raise the error [3].

This commit ensures that only valid ids are added, preventing None values from being browsed.

[1]: https://github.com/odoo/enterprise/blob/887fb85cf3ed488187418c03df159af859a4e435/account_reports/models/account_return.py#L2365-L2371

[2]: https://github.com/odoo/enterprise/blob/887fb85cf3ed488187418c03df159af859a4e435/account_reports/models/account_report.py#L2461

[3]: https://github.com/odoo/enterprise/blob/887fb85cf3ed488187418c03df159af859a4e435/account_reports/models/account_return.py#L2399

sentry-7263718845

Steps to reproduce the issue:
=================================

1. Go to Website > Products and edit a product.
2. In the product description, add a header using the editor.
3. You can now drop an image in that place, so drop it.
4. Click on the image and try to add an anchor for it.

-> Traceback

Cause:
======

The reason an image can be dropped in that location is because the editor
added an adjacent element, such as a `<p>` or `<h1>`, which is considered
a valid drop zone by the drop zone plugin. However, when trying to
create a link, the parent element checks if it is valid to have an
anchor, but then when adding an anchor the element text is undefined,
causing a traceback.

Why can an image be dropped in that location after adding the editor?
The bug was due to passing `excludeNearParent` as a property name instead
of `excludeParent` to the `getSelectorSiblings` function, which always
evaluated to false. So it allowed dropping images in invalid locations.

Solution:
=========
Pass the correct property name.

Impact:
=======
This fix enforces the intended dropzone behavior where content snippets
(like images, buttons with `.o_snippet_drop_in_only`) cannot create
dropzones next to elements that are direct children of `.oe_structure`
containers.

Test Changes Required:
=======================
The button tests were failing after the fix because they were testing
buttons as direct children of
`<div id="wrap" class="oe_structure oe_empty">`. This was only working
before due to the bug - `excludeNearParent` was being ignored.

The fix wraps the test buttons in a `<div>` container,
making them children of a child of `.oe_structure` rather than
direct children.

opw-5489444

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

Forward-Port-Of: odoo/odoo#249707
Forward-Port-Of: odoo/odoo#244324

## Issue
In the Planning app, users within the *Planning / User* groups could not take open shifts. The button *"I Take It"* would not be displayed when clicking on the shift.

## Steps to reproduce
1. Install the *Planning* (`planning`) app
2. In the Planning app, as an admin, create and publish an open shift
3. Log in as a *User*, open the *Planning* app, and click on the open shift
4. **The _"I Take It"_ button is not displayed**

When logging in as a user who is **not** part of the *Planning / User* group, the *I Take It* button is displayed.

## Cause

The condition for the *I Take It* button to be displayed is the following:

https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L282-L283

The condition that makes the button invisible is `not context.get('my_planning_action')`. When the user is part of *Planning / User*, the schedule they see when opening the *Planning* app is the *"Schedule by Resource"*, which has the following context:

https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L716

When a user who **is not** part of the *Plannig / User* group opens the *Planning* app, they see their own schedule, where the context is different than in the first case:

https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L636

Because the `my_planning_action` property is in the context (and all the other conditions are respected), the button is displayed.

opw-5451282

Forward-Port-Of: odoo/enterprise#104919

Steps to produce:
---
- Install sales module.
- Go to Settings and enable Pricelists (make sure we have 2 pricelists
  so that we able to change the pricelist value in quotation).
- Create a new quotation > Add a customer and product.
- Change the pricelist.
- Save the record.

Issue:
---
- After saving the quotation, the `Update Prices` button becomes invisible.

Root cause:
---
- The field `show_update_pricelist`, which controls the visibility of the button, is not present in the view. As a result, when the record is saved, the field is not included in the form data and its value is not properly maintained, causing the button to become invisible.
- The field is removed from the view in this [commit].

Solution:
---
- Added the `show_update_pricelist` field to the view to ensure its value is properly maintained. This allows the `Update Prices` button to remain visible when applicable.

[commit]: https://github.com/odoo/odoo/commit/da4b588b272432095f549c012e0a0d7238f00dc0

**Enterprice PR:** https://github.com/odoo/enterprise/pull/107621

opw-5927659

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

Forward-Port-Of: odoo/odoo#248957

Users with the project_manager role and no access on sale cannot open stock moves

Steps to reproduce:
1. Install Sales, Inventory and Project
2. Create a Sale order for any company with an address and any product and confirm it (a delivery should be automatically created)
3. Go to Settings > Users and open user Marc Demo
4. Set Marc Demo's role on Sales to "No" and on Project to "Administrator"
5. Log in as Marc Demo
6. Go to Inventory > Operations > Deliveries and try to access the delivery previously created
7. An error occurs

Problem:
https://github.com/odoo/odoo/blob/6b2d3af64a076654e04494972acc4c42d7c54bd8/addons/sale_stock/models/stock.py#L32-L38
stock.move's description is computed based on the related sale order lines which will cause an access error because users with role `project.group_project_manager` can only access sale order lines of projects or tasks because of this rule:
https://github.com/odoo/odoo/blob/3909bef741ebb5c879beb383c395e1a310ba78eb/addons/sale_project/security/sale_project_security.xml#L4-L13
even though the group `stock.group_stock_user` are expected to always have read access to sale order lines because of this right:
https://github.com/odoo/odoo/blob/3909bef741ebb5c879beb383c395e1a310ba78eb/addons/sale_stock/security/ir.model.access.csv#L6

Note that the issue doesn't happen when the user is a sale user because of this rule that adds the rights on sale order lines:
https://github.com/odoo/odoo/blob/3909bef741ebb5c879beb383c395e1a310ba78eb/addons/sale/security/ir_rules.xml#L78-L83

This fix also solves the issue for `mrp.group_mrp_user` because they inherit the group `stock.group_stock_user`:
https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/mrp/security/mrp_security.xml#L11-L16

Therefore the rule on `project.group_project_manager` needs to be
overridden when the user is a stock user

Solution:
Create a record rule with a truthy domain to force stock users to have access to sale order lines even if other rules remove this access

opw-5492232

Forward-Port-Of: odoo/odoo#247529

### Steps to reproduce:
- Download Rental and eCommerce apps.
- Install an RTL language (e.g., Arabic) on the website.
- Create a rental and go to website.
- Try to pick a date for the rental.

### Issue:
When the website is viewed in an RTL language, the navigation arrows of the date picker are displayed in the wrong direction. This happens because the date picker is not inside `o_rtl` component, but inside `o-main-components-container` component. So, when `o_rtl` is called in css (for example):
https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/web/static/lib/odoo_ui_icons/style.css#L67-L76
Since the arrows are not inside `o_rtl`, the transformation doesn't apply to them.

### Solution:
The `o_rtl` class has been appended to `o-main-components-container` class in case of a RTL language, so that had the css file contain rules for `o_rtl`, they would be applied automatically.

opw-5498615

Forward-Port-Of: odoo/odoo#249541
Forward-Port-Of: odoo/odoo#246190

### Steps to reproduce:
- Download MRP app.
- Create a product and its corresponding BOM (including at least a single operation)
- Create and confirm a manufacturing order for 1 unit of that product
- Click on the Shop Floor smart button > Click on the header of the MO
- The MO filter applied on the shopfloor search bar is removed

### Issue:
The MO search filter is removed after you click the header of the workorder order. This bug was introduced by another commit https://github.com/odoo/enterprise/pull/94584/changes/c83ab24a8d037a339db8067c7e9794cba5c16eab to remove the filter when a workorder's barcode is scanned. Hence, https://github.com/odoo/enterprise/blob/67ff37a830202afb8c8914da6f7bc8d4972eefd4/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L289-L292
the change resulted in the filter being removed every time the header is clicked. In the case where a user clicks to start the workorder, we need to keep the filter.

### Fix:
Based on https://github.com/odoo/enterprise/blob/67ff37a830202afb8c8914da6f7bc8d4972eefd4/mrp_workorder/static/src/mrp_display/mrp_display_record.xml#L6-L8 `onClickHeader()` is called every time a shopfloor record is clicked, which (based on the reference in the previous section) removes the filter, then calls `startWorking()`. By removing `this.env.searchModel.removeMOFilter()` from this method, it's ensured that clicks preserve the user's current search context.
For https://github.com/odoo/enterprise/blob/67ff37a830202afb8c8914da6f7bc8d4972eefd4/mrp_workorder/static/src/mrp_display/mrp_display.js#L248-L250 since the original workflow of removing the filter in case of a barcode scan should be kept, moving `removeMOFilter()` call here with the appropriate reference of `workorder.component.env.searchModel`matches the expected behaviour.

opw-5877418

Forward-Port-Of: odoo/enterprise#107121

Steps to reproduce
------------------

1. Enable Units of Measure and Automatic Valuation.
2. Create:
  Product KIT, stockable, UoM category Unit, UoM = Units.
  BoM for KIT with at least one component whose UoM is in a different
     category (e.g. m from Length).
3. Go to the product's category and set the Costing Method to Average
   Cost (AVCO) and the Inventory Valuation to Automated.
4. Create a PO for KIT in a currency different from the company currency.
5. Confirm the PO and validate the receipt.

Issue
-----

Validating the receipt raises:

> The unit of measure m defined on the order line doesn't belong to the
> same category as the unit of measure kit defined on the product…

If you keep the PO currency equal to the company currency, the same kit
and BoM work and the receipt posts correctly.

Cause of the issue
------------------

Validating the receipt will call the `_action_done` of stock.move's and generate the related accounting entries. During this call and the currency of the PO is different from the company currency the `_generate_valuation_lines_data` will call the `_get_currency_convert_date` method:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L134-L140
This call will in turn call the `_get_qty_received_without_self`:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L121-L122
which was not written to handle kit products since it assumes that the product of the PO is the same as the one of the related move:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L102-L108

Fix
---

The qty_received is relevant to the _get_currency_convert_date as the method compares the qty_invoiced with the qty_received to determine whether to use the Invoice Date (when qty_invoiced > qty_received) or the Receipt Date.

https://github.com/odoo/odoo/blob/888e086dc6c7823b07993e90f70e2849e988fa7a/addons/purchase_stock/models/stock_move.py#L122-L126

  For kits, `qty_received` must be calculated by aggregating component
  moves to accurately determine this status. Since the standard logic
  crashes due to UoM mismatch, the override in `purchase_mrp` is
  necessary to provide the correct quantity for this date selection.

opw-5030761

Forward-Port-Of: odoo/odoo#248883
Forward-Port-Of: odoo/odoo#236276

_
## Short functional explanation of the error
When an employee enters multiple attendances for a single day, the company tolerance time isn't computed correctly.

## Reproduction Steps
1. Go to attendances.
2. Click on configuration and scroll down to the Extra Hours section. Set a Tolerance Time in Favor of Company of 15 minutes.
3. Create 2 attendances for the same employee: one attendance from 8 to 15 for example, and a second one from 16 to 18:12.

### Expected behavior
As the overtime entered is 12 minutes, which is inferior to the company tolerance time of 15 minutes, no extra time should be computed.

### Unexpected behavior
12 minutes of overtime are computed.

## Origin of the issue
Let's say we enter 2 different shifts for the same day. Our work day should be 8 hours, and the sum of both shifts reaches 8 hours or more. We shouldn't have any overtime. However, in the code, the overtime is negative. This is compensated by, in our case, the post-work time: in our case, our overtime duration will be equal to -1, but our post-work time will be equal to 1.2. Both cancel each other, and in the end we obtain 0.2 of overtime, which corresponds to our 10 minutes overtime. However, in this code: https://github.com/odoo/odoo/blob/afcbd98594c9f7007f03a343ea40ea122b955459/addons/hr_attendance/models/hr_attendance.py#L374-L380 it isn't computed that way: because post-work time is 1.2, which is above our company tolerance time of 15 minutes (0.25 in the code), we will always be in the case where we exceed the tolerance time.

Hence, we have to "flatten" the overtime duration and the post-work time before reaching that piece of code.

note: the same bug exists for the employee tolerance time, which
is corrected in this commit.
__
opw-5136861

---

Forward-Port-Of: odoo/odoo#244339
Forward-Port-Of: odoo/odoo#242517

**Issue:**
Loading the shop page was slow due to excessive forced reflows. When a reflow occurs, the browser can't reuse the layout computed so far, and it's forced recalculate it again.

**Cause:**
In `updateVariantPreview`, the init loop wrote to the DOM (textContent, classList) then immediately read `offsetWidth` in the same iteration, forcing the browser to flush and recalculate layout once per product.
This PR tackles the 2 areas of improvement identified:
1. Reduce reflows **number**.
2. Reduce reflows performance **cost**.

[task-5177358](https://www.odoo.com/web#id=5177358&cids=1&menu_id=4720&action=333&active_id=1695&model=project.task&view_type=form)

---

###  1: Reduce reflows **number**.

**Before this PR:**
Phase 1 was a single loop mixing writes and reads, triggering N layout recalculations for N products on the page.

| Performance Tab:  CSS selectors & Advanced paint instr. active (slow) |
|--------|
| <img width="1847" height="650" alt="image" src="https://github.com/user-attachments/assets/91e86e91-1209-4865-bcbd-336f792664ed" /> | 
| Timing inflated by the debug environment | 

**After this PR**
Phase 1 is split into two sub-loops. All writes first (1a) and all reads after (1b). So the browser flushes layout only once, regardless of product count, matching the batching pattern already used in phases 2 and 3.

| Performance Tab:  CSS selectors & Advanced paint instr. active (slow) |
|--------|
| <img width="1380" height="555" alt="image" src="https://github.com/user-attachments/assets/c0fefe32-d309-4fc8-a945-1a5f5c12b86e" /> | 
| Timing inflated by the debug environment | 


**Performance results**
In a page with 21 products, 11 of which with variants, the number of reflows dropped from 12 to just 2, resulting on a 82% faster rendering, roughly a 5.5X speedup.

---

###  2: Reduce reflows performance **cost**.

Reflows cannot be entirely avoided, but side-effects can be mitigated in CSS by instructing the browser how to react when this circumstance occurs. This PR add two rules to the products card:

1. `contain`: Tells the browser each product card is a layout containment boundary and inner changes "should not" affect elements outside.
2. `content-visibility`: Tells the browser to try skipping cards outside the viewport. Their layout will be eventually evaluated when cards scroll into view.

**Performance result:**
In a page with 21 products, 11 of which with variants, the performance cost of a single reflow dropped by 22%.

_note: the browser is not obliged to honor these "suggestion" and may behave differently depending by the viewport size, the content and the browser itself._




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

Forward-Port-Of: odoo/odoo#249324

**Issue:**

Non-admin users get an AccessError as follows

```doesn't have 'create' access to: - Default Values, Based on (Purchase Order Suggest) (ir.default: 45)... ```

when using the Purchase Order Suggest wizard.

**Cause:**

The `ir_default_user_rule` record rule restricts non-admin users to only create/modify ir.default records where
  `user_id = user.id`

However,  in  `_save_values_for_vendor` method:

https://github.com/odoo/odoo/blob/6b8a8196c63275eead6709bb20002df0be12a059/addons/purchase_stock/wizard/purchase_order_suggest.py#L199-L204

 `ir.default.set()`  is called without setting the `user_id` parameter, which defaults to an attempt to create a global default: what only admins can do.

**Steps to reproduce:**

- create a non-admin user with purchase user permissions.
- log  in as that user and create a Purchase Order
- add products to the catalog and click "Suggest.
- configure suggest parameters and click "Compute" (Note: compute is only enabled when estimated_price > 0)

An AccessError occurs

opw-5076647

Forward-Port-Of: odoo/odoo#236743
Forward-Port-Of: odoo/odoo#227643

Steps to produce:
---
- Install `sale_renting` and `sale_management` modules.
- Go to `Sales > Products > Products`.
- Create a product and disable the Sales option (`sale_ok = False`).
- Create a Sales Order and try to add that product.

Issue:
--
- Even though the product is not sale-enabled (`sale_ok = False`), it is still selectable in the Sales Order.

Root cause:
---
- At [1], The issue occurs because `super_domain` was not always included.
- When `order_is_rental` is True, `super_domain + []` happens,
  so only `super_domain` is applied.
- But when `order_is_rental` is False, instead of
  `super_domain + [('rent_periodicity', '=', False)]`, only
  `[('rent_periodicity', '=', False)]` was returned, and
  `super_domain` was ignored.
- Because of this, base conditions from `super_domain` like
  `sale_ok = True` were not applied.

Solution:
---
- Add parentheses around the conditional expression to ensure proper evaluation order and correct domain construction, so only products with `sale_ok = True` are selectable.

[1] https://github.com/odoo/enterprise/blob/abfde5f253c4c52d3a734ca8dafe6f8ed261cf75/sale_renting/models/sale_order_line.py#L49

opw-5902403
---

Before this commit, the following discuss call test may fail non-deterministically:

```
@mail/discuss/call/call/auto-focus participant video in one-to-one call in chat window
```

This happens at the step where it checks that when inside the discuss meeting view, having another participant enable a video stream does not auto-focus the card.

The test was failing and auto-focusing the card because the simulated toggling of enabling the video stream happens before the side-effect of rendering to toggle the flag that meeting view is on. So the handling of event that video stream is toggled on was mistakenly considering outside of meeting view.

This commit fixes the issue by awaiting a `data-active` on the UI if meeting view, which ensures the rendering of meeting view is complete and store is aware of meeting view being open, before triggering the event that simulates toggling of video stream. This technique is borrowed from `DiscussApp` component that requires a similar technique to determine whether a chat window must auto-open or not, which also requires making sure the store knows precisely when `DiscussApp` is logically open.

Fixes runbot-error-240554

In [1], a refactoring of the POS framework was done, but in the process some overlooked behaviors induced a complete loss of the answers given in the registration process, as long as they do not include an answer to a 'selection' question.

STEPS
=====

0. Create a new event with a few questions (no 'selection' one)
1. Add tickets so that you can buy one in the POS
2. Go in the POS (reload data if needed)
3. Buy a ticket and fill the attendee form (answer to all questions)
4. Continue the POS flow and pay for your ticket.
5. Go back to the back-end and event > attendees
6. Check your new attendee: no answers are linked to the record.

ISSUE
=====

TLDR - Two fields have the same comodel on event.registration. This breaks the use of inverseMap as both are loaded in the pos. As they are treated sequentially when connecting related records, hidden side effects occur when both are not set.

Details:

This effect is due to two main issues. First, after [1], we compute the whole model reference relations using processModelDefs method, that accounts for inverse relations of o2m, m2o fields and provides an inverseMap to be used in several places, notably on creation or deletion of relational records from the POS.

However, pos_event presents a peculiar situation, as registrations have two o2m fields, both loaded in _load_pos_data_fields, that are linked to the model event.registration.answer: registration_answer_ids and registration_answer_choice_ids, a subset of the first, just with a domain to only include answers of 'selection' questions.

Meaning that the inverseMap will only use one of the two, in this case registration_answer_choice_ids. In turn, this means that any update of registration_id on the answer model will update that field, even if the original update was done on registration_answer_ids...

Secondly, one could notice that this should still work, as the inverseMap is used in all places, we should just update the records through the field registration_answer_choice_ids.

So why does it not work and why are all answers removed? Because both fields are loaded in _load_pos_data_fields, and in _sanitazeRawData we use getFields to know which fields to update and to connect (for relations on the model), both being returned.

This means that independantly of the create values for the registration in addProductToOrder in pos_event, the 'framework' will still have two fields to connect and will do so sequentially, one field at the time.

But in the _connect logic, if a field has no value given at creation, then the 'CLEAR' command is used, as this would mean we remove the content of the relational field. But in this case, this means that as both answer fields try to update registration_id through registration_answer_choice_ids, if no value is given at creation in that field, then we clear existing ones, for instance those we just linked through the creation values in the first field registration_answer_ids, as we basically empty registration_id on those records. The answers will also be deleted of the indexedDB because of the condition in databaseTable (no linked registration -> can be removed)

FIX
===

Remove registration_answer_choice_ids from the loaded data, as it is not used anywhere except in the registration creation values. As it is a subset of the other field registration_answer_ids, only keep that one instead. Update the creation values to only use that field.

Note that this seems to highlight a limitation when it comes to having more than one o2m field on a model loaded at the same time in POS.

[1] odoo/odoo@a80a39f2ad16baf474553574c79d55948f86c453

Task-4919080

Forward-Port-Of: odoo/odoo#231293

__

## Short functional explanation of the error
Let's say we create a role containing employees with fixed schedules. Then, we create a shift template that applies on this role. When we create a shift, the starting and ending hours will take into consideration the hours of the employee's fixed schedule, instead of aligning with the shift template start and end hours.

As discussed with XBO, the start and end hours of the shift should align with the shift template, despite the fixed working schedules having different start and end hours.

## Reproduction Steps
1. Go to Planning. Click on Configuration tab > roles.
2. Create a role and add an employee as a resource This employee has to have a fixed working schedule.
3. Click on Configuration tab > Shift Templates.
4. Create a new Shift Template. Select starting and ending hours different from the employee's fixed schedule. Select the role you just created.
5. Click on Schedule tab > By resource and click on New.
6. Select the role you just created.

### Expected behavior
The start and end hours should align with the shift template start and end hours.

### Unexpected behavior
The start and end hours are aligned on the employee's fixed working schedule: if the employee has a schedule from 8 to 16h36 and the shift template goes from 10 to 18, the starting and ending hours will be 10 to 16h36.

## Origin of the issue
We kept computing the working intervals of employees, even if a shift template was set:
https://github.com/odoo/enterprise/blob/8b00363e5e461f11b9736354d94e520e21932e71/planning/models/planning.py#L656-L664 Which isn't necessary in the case where a shift template has been set, as the start and end time are determined by the shift template, and not the employee's schedule.
__
opw-5898509

Forward-Port-Of: odoo/enterprise#107018

## [FIX] Accrual account domain
Since [1], the accrued order wizard can be open from a purchase order line view and from a sale order line view.
The wizard account field uses a domain, and this domain is different if the active model is `purchase.order`. In quoted PR, the domain wasn't adapted to work with `purchase.order.line` as active model.
This PR fixes that.

## [FIX] Correct COGS cost
#### How to reproduce the issue
- Use anglo-saxon config;
- Have a product with a cost;
- Sale this product with its unit price =/= its cost;
- Deliver;
- Create accrual entry for this product => The perpetual valuation lines are not correct, they use the SO lines' price for their debit/credit instead of the product's cost.

#### Example
If we have a product with cost of $100 and sell it for $180

We currently have:
Account			Debit		Credit
Stock Valuation		$ 0.00		$ 180.00
Cost of Goods Sold	$ 180.00	$ 0.00

But we should have:
Account			Debit		Credit
Stock Valuation		$ 0.00		$ 100.00
Cost of Goods Sold	$ 100.00	$ 0.00

## PO line price diff
#### Issue
While generating accrual entries for a PO with billed not received, if the billed price is different than the PO line price, no entries were generated for the price diff account.

#### How to reproduce
1. Create a product using "Standard Price" as its costing method and set a cost for this product and set a price  difference account (on its product category);
2. Create a purchase order for this product and confirm it;
3. Create an invoice for this PO with a different price for the product;
4. Go to Accounting > Review > Billed Not Received;
5. Select the PO and click on "Create Accrual Entries" button => Accrued entries are created but no entries are created for the price difference.

#### Expected behavior
Two more entries must be created: one for the price diff account and one for the stock valuation account.

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

task-[5349657](https://www.odoo.com/odoo/966/tasks/5349657)

Forward-Port-Of: odoo/odoo#234600

**Steps to reproduce:**
* Install the **Accounting** module.
* Create a product category hierarchy (grandparent → parent → child).
* Set an **income account** on the grandparent category.
* Set an **expense account** on the child category.
* Leave the parent category without any accounts.
* Create a product assigned to the child category.
* Create a customer invoice using this product.

**Observed behavior:**
* The invoice line uses the **default income account** from settings instead of the grandparent category’s income account.
* The category hierarchy is not checked to retrieve parent accounts.

**Expected behavior:**
* If no account is defined on a category, Odoo should traverse the **parent categories** to find one.
* Only if no account exists in the hierarchy should it fall back to journal or default accounts.

**Cause:**
* Account lookup only checked the **immediate category**.
* Parent categories were not considered.

**Fix:**
* Traverse the product category hierarchy when searching for accounts.
* Use the first account found in the parent chain.

opw-5869592

Forward-Port-Of: odoo/odoo#249909
Forward-Port-Of: odoo/odoo#248389