Before this commit, the `test_knowledge_main_flow` tour sometimes failed. That tour creates articles, then d&d one of them in the sidepanel to re-organize articles, and then clicks on a previously created article to continue editing it. The tour failed on that step, as the previously created clicked article wasn't properly selected/displayed in the editor.

The race condition was that two (non synchronized) calls to the `load` function of the model were done: one after the move because the move could have altered the displayed article (1) and one because we selected another article to open by clicking in the sidebar (2). (1) is done without resId (reload the current article) and (2) is done with the id of the clicked article.

Depending on the order these two calls are done, we end up with the clicked article displayed (if (2) is done after (1)), or with the current article still displayed, but reloaded ((1) done after (2)).

This commit fixes the race condition by forcing the reload of the current record for (1), instead of blindly reloading the model, which might have changed/been requested something else meanwhile.

runbot error~182073

Forward-Port-Of: odoo/enterprise#99174

… correct remaining value when sbc dropship

**Problem:**
When selling and delivering a subcontracted and dropshipped fifo product, 
the incoming stock valuation layer has a remaining_qty and a remaining_value.
(This also happens with 'standard price' and 'avco' but it's mostly problematic for 
fifo products. This being said the fix solves all 3 cases)

Some context: 
When we confirm a SO and validate the delivery of a dropshipped (not sbc) product,
two svls are created, 
   - one with a negative quantity and value.
   - one with positive quantity and value.
 
Both have a zero remaining value and remaining quantity.
The outgoing svl does not trigger run_fifo or decrease the remaining_qty 
and remaining_value on any svl.
In other words the fifo logic is not applied.
If it was the case, the dropship delivery would impact the fifo valuation and 
other layers which we don't want as the product never really entered the stock.
 
In the use case of this PR, a subcontracted dropshipped fifo product being delivered, 
the outgoing svl(s) are linked to the dropship and have the correct values. 
But the incoming svl is linked to the subcontract order and has a remaining value
and remaining quantity which will impact the fifo logic when it shouldn't.

**Steps to reproduce:**
- enable the subcontracting setting and the dropshipping setting.
- create a storable product, with a fifo category and positive cost.
- create a subonctracted bom with a consumable component.
- in the purchase tab of the product set a vendor which is the same
as the subcontractor of the bom.
- in the inventory tab select only the dropship route
- create and confirm a SO for this product.
- on the PO enter a positive unit price and confirm
- validate the dropship delivery
- click on the valuation smart button

**Current behavior:**
the stock valuation layer linked to the subcontract picking (the one with a 
positive quantity) has a positive remaining quantity and remaining value.

**Expected behavior:**
As the product is dropship remaining quantity and remaining value should be 0

**Cause of the issue:**
When action_done is called on the picking:
1) In the super method,
action_done is called on the move.
There, _create_dropshipped_svl is called.
https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/stock_account/models/stock_move.py#L289
Inside _get_dropshipped_svl_vals only the value for the (first) outgoing svl
is returned because the location_id (subcontrating location) is valued.
https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/stock_account/models/stock_move.py#L226

2) In the mrp_subcontracting override, button_mark_done is called on 
the mrp.production associated with the picking.
https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/mrp_subcontracting/models/stock_picking.py#L90
Therefore action_done is called on the finished products move the mrp.production.
https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/mrp/models/mrp_production.py#L1731
The move is a 'in' move so this lead to the creation of an in svl.
https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/stock_account/models/stock_move.py#L289
The problem is that there is no mechanism to prevent the in svl from having 
a remaining_value and remaining_qty

**fix**
The mrp_subcontracting_dropshipping override of _action_done (on stock picking)
is where, when needed, the other ougoing layer is created specifically in this 
subcontracting dropshipping use case.
https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/mrp_subcontracting_dropshipping/models/stock_picking.py#L27-L32
Because the conditions are the same, imo, it's a good place to set the value of 
remaingin_value and remaining_qty of the incoming svl to 0.

opw-5184644

Forward-Port-Of: odoo/odoo#234573
Forward-Port-Of: odoo/odoo#233041

…or flexible working schedules

```
odoo.exceptions.UserError: Código Python erróneo definido para:
- Empleado: Donovan Raziel Castillo
- Versión: False
- Recibo de nómina: Payslip Simulation
- Regla salarial: Holidays On Time to Substruct (HOLIDAY_TO_SUB)
- Error: float division by zero
```
Steps to reproduce:
1. Create a new database in saas-18.4 and install: resource, l10n_mx, l10n_mx_hr_payroll, hr_payroll, hr_contract_salary_payroll
2. Go to the Recruitment app → create a Salary Offer.
3. Assign a name, an applicant, and a contract template.
4. In the contract template:
   - Name: Department
   - Contract Type: Permanent, employee_mexico
   - Working Hours: create a new schedule
