This update makes Odoo app model definitions available from each app's main entry point, so other apps can reference them without depending on internal folder layouts. It is an internal maintainability improvement that supports future typing work and should not change day-to-day user workflows.

[IMP] *: Import models at the addon root level

Odoo model classes whose name matches their model are exposed at the root
level of the addon. This is so that other addons do not have to take into
account the structure which is an implementation detail.
These classes can be easily used for typing. This use will be present
later.

see: https://github.com/odoo/odoo/commit/5733d252b8f760b87bdd43ec6ac9ed22c4f1d07e

Approval activity items now use the shared persona display, making requester or assignee information more consistent with the rest of Odoo. This improves readability and provides a more uniform experience when reviewing approval tasks.

PR community: https://github.com/odoo/odoo/pull/190161

Auto planning now looks at the most relevant past or upcoming shift for the same customer/product or project, then assigns the work to the same available person when possible. This helps maintain continuity for customers, especially after contract renewals, while still respecting staff availability.

Currently, when auto plan schedules a shift linked to an SOL, it will try to keep all of the related shifts assigned to the same person. However, if the customer renews their contract and a new SOL is created, auto plan won't assign the new shift to the same resource. This doesn't make sense as it is likely for the customer to continue working with the person they are familiar with and who knows about their needs best.

After this commit:
- If only the SOL of a shift is set and auto plan is run, we plan it to the resource of the "closest" shift linked to an SOL of the same product and the same customer.
- If only the project of a shift is set and auto plan is run, we plan it to the resource of the "closest" shift linked to the same project.

In both cases, "closest" means we pick the shift having the closest deadline compared to the current date. We also check if the resource is available. If not, we look at the next closest shift.

task-4295867

The IoT quality configuration screen now places the more commonly used Printer Reports tab before Quality Control Points. This makes frequently accessed printer report settings easier for users to find and reduces navigation friction.

As it's "Printer Reports" tab is more widely used than "Quality Control Points" one, we moved it in first posistion.

Task: 4146883

The Spanish Modelo 130 tax reporting functionality is now included directly in the main Spanish accounting and reporting modules instead of separate add-ons. This simplifies installation and maintenance while keeping the existing quarterly tax report and export capabilities available to Spanish businesses.

This PR merge the modules l10n_es_modelo130 & l10n_es_reports_modelo130 into the respective l10n_es & l10n_es_reports modules.

These 2 modules were added in stable, here's the related PR's : 

