In some case, a database can be in a state where some auto install module are not installed
- when the user uninstall a module
- when module was added in stable and a database was created before the addition.

It can lead to issues where an upgrade fails or some business logic does not work as expected because of the missing modules.

This is not easy to reproduce and to test, even if uninstalling such module should in theory work and be tested.

This pr proposes to add a flag "--skip-auto-install" to the config to be able to disable all auto install of modules.

It is open to discussion to change this to a config option, with or without a module list

**Initial solution (alternative to avoid a config)**
--dev skipautoinstall

**Current solutions**
(command line param)
--skip-auto-install

**Maybe in the future but unlikely**
(more flexible)
--skip-auto-install=all
--skip-auto-install=web_enterprise,iap

(krma suggestions)
--skip-auto-install=*
--skip-auto-install=web_*,iap

Those two last one could be more flexible but the use case are limited and can be done another way with an explicit -i, maybe no worth the additional complexity (mainly since we need to filter in two different places)

Note that this pr uses **get** on the config just in case the config is monkey patched somewhere to make it more robust.

Forward-Port-Of: odoo/odoo#239044
Forward-Port-Of: odoo/odoo#234710

Currently, an error occurs when user opens the `account.duplicate.transaction.wizard.form` view and saves it.

**Steps to Reproduce:**

 - Install the `account_accountant` module.
 - Using `Open View`, open the `account.duplicate.transaction.wizard` view > enter the start date, and save..

`ValueError: Compute method failed to assign account.duplicate.transaction.wizard(22,).provider_duplicate_ids`

The error occurs because when the view is opened and saved, the _compute_provider_duplicate_ids method is triggered. Since no journal is linked to the wizard, the method assigns an empty list ([]) to provider_duplicate_ids [1]. Because this is a O2M field, assigning a raw empty list is invalid and causes the error.

This commit ensures that when journal is missing, instead of assigning an empty list ([]), a valid relational command `([Command.set([])])` is used.

Ref: https://github.com/odoo/enterprise/pull/97196/commits/c109e0bcce20f14b6dbd3d28e61b135f1fd048f2

[1] https://github.com/odoo/enterprise/blob/d808ad3f6ff52632e00cf1a68de0e5270e52895d/account_online_synchronization/wizard/account_journal_duplicate_transactions.py#L53

sentry-7080686084

Forward-Port-Of: odoo/enterprise#101177

Steps to reproduce:
===================
1- Go to the Website editor.
2- Go to mobile view
3- Zoom in (e.g., set it to 120%).
4- Click on any snippet inside the website iframe. 
-> The highlight overlay is in the wrong position.

When the website builder iframe is zoomed (scaled), the overlay elements (blue selection borders) become misaligned and incorrectly sized.

Cause:
======
This occurs because `targetRect` returns coordinates in the iframe's internal coordinate system (unscaled), while `iframeRect` is in the window's coordinate system (scaled).
So when we try to draw the Overlay (in Main Window) using targetRect (from Iframe), we must scale the `targetRect` values to match the Main Window's reality.

See [1] for more informations on how `getBoundingClientRect` works

Solution
=========
Scale targetRect to match the main windows's reality.

[1]: https://developer.mozilla.org/en-US/docs/Web/API/Element/getBoundingClientRect 
opw-5345154

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

Step to reproduce:
- start pos and finalize a order with product A
- go backend
- Archive product A
- start the pos again
- try to refund the order

Observation:
- Blank page with traceback in console

```
Caused by: TypeError: Cannot read properties of undefined (reading 'filter')
at __exports.getOrderChanges
at Proxy.getOrderChanges
```


Cause:
- until now `product.template` model is looked for filter after a reload
https://github.com/odoo/odoo/blob/1b2500422209ed5feb6d49716f94d58c931bf541/addons/point_of_sale/static/src/app/models/data_service_options.js#L91-L93
https://github.com/odoo/odoo/blob/1b2500422209ed5feb6d49716f94d58c931bf541/addons/point_of_sale/static/src/app/services/data_service.js#L290-L295
 and not `product.product`, this makes `product_id` available but 