5. Set Schedule Type = Flexible
6. Fill Hours per Week (`full_time_required_hours`) (e.g., 48) → Notice that Hours per Week and Work Time Rate are not visible.

In saas-18.4, when a working schedule is configured as Flexible, the computation of `work_time_rate` results in 0.0 because the field `hours_per_week` remains unset (it is only visible when Flexible Hours is [False](https://github.com/odoo/odoo/blob/saas-18.4/addons/resource/views/resource_calendar_views.xml#L85-L92)). As a result, during migration, when the computation occurs in `hr_contract_salary_offer`, A division by zero error is raised during the salary rule Python computation.

Root cause:
When the calendar is flexible, and Hours per Week (`full_time_required_hours`) are defined, the computation of `work_time_rate` returns 0.0. As a result, when the salary rule computation (`_compute_rule`) performs a division using this zero value, a ZeroDivisionError occurs.

Technical point of view:
The error occurs because the Work Time Rate is not being calculated correctly. In both versions [18.4 ](https://github.com/odoo/odoo/blob/saas-18.4/addons/resource/models/resource_calendar.py#L143-L151)and [19.0](https://github.com/odoo/odoo/blob/19.0/addons/resource/models/resource_calendar.py#L250-L258), the compute logic is the same — it depends on the fields `hours_per_week` and `full_time_required_hours`.

However, in this case, the computation behaves incorrectly. If the customer provides a value for Equivalent Working Hours, the code enters the `if` [condition](https://github.com/odoo/odoo/blob/saas-18.4/addons/resource/models/resource_calendar.py#L146) to calculate the Work Time Rate. Since the field `hours_per_week` is only visible and its [computation] (https://github.com/odoo/odoo/blob/saas-18.4/addons/resource/models/resource_calendar.py#L136-L141) happens when Flexible Hours is [False](https://github.com/odoo/odoo/blob/saas-18.4/addons/resource/views/resource_calendar_views.xml#L85), its value remains 0, which leads to a Work Time Rate of 0.0 always.

On the other hand, in the `else` [condition](https://github.com/odoo/odoo/blob/saas-18.4/addons/resource/models/resource_calendar.py#L148), the Work Time Rate is directly set to 100. This means that when Flexible Hours = True and Equivalent Working Hours is not filled in, the calculation always results in 100.

Solution:
To fix this issue, we should make both Work Time Rate and Hours per Week visible in the form view for the customer. This fix aligns the behavior with the version 19.0 [In 19.0 the both `hours_per_week` and `work_time_rate` visible for the user from this [IMP](https://github.com/odoo/odoo/commit/5cb102546ea4370b4fe5e4a4f37cccdc90c263fd) fix.] by making both `hours_per_week` and `work_time_rate` visible in the working schedule form view. This allows users to correctly configure these fields when using flexible calendars and prevents incorrect or zero-based calculations.

In summary:
The issue only occurs when Flexible Hours = True — in that case, the Work Time Rate calculation always results in 0.0. Showing both fields to the user ensures proper configuration and avoids incorrect computation.

UPG:- 3269714
OPW:- 5124639
Errro-Pad :- https://pad.odoo.com/p/issue_5124639_labo

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/a8ebab8f8 [REL] 18.4.17 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/e053137c8 [FIX] TopbarMenu: specify `isReadonlyAllowed` [Task: 5245432](https://www.odoo.com/odoo/2328/tasks/5245432)
https://github.com/odoo/o-spreadsheet/commit/b5c217ff8 [FIX] range: invalid sheet name with special character [Task: 5125762](https://www.odoo.com/odoo/2328/tasks/5125762)
https://github.com/odoo/o-spreadsheet/commit/2470a53f2 [FIX] composer: set editionMode to inactive when composer is unmounted [Task: 5149215](https://www.odoo.com/odoo/2328/tasks/5149215)
https://github.com/odoo/o-spreadsheet/commit/e9ca3de5c [FIX] filter menu: truncate long filter values [Task: 5219611](https://www.odoo.com/odoo/2328/tasks/5219611)
https://github.com/odoo/o-spreadsheet/commit/a4733d2b1 [FIX] chart: add placeholder for axis title input [Task: 5187080](https://www.odoo.com/odoo/2328/tasks/5187080)
https://github.com/odoo/o-spreadsheet/commit/15da32f9d [PERF] zones: faster isZoneInside [Task: 5213090](https://www.odoo.com/odoo/2328/tasks/5213090)
https://github.com/odoo/o-spreadsheet/commit/19506f3bd [PERF] Renderer: speed-up box generation [Task: 5213090](https://www.odoo.com/odoo/2328/tasks/5213090)
https://github.com/odoo/o-spreadsheet/commit/56e9c8288 [FIX] charts: crash when converting empty chart to scorecard/gauge [Task: 5181741](https://www.odoo.com/odoo/2328/tasks/5181741)
https://github.com/odoo/o-spreadsheet/commit/cc30312f4 [FIX] Package: update owl to 2.8.1 [](https://www.odoo.com/odoo/2328/tasks/)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

Versions
--------
- saas-18.4+

Steps
-----
1. Create a branch company B;
2. create a branch C for the branch company B;
3. change to branch C;
4. create a warehouse;
5. enable dropshipping;
6. add a vendor to a stored product with the Dropship route enabled;
7. log in as a sales user with access to branch C only;
8. add product to a sales order & confirm.

Issue
-----
> Access Error
> Uh-oh! Looks like you have stumbled upon some top-secret records.
> Sorry, Marc Demo (id=5) doesn't have 'read' access to:
> - Companies, YourBranch (res.company: 3)

Cause
-----
The error gets thrown during the `_prepare_purchase_order_line` method, specifically on the line which filters `supplier_taxes_id` using `lambda x: x.company_id in company_id.parent_ids`.

This passes via the field's `convert_to_record` method, which attempts to access the `active` field of the companies to filter out any that are archived[^1].

[^1]: https://github.com/odoo/odoo/blob/5b911a97a3885283d2f21ac30abb96cb10fe39d9/odoo/orm/fields_relational.py#L608-L612

In previous versions, this wasn't an issue, because the `active` field was still present in cache from the `_compute_parent_ids` which is called with `sudo`, but as of saas-18.4, it attempts to refetch these values, leading to the error.

Solution
--------
Instead of using `filtered`, use `filtered_domain` using the result of `account.tax._get_company_domain`.

opw-5112625

**Issue**
When creating a partial credit note (i.e., for a quantity less than originally invoiced) for a subscription invoice, the `qty_invoiced` on the corresponding subscription order line is incorrectly set to zero, instead of reflecting the remaining quantity.

**Steps to Reproduce**
1. Create a subscription with a quantity of 50.
2. Confirm the subscription and generate an invoice.
3. Create a credit note (reversal) for the invoice.
4. Change the credited quantity to 30.
5. Post the credit note.
6. The subscription order line shows qty_invoiced = 0 instead of the expected 20.

**Root Cause**
The method `_get_max_invoiced_date()` is used to determine the latest invoiced period for a subscription. In its original implementation, it removes refunded periods from the list of invoice dates regardless of whether the refund is partial or full. This causes the system to consider the period as not invoiced at all, which leads to incorrect recomputation of `qty_invoiced`

**Fix**
Adjust `_get_max_invoiced_date()` to track the net invoiced quantity per period. A period is only removed from the list of invoice dates if it has been fully refunded (i.e., net quantity is zero). This ensures that partially refunded periods are still considered invoiced, and the `qty_invoiced` is correctly updated to reflect the remaining quantity

Opw-4908760

Forward-Port-Of: odoo/enterprise#98892
Forward-Port-Of: odoo/enterprise#91344

Steps to reproduce the bug:
- Create a storable product "P1" and "P2" with vendor "azure interior"
- for P2 subcontracting BoM referencing "azure interior" as subcontractor and component "C1"
- Create a receipt for partner "azure interior" including 1 unit of P1 and 1 unit of P2
- Validate the receipt
- Create a return for both P1 and P2

Problem:
A picking is created with destination location set to the subcontracting location for both products,
instead of setting the partner location only for subcontracted products.

Solution:
Ensure only the move line for subcontracted products uses the subcontracting destination location,
while other returned products go back to the supplier location.

When the `picking_id.partner_id`` is changed, it triggers a write on the
picking, which in turn triggers a write on its moves, but only on the
ones that are not scrapped.

However, since the `scrapped`` field is a stored computed field, and as
it hasn't been accessed before, it needs to be computed. And because
its computation depends on `location_dest_id`, that field also needs
to be recomputed. as a result, the `location_dest_id`` of the moves that
we manually set may be changed unexpectedly.

Therefore, in the `_create_return`` function, we check that the
picking’s `partner_id` is different from the moves’ partner_id before
updating it, to avoid unnecessary writes and the chain of recomputations
that could alter our values.

Resetting the picking’s partner_id based on the move’s partner_id could
actually be removed in master, as it serves no real purpose,
the move.partner_id itself is already derived from the picking’s
partner_id. We just keep it in stable versions to avoid any unexpected
behavior changes.

opw-5208289

Forward-Port-Of: odoo/odoo#234521