Steps to Reproduce:
- Ensure the `sale_timesheet` module is installed.
- Log in as a user with Timesheet Administrator permissions but without access to the Project module.
- Attempt to open the Timesheets list view results in an `AccessError` due to missing read rights on `project.task`.
- Create a task in a private project linked to a timesheet and open its form view results in an `AccessError` due to missing read rights on `project.project`.

Cause:
- When a user has Timesheet Administrator access but lacks project access, they can view all timesheets, including those linked to tasks with private privacy visibility. However, these users do not have read access to the private tasks themselves.
- The `_compute_commercial_partner` method reads `task_id.partner_id.commercial_partner_id` and `project_id.partner_id.commercial_partner_id`. When a user without read access to `project.task` or `project.project` tries to compute this field, an `AccessError` occurs because the code tries to access these related records without bypassing access rights.

Solution:
- Use `sudo()` on `task_id` and `project_id` when accessing their `partner_id` fields inside the compute method to bypass access rights checks, preventing ` AccessError` for users lacking read permissions.

task-4798066

Forward-Port-Of: odoo/odoo#221247
Forward-Port-Of: odoo/odoo#210826

Bug introduced by: https://github.com/odoo/odoo/commit/b75394102bec3e25b23c75fd82ca0d8dec2726c5#diff-1281da5f4d0a3daaf162a2e6456469537d1b74b8034437783c9c717307aa8fcdR859

Steps to reproduce:
- Create two purchase orders with different vendors
- Add any product and confirm both orders
- From the purchase order list view, select both orders
- Click on "Create Bill"

Problem:
A traceback occurs when selecting multiple purchase orders with
different vendors and clicking Create Bill from the list view. This
is due to default_partner_id being forcibly set in the context, which
assumes a single vendor.

This bug was introduced by commit b753941, where default_partner_id is
always injected into the context, even when multiple vendors are
involved: https://github.com/odoo/odoo/commit/b75394102bec3e25b23c75fd82ca0d8dec2726c5#diff-1281da5f4d0a3daaf162a2e6456469537d1b74b8034437783c9c717307aa8fcdR714

Why it breaks:
When creating a bill, action_view_invoice() is called without verifying
that only one vendor is selected. Setting a default_partner_id in such
cases leads to invalid assumptions and crashes.