`product_tmpl_id` undefined, causing inconsistency

Fix:
- we add `product.product` in `cleanupModels` for data to in sync with backend 

opw-5237961

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

In some case, a database can be in a state where some auto install module are not installed
- when the user uninstall a module
- when module was added in stable and a database was created before the addition.

It can lead to issues where an upgrade fails or some business logic does not work as expected because of the missing modules.

This is not easy to reproduce and to test, even if uninstalling such module should in theory work and be tested.

This pr proposes to add a flag "--skip-auto-install" to the config to be able to disable all auto install of modules.

It is open to discussion to change this to a config option, with or without a module list

**Initial solution (alternative to avoid a config)**
--dev skipautoinstall

**Current solutions**
(command line param)
--skip-auto-install

**Maybe in the future but unlikely**
(more flexible)
--skip-auto-install=all
--skip-auto-install=web_enterprise,iap

(krma suggestions)
--skip-auto-install=*
--skip-auto-install=web_*,iap

Those two last one could be more flexible but the use case are limited and can be done another way with an explicit -i, maybe no worth the additional complexity (mainly since we need to filter in two different places)

Note that this pr uses **get** on the config just in case the config is monkey patched somewhere to make it more robust.

Forward-Port-Of: odoo/odoo#239044
Forward-Port-Of: odoo/odoo#234710

There are two issues:

1) When making a purchase matching, and adding a vendor bill to a PO, when searching for the corresponding purchase order, it will not find it if the purchase order is an user with a company
2) When making a bill matching, the vendors bill will not appear.

Steps to reproduce:
-------------------
* Create a company A
* Create a partner A of type individual as a sub-partner to the company A
* Create a purchase order with partner A and confirm it
* Create a vendor bill corresponding to the purchase order

1)
* Click on the purchase matching smart button the vendor bill and try to add to PO
* Search for the purchase order
-> Issue, the purchase order does not appear.

2)
* Go on the purchase order
* Click on Bill matching smart button
-> Issue the vendor bills will not appear

Observation:
-----------
The issue is that purchase Orders store the partner exactly as selected (individual contact), while Vendor Bills are normalized internally to the parent company ("commercial_partner_id'). This creates a mismatch when making the search.
https://github.com/odoo/odoo/blob/9e9e992698946b75212040ca0ff812194200a8bf/addons/account/models/account_move_line.py#L480-L483

1) The domain of the search is
https://github.com/odoo/odoo/blob/58b888992f80a58fecdb92e23fea0050f2178faf/addons/purchase/wizard/bill_to_po_wizard_views.xml#L10-L11
The domain on the search does not take into consideration the missmatch between Vendor Bill and PO.

2) When calling action_bill_matching, the domain is:
https://github.com/odoo/odoo/blob/73590e017e9f2861b0852952e14261e57eb67f70/addons/purchase/models/purchase_order.py#L609-L621
This is a similar issue as 1) and https://github.com/odoo/odoo/commit/c0e86ba6d31708fb16765ba0e0596adc2f29dcd8

Why the fix:
------------
Commercial_partner_id is always set, adding it in the search will allow to normalize the search on the parent_company if there is one.
https://github.com/odoo/odoo/blob/18.0/odoo/addons/base/models/res_partner.py#L450-L455
opw-5067995

Forward-Port-Of: odoo/odoo#236913

Issue
=====
When scanning a package as result package, if the package is empty, it works, but if this package already has content, it doesn't work.

How to reproduce
================
1. Enable "Packages" and "Storage Locations" settings;
2. Create two packages with some content in WH/Stock/Shelf 1;
3. Create an empty package;
4. Create an internal transfer directly from the Barcode app;
5. Scan Shelf 1 barcode and scan first package;
6. Scan the empty package => It's assigned as the result package;
7. Confirm the operation;
8. Create another internal transfer;
9. Scan Shelf 1 barcode and scan second package;
10. Scan the no more empty package => This time, it's not assigned as the result package.

Reason
======
A package was assigned as the result package only if one of the following conditions is matched:
1. The scanned package is empty (it's what's happening in 6.);
2. The selected line has no result package yet and the scanned package is in the selected line's destination location.