- [l10n_es_modelo130](https://github.com/odoo/odoo/pull/164946)
- [l10n_es_reports_modelo130](https://github.com/odoo/enterprise/pull/62197)

linked:https://github.com/odoo/odoo/pull/176173
linked:https://github.com/odoo/upgrade/pull/6359

task-3866238

Map views now show 0 instead of None when records are grouped by an integer field with no value. This makes grouped data clearer and avoids confusing empty labels for business users.

SPECIFICATION:

When grouping by an integer field, ensure that if the field's value is empty, display the 0 instead of None in the all views.

Related Community PR-https://github.com/odoo/odoo/pull/187567
Task-4327850

Restaurant appointment and retail point-of-sale flows were adjusted to stay aligned with recent direct sale changes. This helps keep ordering, certification, invoicing, IoT, and delivery integrations working consistently across affected POS scenarios.

Change restaurant flows and retail interface.

task-id: 4314614
Community PR: https://github.com/odoo/odoo/pull/188390

After a WhatsApp chat is forwarded to a human operator, the chatbot is now removed from the conversation. This keeps the channel focused on the customer and operator, reducing confusion during live support handoffs.

Until now, the chat bot stayed as a member of the channel after the "forward_operator" step. It makes more sense to remove it from the channel.

task-4354075


community: https://github.com/odoo/odoo/pull/189456

The Moroccan reports module now lets users manually edit the Payment Channel value even though it is calculated automatically. This fixes cases where the automatically suggested payment channel needs correction, improving reporting accuracy without workarounds.

Upgrade PR: https://github.com/odoo/upgrade/pull/6842

task-4226448

The appointment website test now creates the data it needs during the test instead of relying on preloaded demo data. This helps keep automated checks stable across environments and reduces the risk of false failures during releases.

With this PR [1](https://github.com/odoo/enterprise/pull/72612),  without demo data tour(test_searchbar_within_appointments) was failing, so required data created on the fly.

runbot: 109512

This update restores expected behavior in Documents and Marketing Automation after a shared technical change affected kanban views. Users should see more reliable document selection and proper confirmation prompts when deleting parent marketing activities.

The documents and marketing_automation apps previously used some information
in the "list" prop that was removed in favor of a optional field "groupByField"
for simplification purposes.
See changes introduced by https://github.com/odoo/odoo/pull/189109 and https://github.com/odoo/enterprise/pull/74863

Now we only use the "selection" prop of the list for documents and
the code to display the confirmation message when deleting parent activities
is moved in the HierarchyKanbanRenderer with the help of the deleteRecord
function.

task-4377706

WhatsApp conversations now better separate the name shown for a discussion from the underlying channel name. This internal cleanup supports clearer behavior and helps maintain consistent access checks without changing the day-to-day user experience.

Enterprise counter-part.

https://github.com/odoo/odoo/pull/190243

Before this commit, when opening a table with an order, the draft order would not be shown. This was because, when there was no order to sync, the sync function was not called to retrieve the orders from the server. This is needed in the restaurant module. opw-4370055 Forward-Port-Of: odoo/enterprise#75105 Forward-Port-Of: odoo/enterprise#74909

Before this commit, when opening a table with an order, the draft order would not be shown. This was because, when there was no order to sync, the sync function was not called to retrieve the orders from the server. This is needed in the restaurant module.

opw-4370055

Forward-Port-Of: odoo/enterprise#75105
Forward-Port-Of: odoo/enterprise#74909

Currently, the timesheet header is not working correctly in the list view. There are a bunch of issue that this commit aims to fix: An empty header is displayed when the start button is pressed, and trying to either stop it or discard it will triggers an error The grouped by function triggers a similar issue as the one above when trying to start & stop the timer When there are no timesheetable project inside the database, an error is triggered too when starting the timer. Source of t

Currently, the timesheet header is not working correctly in the list view. There are a bunch of issue that this commit aims to fix:

An empty header is displayed when the start button is pressed, and trying to either stop it or discard it will triggers an error

The grouped by function triggers a similar issue as the one above when trying to start & stop the timer

When there are no timesheetable project inside the database, an error is triggered too when starting the timer.

Source of the issues :
- when trying to start a timer in the list view, the function 'cleartimesheetname' is triggered. The problem is that function triggers an update on the listview. This update then triggers a second execution of the 'onWillUpdateProps' of the timesheet_timer_hook class. This second execution is not expected in the flow and set the value of the timesheet of the header to 'false'.

- when the view is grouped, the record are not loaded inside the the folded section. This means that when we search for the record inside the 'popRecord' function of the timesheet_timer_hook class, we find nothing. In this use case though, the record is supposed to be found and set.

- when there are no timesheetable project, the method 'popRecord' will set the timesheet of the header back to 'undefined'.

Solution :

- Removed the 'cleartimesheetname' method, as it is no longer usefull. A check up in the write/create of the model will prevent the required field 'description' from being null. The 'enterEditMode' has also been restricted to the kanban view, since doing this in the list view was also triggering an extra call to 'onWillupdateprops'

- Checked the view to get a dynamicRecordList we can use to correctly set the data. More information inside the comment in the code.

- added a condition inside the 'popRecord' method so that in no longer set the timesheet to undefined when we dont need it to

task - 4268687
affected version 18.0-master

Forward-Port-Of: odoo/enterprise#74264

The condition previously added leads to an error when exporting mod 347 in l10n_es as generating the export file for this report always requires period comparison. Previous pr: https://github.com/odoo/enterprise/commit/045fd08c11d5f1407e971da52ea29654ac28aa93#diff-5fc5051f5c0211c0eec96b892e7d29e01b68d804417443502d17bccd8333d7ecR659 Forward-Port-Of: odoo/enterprise#75401

The condition previously added leads to an error when exporting mod 347 in l10n_es as generating the export file for this report always requires period comparison.

Previous pr:  https://github.com/odoo/enterprise/commit/045fd08c11d5f1407e971da52ea29654ac28aa93#diff-5fc5051f5c0211c0eec96b892e7d29e01b68d804417443502d17bccd8333d7ecR659

Forward-Port-Of: odoo/enterprise#75401

- make the start_notice_period take the wizard departure_date instead of next monday in case of having `mutual agreement` the departure reason Task: 4373961 Forward-Port-Of: odoo/enterprise#75041

- make the start_notice_period take the wizard departure_date instead of next monday in case of having `mutual agreement` the departure reason

Task: 4373961

Forward-Port-Of: odoo/enterprise#75041

Forward-Port-Of: odoo/enterprise#75262

Forward-Port-Of: odoo/enterprise#75262

**[FIX] stock_barcode: move entire package button** > Before this commit, the buttons to add quantity on a barcode line were also displayed for package lines. It shouldn't be the case and it doesn't work (traceback when clicked.) This commit fixes that. **[FIX] stock_barcode_*: views priority** > *: stock_barcode_mrp, stock_barcode_picking_batch > > This commit adds missing priority on primary `stock.move.line` form inherited views: > - `stock_barcode_mrp.stock_move_line_product_selecto

**[FIX] stock_barcode: move entire package button**
> Before this commit, the buttons to add quantity on a barcode line were also displayed for package lines. It shouldn't be the case and it doesn't work (traceback when clicked.) This commit fixes that.

**[FIX] stock_barcode_*: views priority**
> *: stock_barcode_mrp, stock_barcode_picking_batch
> 
> This commit adds missing priority on primary `stock.move.line` form inherited views:
> - `stock_barcode_mrp.stock_move_line_product_selector`
> - `stock_barcode_picking_batch.stock_move_line_product_selector_inherit`
> 
> Without this field, those views will have the default priority and will sometime be displayed instead of the default move line form view (`stock.view_move_line_form`) which causes a traceback because those views were explicitly created for the Barcode app and use specific widget which is no usable in other contexts.

task-4329041

Forward-Port-Of: odoo/enterprise#73682

The multipage computation of xslx files was a bit overkill as it would convert the xlsx file to an o-spreadsheet json friendly form where it could simply explore the zip files. Furthermore, that convertion would create attachments for each media file present in the xlsx file. This is bad in 2 ways: - the created attachment would never be used again - we were creating attachment while calling a computed field (read/write mix is bad) Task-4213183 Forward-Port-Of: odoo/enterprise#75332 Forwar

The multipage computation of xslx files was a bit overkill as it would convert the xlsx file to an o-spreadsheet json friendly form where it could simply explore the zip files. Furthermore, that convertion would create attachments for each media file present in the xlsx file. This is bad in 2 ways:
- the created attachment would never be used again
- we were creating attachment while calling a computed field (read/write mix is bad)

Task-4213183

Forward-Port-Of: odoo/enterprise#75332
Forward-Port-Of: odoo/enterprise#70722

Current behaviour: --- When trying to duplicate a resource booking containing a resource, you get a Validation Error for a missing field. Expected behaviour: --- Ability to duplicate a resource booking Steps to reproduce: --- 1. Go to Appointments 2. Select a resource appointments (ie. Tennis Court) 3. Click on new (To make a new resource booking) 4. Set a name, attendee, AND resource (ie. Court 1) 5. Go to list view, and open newly made booking 6. Click on the cog > Duplicate

Current behaviour:
---
When trying to duplicate a resource booking containing a resource, you get a Validation Error for a missing field.

Expected behaviour:
---
Ability to duplicate a resource booking

Steps to reproduce:
---
1. Go to Appointments
2. Select a resource appointments (ie. Tennis Court)
3. Click on new (To make a new resource booking)
4. Set a name, attendee, AND resource (ie. Court 1)
5. Go to list view, and open newly made booking
6. Click on the cog > Duplicate
7. Validation Error

Cause of the issue:
---
Caused by: https://github.com/odoo/enterprise/commit/064e0da976edd7ef501e4fb33d4d579eaab85a3d 
When duplicating a calendar.event, at the field appointment_resource_ids, the relation table appointment_booking_line 
is used on the fields calendar_event_id and appointment_resource_id. 
However, the model appointment_booking_line has another required field capacity_reserved. 
So when inserting into the table:
https://github.com/odoo/odoo/blob/b64a507697381fd7bb205f4a2b2217322d31811a/odoo/fields.py#L4945 
Only the two specified columns/fields are set, but not the third required field capacity_reserved.
Which causes a SQL error "violates not-null constraint"

opw-4187159

Forward-Port-Of: odoo/enterprise#75014
Forward-Port-Of: odoo/enterprise#71489

[IMP] documents improve search panel and home kanban view This commits brings changes to the search panel that should improve UX: - When coming from another app (e.g. Projects), the COMPANY folder stays folded... -... and the name of the folder containing the targeted document is displayed below the breadcrumbs, right before the cogwheel. - "Home" background changes when you hover or select it, the same way as for the folders. - Deselect 'Home'* (if selected) when adding a search item.

[IMP] documents improve search panel and home kanban view
This commits brings changes to the search panel that should improve UX:
- When coming from another app (e.g. Projects), the COMPANY folder
stays folded...
-... and the name of the folder containing the targeted document is
displayed below the breadcrumbs, right before the cogwheel.
- "Home" background changes when you hover or select it, the same way
as for the folders.
- Deselect 'Home'* (if selected) when adding a search item.
- Clear search and order by `last_accessed_date` when clicking on 'Home'.
- When users navigate through COMPANY folders via the Kanban or the List
view, and COMPANY is folded, the search panel does not expand the visited
folders.
- Clicking on the caret before the folder name, fold/unfold the folder
without selecting it (setting it as the active folder).
- Clicking on a folder name in the search panel just select it
(no folding/unfolding).
- Main folders like 'COMPANY', that name is preceded by an icon, also
have a caret for folding/unfolding.
- Kanban view: limit pager size to 40 records.

* actually, it's just a visual trick: removing the active class from the
'Home' header element.

task-4293935

Forward-Port-Of: odoo/enterprise#73443

This PR hides the “Update DGI Status” button on the account.move form view when the CFE Status is either “CFE Accepted by DGI” or “CFE Rejected by DGI”. This change is necessary because both “Accepted” and “Rejected” are final states that cannot transition to another status. Once a CFE reaches either of these states, there is no status update possible, making the button irrelevant in these scenarios. Task Adhoc side: 43467 Task Latam side: 1295 Forward-Port-Of: odoo/enterprise#75144

This PR hides the “Update DGI Status” button on the account.move form view when the CFE Status is either “CFE Accepted by DGI” or “CFE Rejected by DGI”.

This change is necessary because both “Accepted” and “Rejected” are final states that cannot transition to another status. Once a CFE reaches either of these states, there is no status update possible, making the button irrelevant in these scenarios.

Task Adhoc side: 43467
Task Latam side: 1295

Forward-Port-Of: odoo/enterprise#75144

**Steps to reproduce:** - Make sure that PyPDF2 is in version 1.26.0 - Install l10n_mx_edi - Switch to a Mexican company - Create an invoice: * Customer: [a Mexican customer] * Payment Way: [Effectivo] * An invoice line with a product having a UNSPSC Category - Confirm the invoice - Generate CFDI via "Send & Print" button - Register a payment with "Efectivo" Payment Way - Update Payments on the invoice - Go to the payment - Force CFDI - Make sure the CFDI status of the paymen

**Steps to reproduce:**
- Make sure that PyPDF2 is in version 1.26.0
- Install l10n_mx_edi
- Switch to a Mexican company
- Create an invoice:
  * Customer: [a Mexican customer]
  * Payment Way: [Effectivo]
  * An invoice line with a product having a UNSPSC Category
- Confirm the invoice
- Generate CFDI via "Send & Print" button
- Register a payment with "Efectivo" Payment Way
- Update Payments on the invoice
- Go to the payment
- Force CFDI
- Make sure the CFDI status of the payment is "Signed"
- Print "Payment Receipt"

**Issue:**
PyPDF2 raises a traceback:
"IndexError: list index out of range".

**Cause:**
PyPDF2 is executing this code to format a warning: file = filename.replace("/", "\\").rsplit("\\", 1)[1] where filename is something liked "<xxx>" (coming from the qweb compilation). Therefore, there is no index 1.
The warning is coming from lxml and is due to the fact that we are evaluating a xml value as it is in a qweb template:
"FutureWarning: Use specific 'len(elem)' or 'elem is not None' test instead." And since this commit:
https://github.com/odoo/odoo/commit/fd67b56fc695526d09706d2b6218519ea255fc30 Python's "warning.py" is overridden in PyPDF2.

**Solution:**
Use "len(cfdi['cfdi_node'])" as advised to check if the xml node has children in the payment receipt template.

opw-4359466
opw-4366016

Forward-Port-Of: odoo/enterprise#75227

To reproduce: ============= - assign a user U without any group access to Appraisal app as manager of an appraisal - login as this user U and ask for feedback on the appraisal - fill the feedback, and change it's deadline to the past - try to consult the answers as user U -> redirected to survey expired error page Problem: ======== the access to appraisal feedback is checked based on the user's group access, but the user can be the manager of the appraisal without any group access to t

To reproduce:
=============
- assign a user U without any group access to Appraisal app as manager of an appraisal
- login as this user U and ask for feedback on the appraisal
- fill the feedback, and change it's deadline to the past
- try to consult the answers as user U -> redirected to survey expired error page

Problem:
========
the access to appraisal feedback is checked based on the user's group access, but the user can be the manager of the appraisal without any group access to the appraisal app

Solution:
=========
in addition to the group access, check if the user is the manager of the appraisal

opw-4354685

Forward-Port-Of: odoo/enterprise#75360

Steps to reproduce: - Install the l10n_cl_edi module - Create an invoice - Some terms are not translated : - Where it says: .. should say: .. - Donce dice: .. deberia decir: .. Issue: Some translation were missing making it incorect for the Chile localization. This comes from the [changes](https://github.com/odoo/enterprise/commit/33b6cafdf3985df255ef44) Fix: Updated the .pot and the .po accordingly to include the terms so the translation is correct. opw-4350114 For

Steps to reproduce:
 - Install the l10n_cl_edi module
 - Create an invoice
 - Some terms are not translated :
 	- Where it says: .. should say: ..
	- Donce dice: ..  deberia decir: ..

Issue:

Some translation were missing making it incorect for the
Chile localization. This comes from the [changes](https://github.com/odoo/enterprise/commit/33b6cafdf3985df255ef44)

Fix:

Updated the .pot and the .po accordingly to include the terms
so the translation is correct.

opw-4350114

Forward-Port-Of: odoo/enterprise#74447

## Description Most read `ir.rule` on documents are based around the searchable field `user_permission`. Both `documents.document` and `documents.access` rely on it, and its' implementation creates a recursive application of the ir.rule, as `documents.document` calls `_search_user_permission`, which reads on `documents.access`, whos `ir.rule` rely on `document_id.user_permission`, re-applying the same domain from `_search_user_permission`. This recursive-like behaviour creates excessively larg

## Description
Most read `ir.rule` on documents are based around the searchable field `user_permission`. Both `documents.document` and `documents.access` rely on it, and its' implementation creates a recursive application of the ir.rule, as `documents.document` calls `_search_user_permission`, which reads on `documents.access`, whos `ir.rule` rely on `document_id.user_permission`, re-applying the same domain from `_search_user_permission`.
This recursive-like behaviour creates excessively large queries with a lot of subquery, exploding the costs of it above the `jit_above_cost` threshold (500k by default), leading to slow execution, due to the JIT optimizer, which normally should be reserved for long analytical queries.

## Patch
Adding `auto_join=True` on `documents.access.document_id` will transform some of the subqueries in joins, and is done in `sudo` context, avoiding re-application of the `ir.rule` while resolving itself. The simplification of the query leads to lower query cost that is bellow the `jit_above_cost` threshold, removing the slow optimisation step, leading to faster execution, as it was the main bottleneck.

## Benchmark
On a db with a moderately sized `documents_document` table:

| Timings                       | Before | After | Speed up |
|-------------------------------|--------|-------|----------|
| `action_update_access_rights` | 7s     | 550ms | 12.7x    |

## Reference
task-4381572

Forward-Port-Of: odoo/enterprise#75280