Problem:
When running the MPS report on a large number of production schedules, if the associated number of stock moves is high, the _get_moves_and_date method can cause a memory error.

Solution:
We will fetch only the necessary fields to reduce queries and memory usage and set prefetch_fields=False to further reduce memory usage.

Benchmarks:
Run locally on a dupe of customer's db.
Time/queries measured by requests to /get_mps_view_state Memory measured using memray on method get_production_schedule_view_state()

<table>
   <tr>
      <th rowspan="2"># of Production Schedules</th>
      <th colspan="3">Before</th>
	   <th colspan="3">After</th>
   </tr>
   <tr>
      <th>Time</th>
      <th># of Queries</th>
	   <th>Memory usage</th>
      <th>Time</th>
      <th># of Queries</th>
	   <th>Memory usage</th>
   </tr>
   <tr>
      <td>20</td>
      <td>22.846s</td>
      <td>1,379</td>
      <td>882.0MB</td>
      <td>8.046s</td>
      <td>1,180</td>
      <td>103.4MB</td>
   </tr>
   <tr>
      <td>300</td>
      <td>41.098s</td>
      <td>6,297</td>
      <td>1.0GB</td>
      <td>43.694s</td>
      <td>5,732</td>
      <td>363.5MB</td>
   </tr>
	<tr>
      <td>1000</td>
      <td>N/A (MemoryError)</td>
      <td>N/A (MemoryError)</td>
      <td>>2GB</td>
      <td>88.416s</td>
      <td>22,629</td>
      <td>1.1GB</td>
   </tr>
</table>
Average memory usage reduction: 75%


opw-5225472

Forward-Port-Of: odoo/enterprise#106392

Problem:
When running the MPS report on a large number of production schedules, if the associated number of stock moves is high, the _get_moves_and_date method can cause a memory error.

Solution:
We will fetch only the necessary fields to reduce queries and memory usage and set prefetch_fields=False to further reduce memory usage.

Benchmarks:
Run locally on a dupe of customer's db.
Time/queries measured by requests to /get_mps_view_state Memory measured using memray on method get_production_schedule_view_state()

<table>
   <tr>
      <th rowspan="2"># of Production Schedules</th>
      <th colspan="3">Before</th>
	   <th colspan="3">After</th>
   </tr>
   <tr>
      <th>Time</th>
      <th># of Queries</th>
	   <th>Memory usage</th>
      <th>Time</th>
      <th># of Queries</th>
	   <th>Memory usage</th>
   </tr>
   <tr>
      <td>20</td>
      <td>22.846s</td>
      <td>1,379</td>
      <td>882.0MB</td>
      <td>8.046s</td>
      <td>1,180</td>
      <td>103.4MB</td>
   </tr>
   <tr>
      <td>300</td>
      <td>41.098s</td>
      <td>6,297</td>
      <td>1.0GB</td>
      <td>43.694s</td>
      <td>5,732</td>
      <td>363.5MB</td>
   </tr>
	<tr>
      <td>1000</td>
      <td>N/A (MemoryError)</td>
      <td>N/A (MemoryError)</td>
      <td>>2GB</td>
      <td>88.416s</td>
      <td>22,629</td>
      <td>1.1GB</td>
   </tr>
</table>
Average memory usage reduction: 75%


opw-5225472

Forward-Port-Of: odoo/enterprise#106392

Purpose:
This module links the `point_of_sale` module with the `l10n_gt_edi` module. It is required in Guatemala to comply with Guatemalan Point of Sale legislation.

Before this commit:
- POS orders had no default customer.
- Invoices generated for unidentified customers exceeding the legal threshold, leading to SAT rejections after submission.
- GT Phrases configured on company were missing on the invoices generated through POS causing the electronic document to be rejected by SAT.

After this commit:
- Consumidor Final is set as the default customer on POS orders.
- POS invoices cannot be generated for unidentified customers when the total exceeds the legal threshold (currently Q2500).
- GT phrases configured on the company are now applied to POS invoices, ensuring valid electronic document submission to SAT.

Technical Details:
- Added a configurable legal threshold field on POS configuration.
- Added validation to block invoicing when an unidentified customer exceeds the configured threshold.
- Added a missing `super()` call in `l10n_mx_edi_pos` to ensure proper method chaining when multiple POS localizations are installed.

related PR https://github.com/odoo/odoo/pull/242985

task-4393614

