[FIX] l10n_ch: fix default contract type

This task is runbot error fix that occured from 19.0 to 19.2

Bug reproduction:

1 - Go to version 19.0, install l10n_ch_hr_payroll_account 2 - Execute test_version_timeline_auto_save_tour tour test 3 - It fails in .o_arrow_button_wrapper[data-tooltip^='Contract:'] step

Bug cause:

1 - When l10n_ch_hr_payroll_account is installed:

    1.1 - contract type becomes "Permanent contract with monthly salary"
    1.2 - the employee is not swiss but it has this CH contract type

2 - data-tooltip starts with Permanent contract instead of contract

    2.1 - Tour fails

3 - contract_type_id is overwritten in swiss modules

    3.1 - Default is assigned without looking to the country of self.env

Bug solution:

1 - If the country is not swiss, the default is assigned as False

    1.1 -> fixed in l10n_ch_hr_payroll/hr_version

    1.2 instead of assigning swiss contract type to the non-swiss emp.

Note: This is fix from saas-18.4 to master.

task-6392040

runbot error: https://runbot.odoo.com/odoo/runbot.build.error/941358

Forward-Port-Of: odoo/enterprise#126520

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

When importing a SODA XML file, users without the Analytic Accounting
group encounter an access rights error.

This occurs because the import wizard reads the `analytic_account_id` field
on the `soda.analytic.mapping` model to build an internal dictionary of
departments. Because this field is restricted to the Analytic Accounting
group, the evaluation of this field crashes the import for users even when
the Analytic Accounting feature is disabled.

This commit prevents the crash by using `.sudo()` when reading the analytic
account ID. This safely bypasses the field-level group restriction, allowing
the dictionary to be built with False values without interrupting the core
import process.

**Steps to reproduce:**

- Log in as Mitchell Admin, change company to “My Belgian Company”
- Settings > Users & Companies > Users > Mitchell Admin > Access Rights > Extra Rights > ensure “Analytic Accounting” is unchecked
   - Also ensure Mitchell Admin is not part of the “Analytic Accounting” group
- Accounting Dashboard > remove “Favorites” from filter > drag & drop a SODA XML file to “Miscellaneous Operations” > save > observe Access Error


**Current behavior before PR:**

- Users who don't belong to the Analytic Accounting group encounter an access error when attempting to import SODA XML files, even when the Analytic Accounting feature isn't enabled

**Desired behavior after PR is merged:**

- Those users no longer receive an access error

opw-6376039

Before this commit, some layouts had the customer address on the right
(light, boxed, bold, striped) and some had it on the left (bubble, wave,
folder). For the latter, when an information_block with the address existed,
it would be inserted before the address pushing it further right. This was
inconsistent since the address position should not depend on whether an
information_block is present or not.

The customer address must stay in a fixed place to match the transparent
window of the envelope when sending a physical letter by snailmail.

This commit fixes this issue by ensuring that in all cases the customer
address position stays fixed regardless of the presence or absence of
the information_block and regardless of the layout used for the letter.

It also fixes the addresses displayed on the sale order report:
1) If invoicing address = partner address != shipping address
or invoicing address != partner address = shipping address
then the three addresses would be printed, even though 2 addresses
are identical.
2) The shipping address and the invoicing address are now printed
horizontally rather than vertically to get rid of the resulting large
blank block under the partner address in that case.

backport of: https://github.com/odoo/odoo/pull/276622

task-6340467

Forward-Port-Of: odoo/odoo#281937
Forward-Port-Of: odoo/odoo#273640

Steps to reproduce:
-------------------
1. Install `hr` module
2. Create two employees (e.g., emp1 and emp2) and assign
   emp1 as the manager of emp2
   → emp2 is now a direct subordinate of emp1
3. In the employee list view, apply the custom filter
   "Direct subordinates is set" (child_ids != False)
   → emp1 appears in the results as expected
4. Archive emp2
5. Apply the same filter again
   → emp1 still appears in the results even though it has
   no active subordinates

Issue:
------
When an employee (e.g., `emp2`) is archived, their manager (`emp1`) should no longer appear in the "Direct subordinates is set" (child_ids != False) filter — since `emp1` no longer has any active subordinates.

However, `emp1` still appears in the search results after `emp2` is archived, because the underlying EXISTS subquery checks all subordinates regardless of their active state.