Difference with attachments case:
When uploading bills from attachments, a check does ensure a single
vendor is selected before calling action_view_invoice() (see b753941#R714).

Fix:
Only inject default_partner_id into the context if all selected
purchase orders share the same vendor.

opw-4948142

Since commit [1], the "Position" grid image option is not appearing anymore, making it impossible to change the `object-fit` property of the grid item images, making them forced to always be in `cover`.

The fix of commit [1] was made to avoid a traceback when toggling back to normal mode, because the `isApplied` was run after the grid mode was disabled but before the option noticed that it was not supposed to be there anymore. However, this was not the right fix, as it made the option not appear at all.

This commit removes this previous fix and fixes the issue by simply checking if the `o_grid_item_image` element is well present in `isApplied`(as it was done before the refactoring).

This commit also cleans the code a bit and renames the files/component/plugin/action so they are called `grid_image_` instead of `image_grid_`, to be more correct and to make the link with the old code.

[1]: https://github.com/odoo/odoo/commit/82882b7e3e24951aa7224a3a266e57cc4773e546

task-4367641

Steps to reproduce:
-------------------
1. Create a free product
2. Add it to self_order
3. Make a self order with only that product -> Free order

Sicne it's a free order, you will not be asked to pay, which is normal.
However, the issue is, no picking is created for that order!!

Why the issue?
--------------
For a non free self order, we create a picking for it by calling
`_process_saved_order` [1] with `draft` argument set to `True`, either
after paying using the online payment method [2], or after paying it
from the payment wizard [3]. However, since for free orders, we're not
asked at any point to pay, and hence, we're not calling
`_process_saved_order` with `draft=True` at any point, and as
consequence, we're also not calling `_create_order_picking`, no picking
will be created for it.

The fix
-------
After, marking the free order as 'paid', we manually call
`_process_saved_order(True)`. We only do it for the free orders, since
the flow is working as expected for non-free order.

[1]: https://github.com/odoo/odoo/blob/a7a29ed691db4f1607c0d12929c56845681164fa/addons/point_of_sale/models/pos_order.py#L153C19-L153C31
[2]: https://github.com/odoo/odoo/blob/a7a29ed691db4f1607c0d12929c56845681164fa/addons/pos_online_payment/models/payment_transaction.py#L64
[3]: https://github.com/odoo/odoo/blob/a7a29ed691db4f1607c0d12929c56845681164fa/addons/point_of_sale/wizard/pos_payment.py#L70

opw-4739523

Forward-Port-Of: odoo/odoo#221434
Forward-Port-Of: odoo/odoo#218118

Steps to reproduce
------------------
1. Create a Sales Order, add a product with QTY = X
2. Open PoS
3. Load this same Sales order (by clicking "Settle the order"-> QTX is
   X as expected
4. Return to Sales order (in the sales app)
5. Edit QTY from X to Y and save
6. Go back to PoS
7. Delete the laoded Sales Order and load it again
   -> Notice that QTY is still X and not the updated Y!!

Other Flow in frontend
----------------------
1. Create a Sales Order, add a product with QTY = X
2. Open PoS
3. Load this same Sales order (by clicking "Settle the order"-> QTY
   is X as expected
4. Change the quantity manually, to pay for X - 1
5. Validate and pay for the order
6. Load the same Sales order again with "Settle the order"
   -> The quantity is still X and the price is the unit price times X!!

Why the issue
-------------
When settling the order, we get its value using _getSaleOrder
which basically reads it from the cache. So it will read the old
order lines having the old qty, and not the updated one.

The fix
-------
Instead of reading the lines from the cache, we read them direcly from
the backend, to accomodate for cases where the data might have been
changed on another device or has not been updated in the cache.

opw-4819708
opw-4913397

Co-authored-by: Arthur Nanson <artn@odoo.com>

Forward-Port-Of: odoo/odoo#220813
Forward-Port-Of: odoo/odoo#218331

Before this commit, when in a discuss call in a chat window with at least 1 video, clicking on no main card had all cards sized for avatar, including the video stream.

This is a problem because the video stream are very small, barely visible, which is unfortunate because when there are video streams they are usually the most important thing that call participants want to see.

This commit fixes by adding a new CSS rule in chat window with call: when user in a call with at least 1 video stream, the size of call view matches the size of a 16:9 video stream when focused.

Part of task-4967123

Before / After
<img width="381" height="634" alt="Screenshot 2025-07-28 at 17 57 37" src="https://github.com/user-attachments/assets/878bae9f-01e5-4f81-9d61-b43180d4f809" /> <img width="385" height="637" alt="Screenshot 2025-07-28 at 17 57 17" src="https://github.com/user-attachments/assets/0261d716-e52c-4a72-ad6a-007c8d01a362" />

Forward-Port-Of: odoo/odoo#221124
Forward-Port-Of: odoo/odoo#220873

Before this commit, when the project is private and the user can only access to some tasks inside that project, he can create timesheets but cannot stop timer in one of those tasks when `industry_fsm` module is installed.

This commit makes sure the user can start/stop a timer on task for which he has access to even if the project is private and he does not have access to it.

Steps to reproduce the issue:
----------------------------

0. install industry_fsm module
1. Create a project A with "followers" as privacy visibility
2. Create a task A and assign it to a project user with lowest timesheet access right.
3. log in as that user
4. Start a timer on Task A
5. Stop the timer and confirm the wizard

Expected Behavior:
-----------------

The timesheet should be created without any issue

Current Behavior:
----------------

An Access error is raised because the user has no access to the project.

task-4680412

Forward-Port-Of: odoo/enterprise#91308
Forward-Port-Of: odoo/enterprise#84807

All-day calendar events were incorrectly causing unavailability for
appointment slots scheduled on the previous evening, due to mismatches
between local time and UTC.

Previously, all-day events scheduled for Tuesday were stored with a start time of 00:00 UTC.
In timezones like America/Chicago, this corresponds to 7:00 PM Monday. As a result, a valid
appointment booked from 6:30 PM to 8:00 PM local time on Monday would partially fall into
Tuesday in UTC (ending at 01:00 UTC), causing a false conflict with Tuesday’s all-day event.

The `calendar_verify_availability` method now calls the newly added `_get_date_boundaries`
which than computes naive datetime boundaries based on the user's local timezone by taking
the end of the previous local day and the start of the next local day. 

This change resolves those edge cases where evening slots crossing
the UTC boundary were falsely marked as unavailable due to timezone
misalignment.

opw-4614544

Forward-Port-Of: odoo/enterprise#90680
Forward-Port-Of: odoo/enterprise#85654

### Steps to reproduce:
	- Create an accrual plan with the following rule: 
	— The employee has 20 days off in the first year. Total 20. 
	— The employee has 21 days off in the second year and an additional 5 days off if available from the previous year, which can be taken until 6 months. Total 21 + 5 = 26 
	— The employee has 22 days off in the third year and an additional 5 days off if available from the previous year, which can be taken until 6 months. Total 22 + 5 = 27 
	— The employee has 23 days off in the fourth year and an additional 5 days off if available from the previous year, which can be taken until 6 months. Total 23 + 5 = 28
	- Create an accrual allocation with the created plan
	- Check future allocation data using 'Balance at the'
	- Notice the following behaviour: — until 31/12/2025 it CORRECTLY shows 20 days available.

		— from 01/01/2026 to 30/06/2026 it CORRECTLY shows 26 days (21 days for renewal and 5 days not used in 2025)
		— from 01/07/2026 it INCORRECTLY shows no days available.

		— from 01/01/2027 to 30/06/2027 it CORRECTLY shows 27 days (22 days for renewal and 5 days not used in 2026)
		— from 01/07/2027 it INCORRECTLY shows 5 days.

		— from 01/01/2028 to 30/06/2028 it CORRECTLY shows 28 days (23 days for renewal and 5 days not used in 2027)
		— from 01/07/2028 it INCORRECTLY shows no days available.

		— from 01/01/2029 it CORRECTLY shows 28 days again.
		— In the following years, after 6 months, one year shows 5 days and the next shows nothing.

### Cause:
The first cause here is that when we have validity for the carryover then we will have two calls in each year one at the start of the year and another at the expiration date of the carryover. So, when we add the days to the allocation we don't consider the second call in the condition and we only check if the allocation.actual_lastcall is equal to one of the start dates for each year

https://github.com/odoo/odoo/blob/3fb37cbc59adc2caace8efcdae418d2466a9b750/addons/hr_holidays/models/hr_leave_allocation.py#L588

The second cause where each two years one of them shows the number of carryover days from the previous year, this is happening because when we remove the expiring days for the first year we set the number of days to 0

https://github.com/odoo/odoo/blob/3fb37cbc59adc2caace8efcdae418d2466a9b750/addons/hr_holidays/models/hr_leave_allocation.py#L516-L517

And it will be 0 until we loop again and add the days to allocation

https://github.com/odoo/odoo/blob/3fb37cbc59adc2caace8efcdae418d2466a9b750/addons/hr_holidays/models/hr_leave_allocation.py#L521-L522

and since this is happening after we already set the expiring days which in this year will be 0 we won't remove those expiring days from the year's allocation data

### Fix:
We add a condition to check if the actual_lastcall is either a date in the start of the allocation or one of the expiration dates for the carryover.

Also, before we set the value of the expiring_carryover_days we call _add_days_to_allocation to calculate on the correct number of days for the plan level we are checking.

opw-4606886

Forward-Port-Of: odoo/odoo#221248
Forward-Port-Of: odoo/odoo#209669

Currently, a user error occurs when confirming a Sales Order (SO).

**Steps to reproduce:**

1) Install sale_project
2) Create a service product that generates a project and a task. 
3) Add a project template by creating one from the product form view. 
4) Create an SO by creating a customer with a company 
5) Add the above-created service product and confirm the SO.