Forward-Port-Of: odoo/enterprise#103767

PURPOSE

The way we currently use the UTM trackers (aka source/medium/campaign) does not
comply with the industry standards, leading to confusion and globally unclear
or not usable reporting on UTM data.

SPECS

This aims at modifying UTM assignation to improve the important information
relayed by UTM trackers, notably in reporting. This comes with two main changes
in UTM handling:

Generalize the UTM source and retire "utm.source.mixin"
Every time a social.post, a mass.mailing, a res.users, and many more records
are created, we create a matching utm.source record through the
utm.source.mixin and use that source in various flows.

This essentially means that we have hundreds, sometimes thousands of different
sources, making reporting useless as you cannot group by source and get a
meaningful graph of how your leads are generated.

UTM sources will now become mostly generic records ("Mass Mailing",
"LinkedIn", ...) allowing get a limited number of static sources.

Introduce UTM reference
As we remove the UTM mixin and thus the creation of sources, this has a number
of drawbacks, the most notable one being the loss of statistics that were
previously retrieved using the source record.

For example, you could see how many crm.leads a certain mass.mailing or a
certain social.post generated, which is useful in terms of tracking what
marketing practices work and how to improve your content. It's also a great
strength of the Odoo ecosystem to have links and inter-connected apps.

This is resolved by introducing a fourth field on the utm.mixin: utm_reference.
That new field serves the purpose of the former utm.source.mixin in a much
simpler way as it's a reference field storing model,id and doesn't require an
extra model.

Implement the above in all functional modules
To ease the tracking of the changes, functional modules are gradually modified
in separate commits, with additional specificities for some of them.

EXAMPLE

Let's take a real example: a mass.mailing with a button to purchase something.
The button is clicked and a client buys a product from the store with the UTM
values of that mass.mailing's link trackers.

The resulting sale order's UTM trackers will look like the following:

Before:
- UTM Campaign: Black Friday Sales
- UTM Medium: utm.utm_medium_email
- UTM Source: "Black Frid... (Mailing Created on 2024-04-14)"

After:
- UTM Campaign: Black Friday Sales
- UTM Medium: utm.utm_medium_email
- UTM Source: utm.utm_source_mailing
- UTM Reference: mailing.mailing,42

Task-3330036

[IMP] documents(,_account): access parent company folders from branches

Enable child companies to use accounting document synchronization folders (`documents.account.folder.setting`) of their parents when sharing the same journal:
- Previously the document synchronization setting (documents.account.folder.setting) was only applicable to the configured company, now it is also applicable to children companies. This enables children companies sharing a common journal with their parent to synchronize documents in the Document App. To support that feature, parent company folders (of the settings) are now visible to child companies through overridden `env_companies_access` logic.
- Previously when uploading or moving a document to an account synchronization folder made the document inherit from the folder company regardless of the selected company. Now, we use the active company (if it is a child of the related account setting company) as the company of the uploaded or moved document (including when using a server action like "Vendor Bill"). This allows having a parent company folder shared with child companies while preserving the company of the document we're dealing with.
- Previously only the company root folder were protected against modification from a non-manager user. We now extend that to folders used for account document synchronization (documents.account.folder.setting). For that we create a new searchable field is_protected that replaces the former condition in the code and record rules. That field and related methods are overridden in documents_account to add the new behavior.
- We have also modified the account setting view (actually the fields domain in the model) to improve the company consistency between the different fields: the journal company and the folder company (except for folder without a company) must be the same as the company setting.

Co-authored-by: Pierre-Yves Dufays <pydu@odoo.com>

Task-5363821

Before this PR, users could add default prompts to act as quick action buttons when opening the AI chat channel from the AI systray button. However:

  - These prompts had to be small, otherwise, there would be UI problems because the prompts were used as titles for the buttons.

  - Posting large prompts to the chat channel doesn't provide the best user experience.

  - Prompts were just text which prevented users from accessing fields of models to write more sophisticated prompts.

  - To fix this, this commit does 3 things:

    - Separate between the text appearing on the default prompt buttons and the actual prompts sent to the AI when these buttons are clicked which solves the UI problem when using large prompts.

    - When the default prompt button is clicked, the button title will be posted to the chat channel. Yet, the actual prompt defined on that button will be sent to the AI instead of the button title.

    - Allow users to use `/field` for AI default prompts to give them the ability to write more sophisticated prompts that