Here, it doesn't work because since we move a package, the barcode line has already a destination package (the same then the source package.)

Fix
===
For the condition 2., adapt the condition to make it works too if the selected line has the same package as the source and result package.

[opw-5326234](https://www.odoo.com/odoo/project/49/tasks/5326234)

Forward-Port-Of: odoo/enterprise#101959
Forward-Port-Of: odoo/enterprise#101357

How to Reproduce : 
1. Remove 'Create' access on the 'Knowledge Article' model for Portal and 
   Internal users.
2. Now log in as a Portal.
3. Try to create a new private article.
4. Log in as an Internal user.
5. Try to create a new private article.

Both Internal and Portal users can still create private articles even after
'Create access' is removed.

Article creation logic in `knowledge.article` was bypassing the usual access
rights because of `sudo` (mainly to add the creator as a member, since creation
rights on the member model are not granted). This allowed users to create
private articles even without create access.

This commit introduces:
1. Model-level access check in `create`. Sudo the creation of articles only when
   the user has create rights.

2. UI imp to hide the '+' button in the sidebar and the `New` button in
   the topbar when the user doesn't have create access.

3. New test cases to verify that model-level access rights are respected when creating an article.

task-4916280

Forward-Port-Of: odoo/enterprise#100776
Forward-Port-Of: odoo/enterprise#93034

Currently, an error occurs when user opens the `account.duplicate.transaction.wizard.form` view and saves it.

**Steps to Reproduce:**

 - Install the `account_accountant` module.
 - Using `Open View`, open the `account.duplicate.transaction.wizard` view > enter the start date, and save..

`ValueError: Compute method failed to assign account.duplicate.transaction.wizard(22,).provider_duplicate_ids`

The error occurs because when the view is opened and saved, the _compute_provider_duplicate_ids method is triggered. Since no journal is linked to the wizard, the method assigns an empty list ([]) to provider_duplicate_ids [1]. Because this is a O2M field, assigning a raw empty list is invalid and causes the error.

This commit ensures that when journal is missing, instead of assigning an empty list ([]), a valid relational command `([Command.set([])])` is used.

Ref: https://github.com/odoo/enterprise/pull/97196/commits/c109e0bcce20f14b6dbd3d28e61b135f1fd048f2

[1] https://github.com/odoo/enterprise/blob/d808ad3f6ff52632e00cf1a68de0e5270e52895d/account_online_synchronization/wizard/account_journal_duplicate_transactions.py#L53

sentry-7080686084

Forward-Port-Of: odoo/enterprise#101177

### Issue:

In this issue, when a quotation template is used in sale order, the end line is missing between name and description in the invoice pdf.

#### Steps to reproduce:
1- Install a db with sale and invoicing installed
2- Create a quotation template, and add a description in the line.
3- Create a quotation with the created template.
4- Confirm the order and create an invoice for the sale order.
5- Print the pdf, as seen the name and description are shown in the same line, while if the sale order was created without a template, we would have seen the description from product in the next line.

`_get_journal_items_full_name` is used to enforce the product name in the description. However, in cases where product name doesn't exist in the description, e.g. our case here, the name and description will be shown in the same line in the invoice pdf. This can be fixed by adding a new line between the name and the description.

opw-5130171

Forward-Port-Of: odoo/enterprise#100417

On a fsm task, using the smart button to go to the invoice, will not give the same domain for the products, if you go from the sale order or directly from the task

Steps to reproduce:
-------------------
* Create a product
	- Purchase: False
	- Sale    : True
* Create a fsm task
* Add products
* Go to the sale order
* Create the invoice (regular invoice)
* Go back to the task
* Go to the invoice using the invoices smart button
* Try to add your product
-> issue it's not possible.

Observation:
---------------
The domain of the search is not the same if we go from the sale order or from the task.

This is because the domain depend on the context and the context is not the same :
[Domain](https://github.com/odoo/odoo/blob/8258ddf12ed6c0495628f7a480d1e2424e756540/addons/account/views/account_move_views.xml#L1134-L1141)

When using the smart button on the SO, some elements will be added to the context, the important one is: default_move_type : "out_invoice":
[SO context](https://github.com/odoo/odoo/blob/18.0/addons/sale/models/sale_order.py#L1453)

Instead when using it on the task, the context does not have that element:

https://github.com/odoo/enterprise/blob/cb79d565031ee0e1bec9db82aa35deb2e1c03576/industry_fsm_sale/models/project_task.py#L325-L327

This will be calculate here in the js files:

[evalContext](https://github.com/odoo/odoo/blob/c3367bd7c6900e42394b006ccf48c3b36a1b87e9/addons/web/static/src/views/fields/field.js#L400)

opw-5135567

Forward-Port-Of: odoo/enterprise#101606
Forward-Port-Of: odoo/enterprise#98612

Currently, an error occurs when user opens the `account.duplicate.transaction.wizard.form` view and saves it.

**Steps to Reproduce:**

 - Install the `account_accountant` module.
 - Using `Open View`, open the `account.duplicate.transaction.wizard` view > enter the start date, and save..

`ValueError: Compute method failed to assign account.duplicate.transaction.wizard(22,).provider_duplicate_ids`

The error occurs because when the view is opened and saved, the _compute_provider_duplicate_ids method is triggered. Since no journal is linked to the wizard, the method assigns an empty list ([]) to provider_duplicate_ids [1]. Because this is a O2M field, assigning a raw empty list is invalid and causes the error.

This commit ensures that when journal is missing, instead of assigning an empty list ([]), a valid relational command `([Command.set([])])` is used.

Ref: https://github.com/odoo/enterprise/pull/97196/commits/c109e0bcce20f14b6dbd3d28e61b135f1fd048f2

[1] https://github.com/odoo/enterprise/blob/d808ad3f6ff52632e00cf1a68de0e5270e52895d/account_online_synchronization/wizard/account_journal_duplicate_transactions.py#L53

sentry-7080686084

Forward-Port-Of: odoo/enterprise#101177

Purpose: In the Guatemalan localization, when an electronic invoice is created, the email template to the customer already contains the PDF version of the DTE. However, the XML file, generated and sent to the SAT through Infile, is not attached to that email. Even though the SAT and Infile deliver the XML to the customer, it is more convenient and transparent if Odoo includes it directly in the outgoing invoice template email, so the customer receives both files in one place.

Before this commit:-
- Only PDF version is attached by default in customer email for e-invoices.
- Name of edi document is prefixed with `Demo` if company is in demo environment (check parent company's environment in case of child company) (e.g. DEMO_certificate_INV_2025_00001.xml) and prefixed with `SAT` if company is in testing or production environment(e.g. SAT_certificate_INV_2025_00001.xml).

After this commit:-
- XML version is also attached by default along with PDF in customer email for e-invoices.
- Name of edi document is always prefixed with `SAT`.

task-5224521

Steps to reproduce the flow:
- Create an expensable product “Hotel” that can be reinvoiced to a customer
- Create an analytic distribution model that automatically applies the analytic account “Commercial &Marketing” to the previous created product “Hotel”
- Create an SO for a customer “Gilles”. The SO is linked to the analytic account “Home Construction”
- Create an expense which category is “Hotel”. The analytic distribution is automatically set to “Commercial & Marketing”
- Reinvoice this expense to “Gilles”. The analytic distribution automatically changes to “Home Construction”. -> Wrong. We lose part of the information
- When posting the expense report, the expense is added in the SO through a dedicated SO line. The analytic account previously set as “Home Construction” is now transformed, for an unknown reason, into “Commercial & Marketing”. -> Wrong.
- On the vendor bill, the analytic distribution is “Home Construction”

Now:
1. The analytic plans from the expense and from the SO are different. Simply add the analytic account from the SO
2. The analytic plans are the same. There are conflicts. In this case, the analytic distribution set on the SO is prioritary. We ensure that costs incurred or sales generated from the expense are reflected in the SO's analytic plan rather than the generic one. In the previous example, Home Construction is the only analytic account that should be considered on the expense, bill and SO.

task-4564463

**Steps to reproduce**
On a local DB, with demo data:
- Change your machine's time to a late part of the day (e.g. 6pm)
- Install `mrp_workorder`
- Set the "Standard 40 hours/week" (used by a workcenter) as flexible.
- From the Shop Floor, start the "WH/MO/00003 - Manual Assembly"
workorder.

"Validation Error: The start date of the time off must be earlier than
the end date."

**Cause**
`_calculate_date_finished` in mrp is calling `plan_hours` and under
certain conditions with a flexible resource, it is possible for
`plan_hours` to return a datetime before the `day_dt` parameter.
This happens because for flexible resources,
`_attendance_intervals_batch` can return attendance intervals with
start or end datetimes outside of the start_dt -> end_dt window.
For example, a flexible calendar with 8h/day will return the
8:00->16:00 interval, even if start_dt is later than 8:00.

**Change**
Don't return attendance intervals outside of the [start_dt, end_dt]
interval by shifting them if necessary.

opw-5123230

**Issue:**
```python
 File "/data/build/enterprise/l10n_cl_edi/models/account_move.py", line 744, in _l10n_cl_edi_post_validation
    raise UserError(
odoo.exceptions.UserError: The stamp date and time cannot be prior to the invoice issue date and time. TIP: check in your user preferences if the timezone is "America/Santiago"
```

**Cause:**
Posting an invoice at early local hours (e.g., 2025-12-11 04:00) is converted by the [Chilean timezone (America/Santiago)](https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/l10n_cl_edi/models/l10n_cl_edi_util.py#L117-L120) to the previous day (e.g., 2025-12-10 19:30).

**Solution:**
- Freeze the test time at a stable CL-safe hour
- Add a fixed `invoice_date` aligned with the frozen timestamp

Reference : [timezone converter](https://dateful.com/time-zone-converter?t=730pm&d=2025-12-10&tz2=Santiago-Chile)
Runbot error: [234755](https://runbot.odoo.com/odoo/runbot.build.error/234755)
Related PR: https://github.com/odoo/enterprise/pull/99518

Forward-Port-Of: odoo/enterprise#101901

Accrual plan for leave days gets blocked, even when the remaining leave balance is below the cap. As a result, no additional leaves are accrued beyond a certain point, even though they should be.

# Steps to reproduce:
Go to time off app
* Create a new leave type.
* Create a new accrual plan with:
        - one milestone :
		- 2 days accrued per month
		- Cap: 10 days
		- start accruing 1 days after
		- No expiration
		- Carry over: All
* Create and validate a leave allocation 
       - 1 year ago
       - new leave type
       - new accrual plan
* Take the maximum number of leaves available.
* Advance the computer calendar by 1 year.
* Again, take the maximum number of leaves.
* Advance the computer calendar by another year.
* Try to take a future leave.
-> Issue: It’s not possible to take a future leave, the number of accrued days has stopped increasing. The accrual plan appears blocked.

Objective : The accrual plan should continue to allocate leave days even if leaves have been consumed regularly, as long as the remaining leaves are under the cap.

## Issue
Before going further: the property `leaves_taken` of the `hr.leave.allocation` is supposed to contain the number of leaves this allocation cover until "today".

In the `_test_get_allocation_future_leaves1` added test, in the last line of the test :
`assert_virtual_leaves_equal(self, leave_type_day, 2, self.employee_emp, date='2023-02-01')`

When calling `get_allocation_data` with a `target_date` set in the future, the result is wrong. Here is how it works :
`get_allocation_data`
...
.....`_get_consumed_leaves` (1)
...........`_get_future_leaves_on` (2)
...............`_process_accrual_plans` (3)
....................`_compute_leaves` (4)
.........................`_get_consumed_leaves` (5)
..............................`get_future_leaves_on` (6)
...................................`process_accrual_plans` (7)

**A)** The method **(2)** try to calculate the added number of days each allocation will have on `target_date`. So it creates a copy of the allocation in memory using the 'new' method:
`fake_allocation = self.env['hr.leave.allocation'].with_context(default_date_from=accrual_date).new(origin=self)`
It will then update it to `target_date` using `_process_accrual_plans` and will return the difference of days between the
updated `fake_allocation` and the current allocation (`self`)

**B)** Before iterating over each accrual date, the `_process_accrual_plans` **(3)** will get the `leaves_taken` property which is a computed field. It will trigger `_compute_leaves`.

**C)** The method **(4)** will call `_get_consumed_leaves`, and so the nightmare begins.

**D)** The method **(6)** will create a second `fake_allocation` based on the origin of the first `fake_allocation` (see **A)**).

**E)** This time, `_process_accrual_plans` **(7)** will also look at the `leaves_taken`, but won't trigger the `_compute_leaves` probably because the current allocation is a `fake_allocation` of a `fake_allocation`, and one property of the `new` method is that `Two new records with the same origin record are considered equal.`. Therefore, the `leaves_taken` is considered to be already computed (but it's not).

So `_process_accrual_plans` read the `leaves_taken` which is 0 (probably the default value of `leaves_taken`), but it should be 20 !

**F)** As the value of `leaves_taken` is wrong, the fake_allocation n°2 is also wrong, and its `number_of_day` is 10 but the `number_of_days` of the origin allocation is 20. So `get_future_leaves_on` **(6)** will return -10 which makes no sense, and all the previous calls computations will be wrong. And the final `virtual_remaining_leaves` value will be 0 instead of 2.