Cause:
--------
Before this commit 5ef007a, `osv.expression`, filtering on a One2many field would automatically
search against [active co-records ](https://github.com/odoo/odoo/blob/5f65e92d7fa341193df53f5aba1620b596f9a1ec/odoo/osv/expression.py#L1260-L1265)only by default.

After that commit, the `condition_to_sql` method in `_RelationalMulti` constructs the comodel with [active_test=False](https://github.com/odoo/odoo/blob/463ca4cf867812890c17d1e1abf7640b04f70ad0/odoo/orm/fields_relational.py#L672-L686) when resolving relational field conditions. This causes the EXISTS subquery generated for `child_ids != False` to compare against all subordinates. (including archived ones rather than active ones only).

Solution:
---------
Added a callable `domain` attribute on the `child_ids` field definition so that only active subordinates are considered by default. This ensures [get_comodel_domain()](https://github.com/odoo/odoo/blob/2d8b24a791b6fe6bb214c32d4fb58b3d46eca70b/odoo/orm/fields_relational.py#L75-L85) returns a server-side domain that filters out archived subordinates, making the `child_ids != False` filter behave as expected.




opw-6193104



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

Forward-Port-Of: odoo/odoo#281222
Forward-Port-Of: odoo/odoo#266658

Description of the issue/feature this PR addresses:

Installing Odoo via the .deb package continuously causes issues with the asset bundles. This is because of the following daisy chain of behaviors:

- `dpkg-buildpackage` parses `SOURCE_DATE_EPOCH` from debian/changelog and then clamps the Modified date of all files to at max that epoch ([src](https://launchpad.net/debian/+source/dpkg/1.18.8)). The relevate date is the one written after the email in the topmost changelog entry
- This is preserved when unpacking the .deb package, the OS does not change it
- The Asset loading logic in ir.qweb and ir.asset relies on the Modified date (via [`os.path.getmtime`](https://github.com/odoo/odoo/blob/17.0/odoo/addons/base/models/ir_asset.py#L49)) to determine the hash that serves a Version for the asset bundles ([src](https://github.com/odoo/odoo/blob/17.0/odoo/addons/base/models/assetsbundle.py#L775), [src](https://github.com/odoo/odoo/blob/17.0/odoo/addons/base/models/assetsbundle.py#L148))
- The controller and ir.qweb compiler rely on this Version hash to correctly invalidate outdated asset bundles and force re-generation of the bundle content as neccessary

Current behavior before PR:

debian/changelog has not been changed or maintained since 2020 and its timestamp remains `Tue, 15 Dec 2020 10:28:49 +0100` This results in the Modified Date being clamped to 2020, which means the files no matter how much is changed always look like last modified on this date. Therefore the Version hash for the asset bundles never changes, and the asset reload logic does not trigger correctly.
This is especially dangerous for setups which use several code sources with different file delivery methods, for example installing Community via .deb but Enterprise via git. This results in only some asset bundles not being updated (those not touched by Enterprise modules) while others are, which then generates an OWL error as it detects the content being different between the bundles ([src](https://github.com/odoo/odoo/blob/17.0/addons/web/static/lib/owl/owl.js#L3333))
For versions 18+, a very common result of this behavior is the portal chatter failing to work. This is because the same files like for example mail/static/src/core/common/thread.xml being loaded into both [`portal.assets_chatter`](https://github.com/odoo/odoo/blob/18.0/addons/portal/__manifest__.py#L69), which is not touched by an Enterprise module, but also into [`web.assets_frontend`
](https://github.com/odoo/odoo/blob/18.0/addons/im_livechat/__manifest__.py#L90) via im_livechat, which is a bundle touched by many modules, including Enterprise modules. Thus, is a file in the mail addon is changed, the changes are correctly applied to `web.assets_frontend`, but not `portal.assets_chatter`, causing an OWL error. This is extremely frustrating to fix, since it not only requires a manual Asset Rebuild, but also for every user to empty their Browser Cache, since the assets bundles are so large as to be guaranteed to be cached, and if the old version of the bundle is loaded from cache, the OWL error persists. A similar error can also happen with website, since the assets for the WYSIWIG editor are loaded as a module-specific bundle, `website.assets_wysiwyg`, which also fails to update, while of course the same assets being loaded to the general website asset bundle will be updated.

Desired behavior after PR is merged:

The builder for the nightly .deb package of Odoo writes a complete debian/changelog entry instead of merely replacing the first line. This entry includes the current date, thus ensuring the Modified date for the files is not clamped to years in the past. Down the line, this fixes the assets loading issue.


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

Forward-Port-Of: odoo/odoo#269458

### Issue before this commit:
Before commit f2965048f60fe6c815b3e50fa714c97a93dfb5d3, company_type allowed manually selecting whether a contact was an individual or a company. After the commit, is_company became a stored computed field derived from the VAT number, with no manual override available in the standard UI, and no exception was added for Spanish DNI/NIE formats.

### Steps to reproduce the issue:
1. Download Accounting and l10n_es
2. Set as VAT of ES company 47857909S (or similar but must be a DNI or NIE format)
3. Create an invoice for a Spanish customer
4. Send the invoice with Facturae
5. Check the XML created and see that the tag <PersonTypeCode> of <SellerParty> has a J (legal entity) rather than an F (individual)

### Cause of the issue:
The Spanish localization's _compute_is_company override only adds the check for CIF-formatted VAT numbers (for [legal entities](https://sede.agenciatributaria.gob.es/Sede/ayuda/manuales-videos-folletos/manuales-practicos/guia-practica-cumplimentacion-modelo-censal-036/anexos/anexo-01-solicitud-nif-documentacion-aportar/informacion-sobre-numero-identificacion-fiscal/composicion-nif/personas-juridicas-entidades.html)) but it has no corresponding negative check for DNI or NIE formats (for [standalone individuals](https://sede.agenciatributaria.gob.es/Sede/ayuda/manuales-videos-folletos/manuales-practicos/guia-practica-cumplimentacion-modelo-censal-036/anexos/anexo-01-solicitud-nif-documentacion-aportar/informacion-sobre-numero-identificacion-fiscal/composicion-nif/personas-fisicas.html)). Here the [rules](https://factuo.es/herramientas/verificador-nif) for regex.
https://github.com/odoo/odoo/blob/f014e0b7bc3ce56a9931e81339a4f8327a400422/addons/l10n_es/models/res_partner.py#L39-L51 As a result, any standalone partner with a valid non-void VAT inherits is_company = True from the base computation.
https://github.com/odoo/odoo/blob/f014e0b7bc3ce56a9931e81339a4f8327a400422/odoo/addons/base/models/res_partner.py#L824-L833

### Reason to introduce the fix:
The Facturae 3.2.2 export directly derives PersonTypeCode (F/J) and the LegalEntity/Individual XML structure from partner.is_company. Since a self-employed individual (autónomo) is required to use their personal DNI/NIE as NIF and is their own commercial partner, the current logic misclassifies them as a legal entity (J), producing a Facturae invoice with an incorrect PersonTypeCode and structure. Explicitly setting is_company = False for DNI/NIE-formatted Spanish VAT numbers restores the ability to correctly represent individual entrepreneurs in Facturae exports.

opw-6396314

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

Forward-Port-Of: odoo/odoo#277228

Steps to reproduce the bug:
- Install a localization that overrides invoice_policy defaults for storable products without an explicit company_id (e.g. l10n_ke_edi_oscu_stock, which forces 'delivery' in that case)
- Run TestSaleMRPAngloSaxonValuation.test_sale_mrp_kit_bom_cogs (sale_mrp) or TestAngloSaxonValuation.test_anglo_saxon_cogs_partial_down_payment_credit_note (sale_stock)

Problem:
These tests create their products without setting invoice_policy explicitly, relying on the field's implicit default. l10n_ke_edi_oscu_stock's _compute_invoice_policy (https://github.com/odoo/enterprise/blob/4e459417dac809caafea34aa2e487fc3c1f0ce1a/l10n_ke_edi_oscu_stock/models/product.py#L16-L21) forces invoice_policy to 'delivery' for any storable product whose company_id is not set, which is the case for products created in these test fixtures.

Once invoice_policy becomes 'delivery', invoiced quantities are driven by qty_delivered instead of the ordered quantity, which the affected tests never account for (some deliver an arbitrary quantity instead of the exact BoM demand, others never validate a delivery at all), causing wrong COGS amounts or wrongly invoiced quantities as soon as such a localization is installed alongside these modules.

Solution:
Pin invoice_policy to 'order' explicitly wherever these test fixtures create their products, so the test outcome no longer depends on which other modules happen to be installed.

runbot-243633

Forward-Port-Of: odoo/odoo#279277
Forward-Port-Of: odoo/odoo#278346

Before this commit, marking several manufacturing orders as done at once crashed or could post labour costs on the wrong account, because the labour posting loop read the product and the company from the whole recordset instead of the manufacturing order being processed.

Steps to reproduce:
- activate a second company, e.g. My Company (Chicago)
- create a manufacturing order in each company and confirm them
- in the Manufacturing Orders list view, select both orders and mark them as done

A "ValueError: Expected singleton: res.company(...)" traceback is raised and none of the orders can be closed, even though each one can be marked as done individually. With same-company orders of different products, the production location resolved from the union of products, so the labour entry could be posted against another product's WIP account.

Use the manufacturing order of the current loop iteration to resolve the production location, as the rest of the loop already does.

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

Forward-Port-Of: odoo/odoo#276586

Steps:
- Install `account_peppol` module.
- Set `Peppol` compatible country and related details
- Go to my/account page.

Issue:
- Peppol related details always displayed on `my/account` page even though user select different invoice sending method like: `By Email`.

Casue:
- selector to manage visibility of Peppol related details in `my/account` is wrong and because of that those fields always display. Probably because https://github.com/odoo/odoo/pull/195764 and backport of this https://github.com/odoo/odoo/pull/198327 merged at same time.

Fix:
- Update selector to fix this

### [FIX] account_peppol: fix error when setting wrong endpoint

Steps:
- Install `account_peppol` module.
- Set `Peppol` compatible country and related details.
- Go to my/account page.
- Set some wrong Peppol value for `Peppol e-Address (EAS)` or `Peppol Endpoint` or `Electronic format`.

Issue:
- Not able to save those details without any error message on address page and getting error on console `Cannot read properties of undefined (reading 'classList')`.

Casue:
- In this PR https://github.com/odoo/odoo/pull/190312 when adapting portal page we set not existing fields in `invalid_fields` details and because of that it can't find related fields on address page and don't allow to save details without raising proper error message.

Fix:
- Updated `invalid_fields` values to properly target them

### [FIX] account_peppol: fix display issue for peppol related fields in address

Forward-Port-Of: odoo/odoo#281718

Steps to reproduce the bug:
- Enable 2-step delivery (pick + ship) on a warehouse.
- Set both rules on the delivery route to "Pull" (instead of the default Pull + Push):
    - Pick rule (Stock -> Output): action = Pull, procure_method = make_to_stock
    - Ship rule (Output -> Customers): action = Pull, procure_method = make_to_order
- Create a sale order for qty 1 and confirm it.
- Validate the Pick transfer.
- Return the Pick transfer.
- Cancel the sale order.
- Set it back to quotation and confirm it again.

Problem:
The newly created delivery (ship) move ends up asking for a wrong, inflated quantity instead of the ordered one (e.g. 3 times the ordered qty for the scenario above; the multiplier depends on the number of prior confirm/cancel/return cycles).

`_action_cancel` (addons/sale_stock/models/sale_order.py) only cancels pickings that are not `done`, so after the pick is validated and returned, cancelling the SO only cancels the still-pending ship move. The pick move and its return stay `done` and linked to the sale order line.

`SaleOrderLine._get_outgoing_incoming_moves` determines which rule "started" the pull/push chain by picking the rule of the first surviving (non-cancelled) move, grouped by warehouse: https://github.com/odoo/odoo/blob/d7bad3dc6c068ffe8643ecb01da1865d743bfb8f/addons/sale_stock/models/sale_order_line.py#L338-L347

Once the ship move is cancelled, it is excluded from that computation, so the Pick rule is wrongly identified as the "triggering" rule instead of the Ship rule. The done pick move and its return share that rule, so they both end up wrongly classified as incoming (returned) quantities instead of being excluded from the computation like before the cancellation, corrupting `_get_qty_procurement`. On reconfirm, `_action_launch_stock_rule` computes
`product_qty = product_uom_qty - qty`, inflating the quantity requested on the new ship move.

Solution:
Identify the triggering rule from the sale order line's full move history, including cancelled moves, so cancelling a move later doesn't change which rule is considered to have started the chain.

opw-6364113

Forward-Port-Of: odoo/odoo#280280

Steps to reproduce the bug:
- Create three storable products C1 ($10), C2 ($20), C3 ($5)
- Create a product P1 with a BoM: 1x C1 + 1x C2
- Create a Manufacturing Order for P1 and validate it
- Unlock the MO (Settings > Unlock)
- Add C3 as an extra component on the unlocked MO
- Open the MO overview

Problem:
The extra move had value=0 after creation, causing the unit_cost in the
MO overview to appear as 0. When a move is added to a done picking or MO
it is created with state='done' and quantity set immediately. This triggers
_set_quantity_done, which creates the move line and calls
_set_value(correction_quantity=delta). Inside _set_value, for outgoing
moves with a correction_quantity, the code computes:
  previous_qty = move.quantity - correction_quantity
Since the move had no prior quantity, previous_qty=0. The original code then
computed ratio=0 and applied move.value += 0, leaving value=0 instead of
computing it from scratch.

Solution:
When previous_qty=0, skip the ratio branch and fall through to the existing
from-scratch computation (standard_price * _get_valued_qty() for AVCO/standard
costing, _run_fifo() for FIFO).

opw-6377393

Forward-Port-Of: odoo/odoo#279962
Forward-Port-Of: odoo/odoo#276303

Before this commit, the html composer variant of "Opening thread with needaction messages should mark all messages of thread as read" failed at random on runbot:

    11. [verifySteps] expected the following steps
    > Expected: [
      "mark-all-messages-as-read",
    ]
    > Received: []

This happens because the channel of that variant holds no message, so the test goes to the inbox before the channel is loaded and it keeps scrollUnread set. Opening the channel again then loads its messages around the 0 separator, and that fetch calls set_message_done, which marks the needaction message as read and leaves nothing for mark_all_as_read to mark.

This commit fixes the issue by giving the channel two messages, pointing the separator at the first one and waiting for their display: loading messages around the separator is skipped when that message is already loaded, so opening the channel again fetches nothing, which the closing assertion checks as well.

The text composer variant gets the same fixture, so that both variants read as master does, from commit 8cd330e3e2d5b1d857d3effb80aa8176d60b38f9. It does not fail: it already waits for a message of its own, and a fetch around its non-zero separator leaves the messages alone in the mock.

https://runbot.odoo.com/odoo/error/945744

Forward-Port-Of: odoo/odoo#282038
Forward-Port-Of: odoo/odoo#281714

Before this commit, the test "Shows warning badge on mic/camera on non-granted permission in meeting conversations" failed on runbot, on 19.0:

Failed to find 1 of "button[title='Turn camera on']" (Timeout of 10 seconds). Found 0 instead.

This happens because the mock server numbers a new record with the highest id of the model plus one, so a record created right after the last one is deleted takes its id back. Joining another call leaves the meeting call first, and the session of the new call carries the id of the one just left. Leaving broadcasts
"discuss.channel.rtc.session/ended" for that id, and under load it lands after the join: the client reads it as its own session being closed and ends the call it has just joined.

This commit numbers the records of a model with a counter, started above the ids its definition gives, as a database sequence does, so a notification about a deleted record can no longer name a live one.

https://runbot.odoo.com/odoo/error/945965

Forward-Port-Of: odoo/odoo#282244

- Compute the standard durations for all French leaves in a single
  `_get_durations()` call instead of recomputing them for each leave.

- Reuse the precomputed duration mapping while calculating the French
  legal duration for each leave.

- Keep the existing French-specific duration calculation unchanged,
  including public holidays, company calendar, date extension, and
  half-day handling.

This avoids repeated ORM computations when processing multiple French
leaves in a batch and significantly improves the performance of leave
duration computation.

Performance testing was performed using the `hr.leave.employee.report`
introduced in 19.1, which calls `_get_durations()` on a large batch of
virtual leaves.

Performance testing on a database containing 677 leaves, including
298 French leaves:

| Metric                              | Before          | After       |
|------------------------------------|-----------------|-------------|
| Standard duration computations    | 298             | 1           |
| Total `_get_durations()`          | >169s (timeout) | ~24s        |

not specific to the employee report and benefits
any caller that invokes _get_durations() on a larger batch.

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

Forward-Port-Of: odoo/odoo#281914
Forward-Port-Of: odoo/odoo#281165