can access fields of models. Users would be able to access fields of the model that is defined on the AI composer (if one is defined). In order to be able to do that, the field `focused_model_ids` is changed into `Many2one` field so that the composer is tied to only 1 model.

Misc:

  - Move some utils from the `ai_fields` module into the `ai` module. The logic defined in `tools.py` in `ai_fields` is now used in the `ai` module. So, the logic is moved into the `ai` module as it is the base for other ai related modules.

  - Previously, all the `ai.prompt.button` records were created inside the `ai` app. The `_search` method was overridden to filter out prompt buttons whose modules weren't installed. This was done to avoid creating multiple small bridge modules. However, The optimal solution is to create bridge modules and add the records of `ai.prompt.button` inside the corresponding modules.

task-5153846

**Steps to reproduce:**
- Install Accounting
- In Accounting settings, activate "Audit Trail"

- Go to "Accounting / Accounting / Management / Assets"
- Create an asset:
  * Original Value: [any]
  * Acquisition Date: [in the past] (e.g. 01/01/2025)
  * Duration: [at least until today] (e.g. 36 Months)
  * Depreciation Account: [any]
  * Expense Account: [any]
- Confirm the asset

- Modify Depreciation:
  * Action: Dispose
  * Date: [in the past] (e.g. 30/10/2025)
  * Loss Account: [any]
- Dispose

- Go to "Accounting / Reporting / Management / Depreciation Schedule"
- Filter on a period after the disposal date

**Issue:**
The asset appears in the selected period even if it has already been disposed.

**Cause:**
There are posted depreciation moves that have a date after the disposal date.
These moves should be deleted but the Audit Trail feature prevents it. These moves are cancelled instead.
However, the disposal date computed on the asset is taking the max date from all the depreciation moves.
Even the cancelled ones ; leading to a disposal date different than the one entered.

opw-5225749

Forward-Port-Of: odoo/enterprise#107028

Before this commit:
====================
When opening the product catalog from shop floor, the Back button is labeled “Back to Production” and navigates the users to Manufacturing Order(MO) form view instead of returning to Shop Floor.

Steps to Reproduce:
====================
1. Install `mrp_workorder` module.
2. Create a MO → Open it in `ShopFloor` → Open the Product Catalog to add a component to the MO.
3. Click on `Back to Production`. It will redirect to MO form view.

Cause of the issue:
====================
The `backToQuotation` method in `ProductCatalogKanbanController` redirects the user back using breadcrumbs, and when no breadcrumbs exist, it falls back to opening the form view. Since the catalog is opened from the Shop Floor without any breadcrumbs, the user is always redirected to the MO form view.

After this commit:-
====================
These changes rename the back button to `Back to Shop Floor` and ensure it redirects users to the Shop Floor when the catalog is opened from there.

TaskID-5355924

Forward-Port-Of: odoo/enterprise#101331

Versions
--------
- 19.0+

Steps
-----
1. Install the Rental and Inventory apps.
2. Go to the rental schedule.
3. Observe the gantt view is grouped by product by default.
4. Remove the product groupby filter.

Issue
-----
The product groupby filter reappears.

Cause
-----
The base gantt view defines `default_group` as product. Additionally, the `sale_stock_renting` module overrides the
`sale_renting.action_rental_order_schedule` action to add two default groupby filters: `search_default_groupby_product` and `search_default_groupby_reserved_lot`.

This creates conflicting defaults: one from the gantt view directly (groupby product) and another from the context (groupby product and reserved lot).

Since lots are disabled by default, the lot groupby filter is ignored. When removing the product filter, the framework falls back to `default_group` and reactivates the product groupby filter.

Solution
--------
Remove the `default_group` parameter from the gantt view. Ensure all actions using the gantt view define their own defaults via context.

opw-5887837

Forward-Port-Of: odoo/enterprise#107008

Currently, an `incorrect warning` message is shown when sending an invoice to 
`DIAN`, if the invoice date is 6 days before today, even though this 
date should be considered valid.

**Steps to reproduce:**
- Install the `l10n_co_dian` module and switch to the `CO company`.
- Go to `Invoicing` and create a new invoice with `taxes`.
- Set the `Invoice Date` to 6 days before today.
- Click `Confirm` > `Send`, ensure `DIAN` is selected, and `send` the invoice.
- Observe the warning message.

**Observation:**
`The issue date can not be older than 5 days or more than 5 days in the future.`