**Error:**
A user exception will be triggered
```
The project and the associated partner must be linked to the same company.
```

**Cause:**

- When a project template is created from the product view, 
both the customer and the company_id default to empty.

- Later, when confirming a SO with a customer that belongs to a company, 
the new project's company_id is taken from the project template, which is empty.

https://github.com/odoo/odoo/blob/876e9d5e9ba87fa69188b2da098eec78f77040f5/addons/sale_project/models/sale_order.py#L140-L141

- However, the project’s partner_id (the customer) does have a company_id,
(since the customer value for the project will be set through SO's customer).

- This leads to a mismatch between the project’s company_id(which is empty) 
and its partner’s company_id. So a user exception will be triggered from the below lines

https://github.com/odoo/odoo/blob/876e9d5e9ba87fa69188b2da098eec78f77040f5/addons/project/models/project_project.py#L257-L258

**Solution:**

- If the project template has no company_id, and the customer of the project has one, 
set the project’s company_id to match that of the customer.

opw-4900741,4880495

Forward-Port-Of: odoo/odoo#216582

Steps to Reproduce:
- Ensure the `sale_timesheet` module is installed.
- Log in as a user with Timesheet Administrator permissions but without access to the Project module.
- Attempt to open the Timesheets list view results in an `AccessError` due to missing read rights on `project.task`.
- Create a task in a private project linked to a timesheet and open its form view results in an `AccessError` due to missing read rights on `project.project`.

Cause:
- When a user has Timesheet Administrator access but lacks project access, they can view all timesheets, including those linked to tasks with private privacy visibility. However, these users do not have read access to the private tasks themselves.
- The `_compute_commercial_partner` method reads `task_id.partner_id.commercial_partner_id` and `project_id.partner_id.commercial_partner_id`. When a user without read access to `project.task` or `project.project` tries to compute this field, an `AccessError` occurs because the code tries to access these related records without bypassing access rights.

Solution:
- Use `sudo()` on `task_id` and `project_id` when accessing their `partner_id` fields inside the compute method to bypass access rights checks, preventing ` AccessError` for users lacking read permissions.

task-4798066

Forward-Port-Of: odoo/odoo#221247
Forward-Port-Of: odoo/odoo#210826

**Steps to reproduce:**
- Install `point_of_sale`.
- Go to POS -> configuration -> settings
- Search 'Operation type' -> open picking type -> Disable `Create new`
- Create a storable product 'test' with serial tracking.
- Add on-hand quantity with serial numbers.
- In POS, select the product and choose one SN,
- Select it again and choose another SN.

**Observation:**
- The order line should have 2 quantities with a list of Serial numbers chosen by the user. For one quantity, it's working fine, but for multiple quantities, an issue occurs.

**Issue:**
- While confirming edit serial numbers popup for multiple quantities, it checks whether each selected SN is valid or not.
- The condition is that the entered SN is in the existing available SNs option. But the already chosen SN is not in the existing SN option,
- Also, creating a new SN is disabled, so it's considered an invalid input.
https://github.com/odoo/odoo/blob/876b7337eb689e0682ab48e9e833f9f0dc6bb8d2/addons/point_of_sale/static/src/app/store/select_lot_popup/select_lot_popup.js#L190-L193

**Solution:**
- Added a condition to allow SNs that are already selected (matched by name and ID) to be considered valid inputs.

opw-4865902

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

Forward-Port-Of: odoo/odoo#220932
Forward-Port-Of: odoo/odoo#219205

After this commit: odoo/enterprise@9dceed0896ce5089bccbc9cc2ce1e8c4b13f0048 [diff](https://github.com/odoo/enterprise/commit/9dceed0896ce5089bccbc9cc2ce1e8c4b13f0048#diff-de4a628e7837c273b67d71f93efab85b6a9ee957ea702f502066ebcc632a76cbL64)

The condition that handles hiding the basic wage on the payslip was not added —possibly it was missed. That’s why the "Hide basic on PDF" feature doesn’t work, regardless of whether it’s enabled, as the necessary condition is missing in the template.

Steps to reproduce (on runbot):
- In a v18 runbot, open any payslip and go to the salary structure. Enable the "Hide basic on PDF" option.
- Return to the payslip and print it.
- You’ll see that the basic wage is still printed on the payslip.


**Before Fix:**

<img width="669" height="238" alt="payslipbefore" src="https://github.com/user-attachments/assets/2fce67a2-19d8-45d8-88fa-4fc6a1767e68" />

**After Fix:**

<img width="683" height="289" alt="payslipafter" src="https://github.com/user-attachments/assets/adcb0104-9c4e-4a35-ba78-b3f278f6bfda" />

opw-4953831

Forward-Port-Of: odoo/enterprise#90798

Before this commit, discuss actions such as thread actions and message actions were defined differently from their own registries. The style of the actions are defined by component that make use of these actions, so lots of code differ in style and use and have to use same pattern to present these actions nicely.

Main problems are:
- each component using these actions have to define complex code for presentation of the actions
- style inconsistency

This commit improves by introducing a DiscussActions component, which accepts formatted lists of actions from thread, message, composer registries. This gives the benefit of easing the showing of these actions in UI by just mounting the `DiscussActions` component and provide list of actions to display.

Consequently to this improvement, style of discuss sidebar actions and discuss header actions have been changed to more closely look like usual odoo dropdown items and odoo control panel switch buttons.

Task-4982792

Before / After (white theme)
<img width="1106" height="906" alt="Screenshot 2025-07-30 at 16 24 09" src="https://github.com/user-attachments/assets/d0572f23-feca-4630-a651-9e779b6f1eb8" /> <img width="1107" height="898" alt="Screenshot 2025-07-30 at 16 23 35" src="https://github.com/user-attachments/assets/4326a902-51a2-4d60-86a3-6b010c5971e3" />


Before / After (dark theme)
<img width="1107" height="906" alt="Screenshot 2025-07-30 at 16 18 41" src="https://github.com/user-attachments/assets/600fae4e-20c4-4be7-8bbd-4d2890e930bf" /> <img width="1107" height="902" alt="Screenshot 2025-07-30 at 16 01 32" src="https://github.com/user-attachments/assets/5712a98d-6eac-4e2c-bed5-422e26960b1c" />

PURPOSE
In order to take into account the achievement rate based on recurring plan for MRR log on a renewal, we need to take into account transfer logs

SPECIFICATIONS
Take into account transfer logs in achievements computation. Source should be clear that it's a transfer log of a renewal

Example:

    If you have a Monthly sub to 100$/month but the yearly of 1000/year (MRR = 83.33) With a commission plan rewarding: 80% MRR of Monthly and 100% MRR of yearly
    If you renew a montlhy into a yearly --> MRR that was 100 become 83,33 so you have a negative MRR so a negative commission and a negative on yearly so with more weight (100% instead of 80)

Current:

    Renew in into yearly: 100% of MRR change -16.67 = -$16.67
    New monthly 80% of MRR change $100 = $80
    Total = 63.33 (modifié)

New

    New monthly 80% of MRR change $100 = $80
    Transfer 1 : 80% of MRR change -100 = -$80
    Transfer 2 : 100% of MRR change +100 = +$100
    Contraction of MRR: 100% of MRR change -16.67 = -$16.67
    Total = 83.33


Moreover this PR:
- fix a bug when achievements were duplicated when no currency was set.
- improve performances by creating a temporary table for invoice rules.


taskid-4783929

Forward-Port-Of: odoo/enterprise#91045
Forward-Port-Of: odoo/enterprise#88646

All-day calendar events were incorrectly causing unavailability for
appointment slots scheduled on the previous evening, due to mismatches
between local time and UTC.

Previously, all-day events scheduled for Tuesday were stored with a start time of 00:00 UTC.
In timezones like America/Chicago, this corresponds to 7:00 PM Monday. As a result, a valid
appointment booked from 6:30 PM to 8:00 PM local time on Monday would partially fall into
Tuesday in UTC (ending at 01:00 UTC), causing a false conflict with Tuesday’s all-day event.

The `calendar_verify_availability` method now calls the newly added `_get_date_boundaries`
which than computes naive datetime boundaries based on the user's local timezone by taking
the end of the previous local day and the start of the next local day. 

This change resolves those edge cases where evening slots crossing
the UTC boundary were falsely marked as unavailable due to timezone
misalignment.

opw-4614544

Forward-Port-Of: odoo/enterprise#91398
Forward-Port-Of: odoo/enterprise#85654

Steps to reproduce the bug:
- unarchive the subcontracting route
- Create a storable product C1 with the following route:
    - Buy + Resupply Subcontractor on Order
- Create a storable product P1 with:
    - BoM type: Subcontracting - Type: subcontracting - Subcontractor: Azure Interior - Component: C1

- Create a purchase order for 20 units of P1
- Confirm the purchase order
- Validate the resupply transfer
- Go to the receipt of P1
- Record 19.8 units of the component (ignore the remaining 0.2)
- Validate the receipt with no backorder

Problem:
A user error is raised:
```
The operation cannot be completed: The quantity to produce must
be positive!
```

When clicking No Backorder, the `process_cancel_backorder`  method is
called:

https://github.com/odoo/odoo/blob/18.0/addons/stock/wizard/stock_backorder_confirmation.py#L75-L77

This triggers the validation of the picking, so updates the subcontract
order quantity:

https://github.com/odoo/odoo/blob/16a1d9b19b8b07435a9c4b4db2cad3c1e37e4e17/addons/mrp_subcontracting/models/stock_picking.py#L53

At this stage, we check whether it should reduce the MO quantity or
cancel the order entirely. However, the logic compares the quantity to
remove against the initial order quantity without using `float_compare`,
which leads to minor rounding differences. This results to update the
MO quantity to zero instead of canceling it, which then triggers an SQL
constraint error because the MO quantity cannot be zero:

https://github.com/odoo/odoo/blob/e7e2a088495eed3c2886a69054af689c01628f32/addons/mrp_subcontracting/models/stock_move.py#L304-L311

https://github.com/odoo/odoo/blob/29d1f637d3ec6f3ebb218d103001a6182af1b8a4/addons/mrp/models/mrp_bom.py#L93-L95

opw-4905031

Forward-Port-Of: odoo/odoo#221273
Forward-Port-Of: odoo/odoo#219650

Before this commit, the available quantity was incorrect when using the "Inventory At" feature with a past date in the inventory report

For products using multi-step delivery routes, the `_compute_quantities_dict()` method incorrectly treated internal moves as outgoing moves As a result, the same outgoing quantity was added multiple times, leading to an overestimation of the available stock

This commit adds a filter to the `domain_move_out_done` domain used for past dates, excluding internal moves based on `location_dest_usage``

## Steps to reproduce:
- Create a new product
- Active the multi-step routes in Settings
- Set the Warehouse's Outgoing Shipments to Pick, Pack, then Deliver
- Create a RFQ for 100 products and Receive Products
- Create a Quotation for 20 products
- Validate each delivery steps
- Go to Inventory -> Report -> Stock
- Click on Inventory At
- Set the date to 2025-01-01
- Search for your product
- The `In Hand` quantity should be 0 but is 40 before the fix

opw-4848473

Issue:
currently, when a user initiates applying a promo code but then discards
it before completing the process. the system still marks the
code as used,

https://github.com/odoo/odoo/blob/204eb9b0737634826c4666f85d0b9d39aeed0ee6/addons/sale_loyalty/models/sale_order.py#L1378-L1379

resulting in a false-positive validation on subsequent attempts
https://github.com/odoo/odoo/blob/204eb9b0737634826c4666f85d0b9d39aeed0ee6/addons/sale_loyalty/models/sale_order.py#L1352-L1355

to reapply the same code.

Steps to reproduce:
- Create a record in "Discount & Loyalty"
- select "Discount Code" in program type field.
- From the conditional rules, copy the discount code.
- Create a sale order and select a product.
- Click on Coupon Code button and paste the code copied in step 3 in Coupon Code
 field.
- Click Apply.
- A wizard of Available Rewards will be opened. Now click the Discard button.
- Repeat last 3 steps

Observation:
- It gives a Validation Error: "This promo code is already applied."

Fix:
- we introduce action_discard() method, which will un-use the coupon , in case user discard the reward dialog box.

opw-4961738

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

Issue:
When the "Lock Confirmed Sales" setting is enabled, adding a product to a Field Service task would lock the associated sales order before its picking could be created. The confirmation process locks the order first , and the subsequent step to create stock moves (`_action_launch_stock_rule`) explicitly skips locked orders.

Reproducible on 17.0~master
[Task](https://www.odoo.com/odoo/action-4043/4633977)
Odoo 17:
https://drive.google.com/file/d/1qmAYhSu6gU91efuJEDF-Irn2cLGUQP0A/view?usp=drivesdk

Odoo 18:
https://drive.google.com/file/d/1x8IeXwT7ZFM7Av9Vp6GSvGIbOaEGfmVx/view?usp=drivesdk


Steps to reproduce:
1. In Sales > Configuration > Settings, enable "Lock Confirmed Sales".
2. Go to a Field Service task.
3. In the kanban view via the "Products" smart button, add a product.
4. Come back to the task, refresh the browser, open the linked Sales Order from the smart button.
5. **Before this fix:** The SO is locked, no picking is created, and SO lines will have delivered_qty set even though we haven't delivered anything.
6. **After this fix:** The SO is not locked, and a Delivery smart button is correctly displayed, linking to the generated picking.

This behavior left the sales order in an inconsistent state: it was locked, but had no corresponding delivery order. As a result, users were blocked from removing or modifying the products added to the task, as the system prevented edits on a locked order with no picking to cancel.

Let's step through what's going on here;

0. We enable "Lock Confirmed Sales" option.
1. Add a product to the Field Service(FS) task https://github.com/odoo/enterprise/blob/4256ea170c31209b83ff808e51145757571f8556/industry_fsm_sale/controllers/catalog.py#L19-L42
https://github.com/odoo/enterprise/blob/4256ea170c31209b83ff808e51145757571f8556/industry_fsm_sale/controllers/catalog.py#L38
2. set_fsm_quantity() is invoked, which will create a SO for the FS task https://github.com/odoo/enterprise/blob/35e1f47160d5840e8701fc0ad43ec42bbfaf9e36/industry_fsm_sale/models/product_product.py#L144
3. `_fsm_create_sale_order()` will immediately `action_confirm()` the new SO, because of the reasons in the function description. 
( Since we are immediately confirming newly created SO, I think we should consider not applying the "Lock Confirmed Orders" option to FSM SOs.)
https://github.com/odoo/enterprise/blob/2347dac2568dbcf83578f044f8fe41ab70a20f47/industry_fsm_stock/models/project_task.py#L124-L134 https://github.com/odoo/enterprise/blob/2347dac2568dbcf83578f044f8fe41ab70a20f47/industry_fsm_stock/models/project_task.py#L134
4. `odoo/addons/sale/models/sale_order.py/action_confirm()` will lock SO because we enabled 'Lock Confirmed Sales'
https://github.com/odoo/odoo/blob/863c064fd911cb4eeedad0abec82adb4690128f6/addons/sale/models/sale_order.py#L964
6. `_action_launch_stock_rule()` is invoked, is in charge of creating Pickings for SOs 
https://github.com/odoo/odoo/blob/3be83d363786526fe470e41122169e594b5467fb/addons/sale_stock/models/sale_order_line.py#L303
https://github.com/odoo/odoo/blob/3be83d363786526fe470e41122169e594b5467fb/addons/sale_stock/models/sale_order_line.py#L343-L344
7. But, since `line.order_id.locked` , the system do not create Pickings for the SOs. https://github.com/odoo/odoo/blob/3be83d363786526fe470e41122169e594b5467fb/addons/sale_stock/models/sale_order_line.py#L315-L316
The line was introduced by
https://github.com/odoo/odoo/commit/17bece3e797913bcba8dd7e07fc8541c0a45e3f7

This commit resolves the issue by passing a context key `fsm_create_sale_order=True` when confirming a sales order that is being created from a Field Service task. The `_should_be_locked` method on the sale order is overridden to check for this context key. If the key is present, it prevents the order from being locked within that specific transaction, allowing the stock rules to execute correctly and create the necessary picking. The order will be locked for any subsequent operations as intended.

Tradeoff here;
We are sacrificing the universal application of one feature (automatic lock on confirmed sales order) to fix a critical bug that makes the entire FSM delivery process unusable.

---
EDIT: 
Without this change, all of [test_fsm_stock](https://github.com/odoo/enterprise/blob/17.0/industry_fsm_stock/tests/test_fsm_stock.py)'s test cases that use `_fsm_ensure_sale_order()` will fail if the setting is on. (around ~20 test cases). 

[In the past, similar issue occurred for Subscription Orders, and the PO confirmed that the "Lock Confirmed Order" setting should never affect the subscriptions. ](https://github.com/odoo/enterprise/commit/e4f9d76c0a58f3cc226a2372f3936cea4547312e). This commit takes the same approach to ignore the setting upon SO confirmation. 

opw-4633977
opw-4749653
opw-4880664

Forward-Port-Of: odoo/enterprise#88855

When importing a winbooks file the following issues and or inconsistencies may be found

**Issue 1**
We may import an account with CENTRALID 'V03' and code 45100000 Having this centralID means that it will be set as tax payable account id according to https://github.com/odoo/enterprise/blame/d8d4812414dba8825a1c785c29d00f7d0fd98360/account_winbooks_import/wizard/import_wizard.py#L174 However, this means it needs to be a `liability_payable` account with reconcile enable, in order to comply with the following check https://github.com/odoo/odoo/blame/ad6c9001b447f5ffebafe1581512f48708c7d746/addons/account/models/account_tax.py#L80

*Note*
Even if we set it as liability_payable, the import may fail later on in case the same account is used in a sales move where those types of account are not allowed https://github.com/odoo/odoo/blame/1b657cf1e1ce43874a3ede307b2f8ad68216aa56/addons/account/models/account_move_line.py#L1247 A solution is to skip the `_check_payable_receivable` check for winbooks lines

**Issue 2**
Move line data may reference an unkown journal, causing a validation error because no journal is retrieved from the database and a move always need a journal

**Issue 3**
Account created during import may be marked for deprecation, which occurs at the end of the import process.
However, if the account has been used in a tax repartition line, trying to set it as deprecated will raise an error.
https://github.com/odoo/odoo/blame/2cdc41c012f637849ba030989ce928b6b1152e7e/addons/account/models/account_account.py#L1028

opw-4850314

Issue
-----
On iOS 18.5, users can get a `NotSupportedError` when trying to scan a barcode from the (barcode) main menu.

Steps to reproduce
-----
- Open barcode
- Click the center scan button
- Scan a barcode

--> Traceback

Discussion
-----
There are 2 issues occuring here.

1. We play either an ogg or mp3 file. However, the method to know if the format is supported by the browser returns one of 'probably', 'maybe', ''.

https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/canPlayType#return_value

This means that when we do

https://github.com/odoo/enterprise/blob/70e5013ea022ed04ff27db71ea3ecccb55ae1f70/stock_barcode/static/src/main_menu/main_menu.js#L37

We might end up using ogg even if the browser doesn't actually support it, as 'maybe' is truthy.

To reduce the risk of this happening, we can specify the codec as "vorbis" (all ogg files of Odoo are vorbis). This is already done in mail:

https://github.com/odoo/odoo/blob/cd4c1d599ea9403ce3791e239ad765d946446a47/addons/mail/static/src/core/common/sound_effects_service.js#L46

2. The browser might not have the permission to play the sound. In such cases, the best we can do is try to play the sound and log potential errors.

-----
Ticket:
opw-4820022

**Issue**:
The expiration date displayed in the barcode app's scan screen may appear incorrect.

**Steps to reproduce**:

- Go to Settings > Inventory, and enable the `Expiration Date` field
- Open the Purchase app
- Create a new Request For Quotation
- Select a product that:
	- is a good tracked by lot
	- has the `Expiration Date` field enabled (Inventory tab > Traceability)
- Confirm the RFQ
- Click the `Receipt` smart button
- Click the `hamburger button` and enter an expiration date at midnight.
- Go to the Barcode application > Operation > Receipts
- Open the corresponding RFQ
- Click Edit and increase the quantity to 1, then Validate
- Observe that the date is displayed as one day earlier

**Cause**:
The code https://github.com/odoo/enterprise/blob/b5ad18b101f4a2608758762edf0f49270a67ba20/stock_barcode_product_expiry/static/src/components/line.js#L17 assumes that the date is encoded using the local while the date comes from the server https://github.com/odoo/enterprise/blob/b5ad18b101f4a2608758762edf0f49270a67ba20/stock_barcode_product_expiry/static/src/components/line.js#L13, and thus is utc encoded. So for example, if the user's timezone is `Europe/Brussels`, a midnight timestamp will appear as 10 PM the previous day.

**Solution**:
To solve this issue, use this method https://github.com/odoo/odoo/blob/7a40285fd03f75f07a74f05d4b60e760e1c83eb3/addons/web/static/src/core/l10n/dates.js#L619-L622 instead of https://github.com/odoo/odoo/blob/7a40285fd03f75f07a74f05d4b60e760e1c83eb3/addons/web/static/src/core/l10n/dates.js#L514-L516. This way, it would parse the utc-base server date as a utc-base date.

opw-4865513

Forward-Port-Of: odoo/enterprise#88526