Version
- 18.0

Steps to Reproduce:
Issue 1: Incorrect tooltip text
  1. Go to Products → Products in subscription app.
  2. Open a product page and select goods product type
  3. observe product_tooltip show incorrect wording:
       * "Based on order" showed end of the period.
       * "Based on delivered" showed beginning of the period.

Issue 2: Product card shows both recurring and sales price
  1. Go to Products → Products in subscription app.
  2. Observe that the product card displays both recurring price and sales price

After this PR:
- Tooltip now correctly states:
   * for "based on order" invoice_policy -> beginning of period
   * for "based on delivery" invoice_policy -> end of period
- Product cards show only the recurring price when applicable.

task-5156390
<img width="1002" height="436" alt="image" src="https://github.com/user-attachments/assets/39f00555-e37a-44a5-8786-d7f8d6882de7" />
<img width="968" height="262" alt="image" src="https://github.com/user-attachments/assets/0d6d5c2d-d5ab-4376-bc03-dba243abce8b" />

Forward-Port-Of: odoo/enterprise#101914
Forward-Port-Of: odoo/enterprise#95010

**PROBLEM**
With a Mexican company, when trying to send a CFDI with a global discount, it can happen that after the repartition of the discount we have lines with a negative amount, so we can't send the CFDI. 

**STEP TO REPRODUCE**
1. Take a mexican company
2. create a quotation with, product A = 1$, product B = 100$, global discount of 15%
3. create an invoice using this quotation, confirm it and try sending the CDFI.
4. the following error will appear : "Error when sending the CFDI to the PAC: Failed to distribute some negative lines" 

**CAUSE**
In account, the function `_normalize_target_factor()` takes a list of dictionnary `target_factors`, with the keys being invoice lines (the targets) and the keys being weights (the factors). It is used to normalize the weight associated with the lines, to later use them to dispatch things like discounts to those lines. This function also does a sort on the weight, and return a list containing pairs of index and weights. This is useful only in the function `_distribute_delta_amount_smoothly()`, other functions doesn't work well with the sorted returned list: they don't use the index, and dispatch discounts to the wrong lines.

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