## Source of the issue
In the `_process_accrual_plans` method, for each allocation, `leaves_taken` is only computed once at the start of the loop over the allocation "important" dates (see `nextcall` property of `hr.leave.allocation`). At this moment, the method calculates the `leaves_taken` the allocation will have on the `accrual_date` parameter. Yet, this property can change depending on the date the allocation is on (`nextcall` property) which leads to some issues in the computation of the `allocation.number_of_days`.

## Solution
For each allocation, compute the `leaves_taken` at every iteration trough the values of `nextcall`. BUT, this can trigger an infinite loop as computing `leaves_taken` calls `_get_consumed_leaves` which calls `_get_future_leaves_on`, which calls `_process_accrual_plans` ... To avoid this, this PR add the context variable `precomputed_allocations` (will be converted into a function parameter in master) which will prevent `_get_consumed_leaves` from calling `_get_future_leaves_on` for the allocations already up to date (contained by this very `precomputed_allocations` context variable).

**For r+: Needs a few changes at 18.0 (hours per day of employee is retrieved differently for example)**

opw-4934391
opw-5226806

## Short functional explanation of the error
Let's say we have created a public holiday on a
Saturday, which is out of an employee's schedule
as they work from monday to friday. When trying
to create a payslip for this employee for the
month the public holiday occurs, it will show
an error.