**Root cause:**
At [1], the allowed invoice date range is incorrectly computed, using 
`5 days in the past` and `10 days in the future`. This does not match the Colombian 
regulations and triggers incorrect validation errors for valid invoice dates.

**Fix:**
This commit updates the date constraint logic to allow invoices dated up to 
`6 days before and 6 days after` the current date, in accordance with the 
DIAN specification described in Anexo Técnico – Documento Soporte No Obligados, 
page 59, at [3].

<img width="1089" height="120" alt="DIAN" src="https://github.com/user-attachments/assets/408c5ccc-5fed-4585-a81e-dce4ccb98b40" />

[1]:
https://github.com/odoo/enterprise/blob/62f59f87a513a86a61f871ca743e7f7b04926a82/l10n_co_dian/models/account_edi_xml_ubl_dian.py

[3]:
https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Documento-Soporte-No-Obligados.pdf

opw-5482555

Forward-Port-Of: odoo/enterprise#107399
Forward-Port-Of: odoo/enterprise#105763

Problem:
When running the MPS report on a large number of production schedules, if the associated number of stock moves is high, the _get_moves_and_date method can cause a memory error.

Solution:
We will fetch only the necessary fields to reduce queries and memory usage and set prefetch_fields=False to further reduce memory usage.

Benchmarks:
Run locally on a dupe of customer's db.
Time/queries measured by requests to /get_mps_view_state Memory measured using memray on method get_production_schedule_view_state()

<table>
   <tr>
      <th rowspan="2"># of Production Schedules</th>
      <th colspan="3">Before</th>
	   <th colspan="3">After</th>
   </tr>
   <tr>
      <th>Time</th>
      <th># of Queries</th>
	   <th>Memory usage</th>
      <th>Time</th>
      <th># of Queries</th>
	   <th>Memory usage</th>
   </tr>
   <tr>
      <td>20</td>
      <td>22.846s</td>
      <td>1,379</td>
      <td>882.0MB</td>
      <td>8.046s</td>
      <td>1,180</td>
      <td>103.4MB</td>
   </tr>
   <tr>
      <td>300</td>
      <td>41.098s</td>
      <td>6,297</td>
      <td>1.0GB</td>
      <td>43.694s</td>
      <td>5,732</td>
      <td>363.5MB</td>
   </tr>
	<tr>
      <td>1000</td>
      <td>N/A (MemoryError)</td>
      <td>N/A (MemoryError)</td>
      <td>>2GB</td>
      <td>88.416s</td>
      <td>22,629</td>
      <td>1.1GB</td>
   </tr>
</table>
Average memory usage reduction: 75%


opw-5225472

Forward-Port-Of: odoo/enterprise#106392

Problem:
When running the MPS report on a large number of production schedules, if the associated number of stock moves is high, the _get_moves_and_date method can cause a memory error.

Solution:
We will fetch only the necessary fields to reduce queries and memory usage and set prefetch_fields=False to further reduce memory usage.

Benchmarks:
Run locally on a dupe of customer's db.
Time/queries measured by requests to /get_mps_view_state Memory measured using memray on method get_production_schedule_view_state()

<table>
   <tr>
      <th rowspan="2"># of Production Schedules</th>
      <th colspan="3">Before</th>
	   <th colspan="3">After</th>
   </tr>
   <tr>
      <th>Time</th>
      <th># of Queries</th>
	   <th>Memory usage</th>
      <th>Time</th>
      <th># of Queries</th>
	   <th>Memory usage</th>
   </tr>
   <tr>
      <td>20</td>
      <td>22.846s</td>
      <td>1,379</td>
      <td>882.0MB</td>
      <td>8.046s</td>
      <td>1,180</td>
      <td>103.4MB</td>
   </tr>
   <tr>
      <td>300</td>
      <td>41.098s</td>
      <td>6,297</td>
      <td>1.0GB</td>
      <td>43.694s</td>
      <td>5,732</td>
      <td>363.5MB</td>
   </tr>
	<tr>
      <td>1000</td>
      <td>N/A (MemoryError)</td>
      <td>N/A (MemoryError)</td>
      <td>>2GB</td>
      <td>88.416s</td>
      <td>22,629</td>
      <td>1.1GB</td>
   </tr>
</table>
Average memory usage reduction: 75%


opw-5225472

Forward-Port-Of: odoo/enterprise#106392