when the ``get_description`` is calling. So, it getting all the information weather it's groupable or not for it [here](https://github.com/odoo/odoo/blob/b48d41086d7ff8ef91c6c43d37d588686d6b921a/odoo/orm/fields.py#L923) and field is from inherited model it trying ``model._read_group_groupby(model._table, groupby, query)`` because those related and non store. As there is no meaning for computation for that because it going groupable because it parent_field is groupable. So, keeping check for that and reduce the computation.

```
   File "/tmp/tmpmagm1mli/migrations/base/tests/test_mock_crawl.py", line 430, in mock_act_window
    views = get_views(
   File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_thread.py", line 463, in get_views
    res = super().get_views(views, options)
   File "/home/odoo/src/enterprise/19.0/web_studio/models/models.py", line 10, in get_views
    result = super().get_views(views, options=options)
   File "/home/odoo/src/enterprise/19.0/web_studio/models/ir_ui_view.py", line 52, in get_views
    return super().get_views(views, options)
   File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_ui_view.py", line 2935, in get_views
    result['models'][model] = {"fields": self.env[model].fields_get(
   File "/home/odoo/src/odoo/19.0/addons/stock/models/product.py", line 521, in fields_get
    res = super().fields_get(allfields, attributes)
   File "/home/odoo/src/enterprise/19.0/web_studio/models/ir_model.py", line 76, in fields_get
    return super().fields_get(allfields, attributes=attributes)
   File "/home/odoo/src/enterprise/19.0/ai_fields/models/models.py", line 47, in fields_get
    res = super().fields_get(allfields, attributes)
   File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3360, in fields_get
    description = field.get_description(self.env, attributes=attributes)
   File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 883, in get_description
    value = value(env)
   File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 930, in _description_groupable
    model._read_group_groupby(model._table, groupby, query)
   File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_activity_mixin.py", line 259, in _read_group_groupby
    return super()._read_group_groupby(alias, groupby_spec, query)
   File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 2064, in _read_group_groupby
    coquery = comodel._search(codomain, bypass_access=field.bypass_search_access)
   File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_attachment.py", line 659, in _search
    records = self.sudo().with_context(active_test=False).search_fetch(
   File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 1418, in search_fetch
    return self._fetch_query(query, fields_to_fetch)
   File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3914, in _fetch_query
    rows = self.env.execute_query(query.select(*sql_terms))
   File "/home/odoo/src/odoo/19.0/odoo/orm/environments.py", line 534, in execute_query
    self.cr.execute(query)
   File "/home/odoo/src/odoo/19.0/odoo/tests/test_cursor.py", line 79, in execute
    return self._cursor.execute(*args, **kwargs)
   File "/home/odoo/src/odoo/19.0/odoo/sql_db.py", line 426, in execute
    self._obj.execute(query, params)
 psycopg2.DatabaseError: out of memory for query result
```

opw-5260147
upg-3444635

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

Forward-Port-Of: odoo/odoo#239991
Forward-Port-Of: odoo/odoo#239400

Currently, an error occurs when a user attempts to load demo data for a newly created company in the Appraisal module.

**Steps to Reproduce:**
1. Install `hr_appraisal` without demo data.
2. Create a new company and switch to it.
3. Appraisals > Click "Load sample data".

**Traceback:**
```
AccessError
Uh-oh! Looks like you have stumbled upon some top-secret records.

Sorry, Sengsourigna Phonkaseumsouk (id=2) doesn't have 'read' access to:
- Employee, Emma Granger (hr.employee: 3, company=TPX Solutions)

Blame the following rules:
- Employee multi-company rule

If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies.

This seems to be a multi-company issue; you might be able to access the record by switching to the company: TPX Solutions.

ParseError
while parsing /home/odoo/src/enterprise/18.0/hr_appraisal_skills/demo/scenarios/scenario_appraisal_demo.xml:4, somewhere inside <function model="hr.appraisal" name="_copy_skills_when_confirmed" eval="[ref('hr_appraisal.hr_appraisal_2')]"/>

ValueError
ParseError('while parsing /home/odoo/src/enterprise/18.0/hr_appraisal_skills/demo/scenarios/scenario_appraisal_demo.xml:4, somewhere inside\n<function model="hr.appraisal" name="_copy_skills_when_confirmed" eval="[ref(\'hr_appraisal.hr_appraisal_2\')]"/>') while evaluating 'action = model._load_demo_data()'
```
**Cause:**
The demo data loading process attempts to access employee records without the required permissions. Since the user belongs to a different company, the multi-company security rules prevent reading those employees.