## Reproduction Steps
1. Create a public holiday on a Saturday. Set the Working Hours to a schedule not including
Saturdays. Set the Work Entry Type as Generic
Time Off.
2. Click on the Configuration tab > Time Off Types.
3. Create a Time Off type. Set the Requires Allocation field at No Limit, and the Work
Entry Type field at Generic Time Off.
4. Click on the Management tab, then Time Off.
5. Click on New. Make sure to select an employee who has the same working schedule as the one you
set for the public holiday, and that on their
contract, their Work Entry Source is set to
Working Schedule. Set the Time Off Type field
to the one you just created.
6. Save and click Approve.
7. Go to Payroll. In Contracts, make sure that the employee's contract is running, and that their contract type is Full-Time.
8. Click on the Payslips tab > to pay.
9. Click on New and select the employee for which you just created a time off.

### Expected behavior
The payslip is created.

### Unexpected behavior
An Odoo Error Occurs.

## Origin of the issue
In the code, we don't verify that the holiday
is present in the employee schedule before
computing the name of the payslip:

https://github.com/odoo/enterprise/blob/a7e954dbe4a68b1770341e754101319a89e4de9e/hr_payroll/models/hr_payslip_worked_days.py#L87-L92

We simply check if one holiday exists, which is
the case as a public holiday is applied to
every employee. Therefore, we need one more
check.

__
opw-5269302