**Fix:**
This commit removes the company assignment from the demo employee records so they are created in the current company instead of the base company.

sentry-7032880299

Forward-Port-Of: odoo/odoo#239415

```
  File "/home/odoo/src/odoo/19.0/addons/account/models/ir_module.py", line 100, in _register_hook
    self.env.registry._delayed_account_translator(self.env)
  File "/home/odoo/src/odoo/19.0/addons/account/models/ir_module.py", line 90, in load_account_translations
    env['account.chart.template']._load_translations(langs=langs)
  File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 1449, in _load_translations
    ._get_chart_template_data(chart_template)
  File "/home/odoo/src/enterprise/19.0/account_accountant/models/account_chart_template.py", line 31, in _get_chart_template_data
    data = super()._get_chart_template_data(chart_template)
  File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 803, in _get_chart_template_data
    data = func(self, template_code)
  File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 59, in wrapper
    return func(*args, **kwargs)
  File "/home/odoo/src/enterprise/19.0/l10n_be_reports/models/account_chart_template.py", line 52, in _get_be_account_reconcile_model
    prepayment_communication = self.env['qr.code.payment.wizard']._be_company_vat_communication(self.env.company).replace('+++', '')
  File "/home/odoo/src/enterprise/19.0/l10n_be_reports/models/qr_code_payment_wizard.py", line 14, in _be_company_vat_communication
    number = int(vat)
ValueError: invalid literal for int() with base 10: 'LU19038918'
```
```sql
kmod_3311837=> select id,name,chart_template,parent_id from res_company;
 id |        name         | chart_template | parent_id
----+---------------------+----------------+-----------
  3 | C.R.O.Qu.E.T. S.A.  | be_comp        |
  2 | KG5380              | be_comp        |
  1 | KNOWLEDGE GATE S.A. | lu             |
(3 rows)

kmod_3311837=> select id,model,module,res_id from ir_model_data where name = 'main_company';
 id |    model    | module | res_id
----+-------------+--------+--------
  2 | res.company | base   |      1
(1 row)
```
```
> /home/odoo/src/enterprise/19.0/l10n_be_reports/models/account_chart_template.py(52)_get_be_account_reconcile_model()
-> if template_code in ['be', 'be_comp', 'be_asso']:
(Pdb) template_code
'be_comp'
(Pdb) self.env.company
res.company(1,)
(Pdb) self.env.company.chart_template
'lu'
(Pdb)
```

- The traceback occurs because during the translation loading process, the system calls [_get_chart_template_data](https://github.com/odoo/odoo/blob/38cffd1d1580693c56f0d897b8c8e60b938a8e85/addons/account/models/chart_template.py#L1465) for all available template codes. In the customer’s database, there are three companies: Company 2 and Company 3 use the BE_COMP localization, while Company 1 uses the LU localization.
- When _get_chart_template_data is executed for the BE_COMP chart template, it eventually calls [_get_be_account_reconcile_mode](https://github.com/odoo/enterprise/blob/d13dc2d7b54d7e43f3b27b19131d0a277d0498b8/l10n_be_reports/models/account_chart_template.py#L49) During this call, the function receives the correct template code (be_comp) as an argument. However, self.env.company returns Company 1, because Company 1 is set as the main_company.
- As a result, [_be_company_vat_communication](https://github.com/odoo/enterprise/blob/d13dc2d7b54d7e43f3b27b19131d0a277d0498b8/l10n_be_reports/models/qr_code_payment_wizard.py#L14) is called with Company 1, even though this company uses the LU localization. Since LU localization does not support the BE VAT communication logic, an error is raised from this method.
- There is no context of the company passed when calling _get_chart_template_data from _load_translations, so I have applied with_company, so _get_chart_template_data is called in the context of a specific company.
opw-5342498
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#239887
Forward-Port-Of: odoo/odoo#239809

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

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