This update aligns signature actions (request, resend, sign) within the Activity Popover with standard Chatter, providing a more consistent user experience. The changes also include technical improvements like syncing activity deadlines and preventing duplicate activity deletion, ensuring accurate and reliable signature workflows.

This PR brings feature parity to the signature Activity Popover by aligning its buttons with the standard Chatter, allowing users to request, resend, or sign documents directly from the popover.

To achieve this cleanly, the PR also includes:
- **Refactoring:** Moves shared signature logic (like `requestSignature`) into the `Activity` frontend model, eliminating duplicated JS code across UI components.
- **Date Sync Fix:** Adds Python overrides to keep the `mail.activity` deadline perfectly synced with the `sign.request` validity date on creation and modification.
- **Unlink activities Fix:** unlink activities on sign_request cancel and prevent double-delete error

Task: 5989542

This update ensures that product SKUs (or default codes) are now included in product listings on the website. It also streamlines the variant display, allowing users to see newly created variants directly without the previous import-only issue. This improves product visibility and simplifies the process for users managing product variations.

An important change for the products to include the SKU (or default_code in Odoo) to the products.
Also now set the variant setting on so that the user can see the variants created directly without having this confusing in-between where we import variants but they cannot see them.

Forward-Port-Of: odoo/enterprise#111317

This update resolves a technical issue that prevented the demo data from correctly generating time off allocations when using a future date (2027-01-01) for faketime testing. Updating the demo data ensures the system accurately reflects leave allocation rules, particularly for contracts starting January 1st, and avoids errors during testing.

Issue:
The Anita Oliver contract starts on %Y-01-01, so her leave allocation begins from that date.
When running with faketime set to 2027-01-01, the system attempts to create leave for the previous month, which results in an error stating that there is no allocation for that time off.

Fix:
Update the demo data to create the leave and payslip for the first month of the year. This prevents failures when using faketime and ensures it works correctly for real usage of `time off to defer`.

task-6026690

Forward-Port-Of: odoo/enterprise#110293

This update resolves a technical issue preventing the tour from correctly displaying the checkout address within the Brazilian localization (l10n_br) module. The fix addresses race conditions introduced by a recent community update to the select menu, ensuring the tour functions as expected.

Because of the community PR that changes the DOM of the select menu, the tour in this commit crashed.
This commit adapts the tour and fixes it as races conditions were still present

part-of-task-5935511

Forward-Port-Of: odoo/enterprise#111248

This update fixes an issue where the Report Editor in web_studio wouldn't automatically focus on the editable field after deleting a row or column. This change ensures a smoother user experience by immediately placing the user in the editable area, preventing frustration and improving efficiency. The fix was part of a larger community contribution.

PR [1] ensures that editable is focused after deleting row or column from table menu by preventing default while
clicking on table menu button. This change causes test [2] to fail if a table menu test runs beforehand, due to browser’s
native focus behavior. This commit ensures that editable is focused whenever clicking on t-field.

[1]: https://github.com/odoo/odoo/pull/249256
[2]: https://github.com/odoo/enterprise/blob/19.0/web_studio/static/tests/client_action/report_editor/report_editor_dom_edition.test.js#L456-L478

Community PR: https://github.com/odoo/odoo/pull/249256

task-5725593

Forward-Port-Of: odoo/enterprise#111154
Forward-Port-Of: odoo/enterprise#109034

This update resolves an error that occurred when activating the 'hr_expense_stripe' module with unsupported currencies (like INR). The fix prevents the creation of a problematic journal, ensuring the invoicing dashboard can be opened without errors. It now defaults to the company's currency for new databases.

Currently, an error occurs when a user opens the invoicing dashboard after activating the `hr_expense_stripe` module for Stripe card issuing with only unsupported currencies active.

Steps to reproduce: (19.0)
- Install `account` module
- Set Company currency to `INR` and deactivate `USD` in currencies.
- Install `hr_expense_stripe`
- Create New company > Set `Country` and `Currency` (eg: India and INR) > 
  Switch to New company > Open `Invoicing` you will get the error.

Steps to reproduce: (saas-19.1)
- Install `account` module
- Set Company currency to `INR` and deactivate `USD` in currencies.
- Install `hr_expense_stripe` > Open `Invoicing` you will get the error.

Traceback:
`ValueError: Expected singleton: res.currency()`

In this [PR], the behavior is such that if `company.stripe_currency_id` is not set, we do not create the "Stripe Issuing".

In 19.0, `@template` was executed after the post-init hook, and we were preventing the creation of the [journal] at that stage. However, when a new company is created, the template data is automatically loaded for companies 
with a matching chart of accounts. As a result, the `stripe_issuing_journal` is created, which leads to the error.

However, in saas-19.1, due to recent improvements in a [commit], the `@template` will now loads data for companies without post init hook. As a result, the `stripe_issuing_journal` is being created, and we are encountering an error.

Solution:
- The`Stripe Issuing` journal will no longer be created on installing the module.
- For existing databases, we will use the company currency as a fallback value to ensure that a valid currency is applied.

[PR]: https://github.com/odoo/enterprise/pull/96271
[journal]: https://github.com/odoo/enterprise/blob/fea009f98885a97439edfea75376b7323c8c9a03/hr_expense_stripe/models/res_company.py#L186-L187
[commit]: https://github.com/odoo/odoo/pull/228950/changes/21fd14ed5e8bdd2cf203d466069437a62a87f2bd

sentry-7284934493

Forward-Port-Of: odoo/enterprise#108436

This update resolves a technical issue related to how Odoo handles geographic data (topoJSON) within its spreadsheet charts. The fix ensures that these charts display correctly and reliably, improving the accuracy of visual reports. This change primarily impacts the Enterprise edition's chart functionality.

test adaptation
Counterpart of github.com/odoo/odoo/pull/248847

Task-5224009

Forward-Port-Of: odoo/enterprise#107912

This update resolves an issue where the topbar menu wasn't correctly updated when a menu was opened using the AI Agent. The fix ensures that the topbar menu accurately reflects the currently active menu after an AI Agent interaction, improving the user experience. This change was driven by a bug fix (Task-6017607).

Purpose:
--------
When a menu (view) was opened through an AI Agent, the menu in the topbar was not updated.
This commit fixes this behaviour by setting the menu when the menu's action has been loaded
Task-6017607

Forward-Port-Of: odoo/enterprise#109929

This update automatically calculates and transmits the necessary commission deductions for Swiss payroll (ELM) based on employee data. This ensures accurate tax reporting and compliance with Swiss regulations, streamlining the payroll process. The change corrects a previous issue related to commission calculations.

task-6050810

Forward-Port-Of: odoo/enterprise#111143

This update resolves a problem where the website's tour process was delayed due to timing issues, specifically with loading translations. The change ensures the tour starts correctly, preventing delays and improving the user experience. This was caused by recent changes in Chrome versions.

This commit adds an intermediary step ensuring the proper page has been reached before actually doing the checks and avoiding to let startup requests (like the loading of the translations) pending at the end of the tour (and the eventual stop of the runner browser).

Note: this is most likely due to a timing (indeterministic by nature) change, emphasised by recent Chrome versions (like v145).

runbot-239128

Forward-Port-Of: odoo/enterprise#111013
Forward-Port-Of: odoo/enterprise#110648

This update resolves a test issue where simultaneous data synchronization in the Point of Sale (POS) tax module caused errors. The fix ensures that backend processes complete before the test continues, improving test reliability and preventing disruptions. This enhances the overall stability of the POS tax functionality.

In the test test_pos_avatax_flow, two calls are made to get_order_tax_details almost simultaneously, which causes the second call to raise an error due to both call trying to sync the same order at the same time. This commit fixes the test by waiting for the backend calls to be done before proceeding with the test next steps.

runbot-error: 238871, 238872

Forward-Port-Of: odoo/enterprise#110341

This update resolves an issue where the map view in the "My Dashboard" sometimes collapsed due to conflicting height settings. The fix removes overly restrictive height rules and adds a minimum height to the map, ensuring it always displays correctly regardless of the number of records shown.

This commit fixes rendering height issues when the map view is displayed inside "My Dashboard".

* Removed `height: 100%` from the map and pin list containers. This conflicting rule interfered with the flexbox layout, often causing the map to collapse entirely since it couldn't compute its own height.
* Added a `min-height` to the map renderer. This ensures the map always occupies a reasonable amount of space in the dashboard, even when there are few or no records to display.

task-6022958

Forward-Port-Of: odoo/enterprise#111195
Forward-Port-Of: odoo/enterprise#110790

This update corrects a bug where changes to view ordering within the Documents module's studio interface weren't consistently applied. The fix involved updating the default order setting to be applied correctly through the designated attribute on the relational model, ensuring view ordering changes are now reliably saved and reflected.

Bug
===
When changing the order of the views using studio, it wasn't applied.

The reason is that we add a default order at the wrong place in JS, it should be done with the attribute made for that, `defaultOrderBy` on the relational model.

Task-6047024

Forward-Port-Of: odoo/enterprise#111395
Forward-Port-Of: odoo/enterprise#111091

This update removes a leftover file related to the l10n_it_xml_export module, which was previously removed in 19.0. This cleanup ensures a cleaner and more streamlined system, addressing a minor technical detail.

The module was removed in 19.0 by this commit:
https://github.com/odoo/enterprise/commit/761e08667a9c8172217afe8b709445d8e12b3872

However a file was accidentally left behind
This commit cleans up the remaining file

Forward-Port-Of: odoo/enterprise#111461

This update corrects a bug in the SendCloud delivery service that was preventing the system from correctly processing delivery requests. The issue stemmed from an incorrect use of Python slicing, which was causing a data retrieval error. The fix ensures reliable delivery processing.

Slicing in Python returns a sub-list, even for a single element. Doing `res[:1]` does not return the first element so doing `.get` causes an error.

This was not caught because the tests do not run in CI due to the tags on the class.

Forward-Port-Of: odoo/enterprise#111254

This update fixes an issue where the Report Editor wouldn't automatically focus on the editable field after making changes like deleting rows or columns. This ensures a smoother user experience when working with report designs, preventing unnecessary clicks and improving efficiency. The change was made to address a test failure related to browser focus behavior.

PR [1] ensures that editable is focused after deleting row or column from table menu by preventing default while
clicking on table menu button. This change causes test [2] to fail if a table menu test runs beforehand, due to browser’s
native focus behavior. This commit ensures that editable is focused whenever clicking on t-field.

[1]: https://github.com/odoo/odoo/pull/249256
[2]: https://github.com/odoo/enterprise/blob/19.0/web_studio/static/tests/client_action/report_editor/report_editor_dom_edition.test.js#L456-L478

Community PR: https://github.com/odoo/odoo/pull/249256

task-5725593

Forward-Port-Of: odoo/enterprise#109034

This update resolves an error that occurred when activating the 'hr_expense_stripe' module with unsupported currencies (like INR). The module will no longer attempt to create a specific journal, and existing company currencies will now be used as a fallback, ensuring the invoicing dashboard functions correctly.

Currently, an error occurs when a user opens the invoicing dashboard after activating the `hr_expense_stripe` module for Stripe card issuing with only unsupported currencies active.

Steps to reproduce: (19.0)
- Install `account` module
- Set Company currency to `INR` and deactivate `USD` in currencies.
- Install `hr_expense_stripe`
- Create New company > Set `Country` and `Currency` (eg: India and INR) > 
  Switch to New company > Open `Invoicing` you will get the error.

Steps to reproduce: (saas-19.1)
- Install `account` module
- Set Company currency to `INR` and deactivate `USD` in currencies.
- Install `hr_expense_stripe` > Open `Invoicing` you will get the error.

Traceback:
`ValueError: Expected singleton: res.currency()`

In this [PR], the behavior is such that if `company.stripe_currency_id` is not set, we do not create the "Stripe Issuing".

In 19.0, `@template` was executed after the post-init hook, and we were preventing the creation of the [journal] at that stage. However, when a new company is created, the template data is automatically loaded for companies 
with a matching chart of accounts. As a result, the `stripe_issuing_journal` is created, which leads to the error.

However, in saas-19.1, due to recent improvements in a [commit], the `@template` will now loads data for companies without post init hook. As a result, the `stripe_issuing_journal` is being created, and we are encountering an error.

Solution:
- The`Stripe Issuing` journal will no longer be created on installing the module.
- For existing databases, we will use the company currency as a fallback value to ensure that a valid currency is applied.

[PR]: https://github.com/odoo/enterprise/pull/96271
[journal]: https://github.com/odoo/enterprise/blob/fea009f98885a97439edfea75376b7323c8c9a03/hr_expense_stripe/models/res_company.py#L186-L187
[commit]: https://github.com/odoo/odoo/pull/228950/changes/21fd14ed5e8bdd2cf203d466069437a62a87f2bd

sentry-7284934493

Forward-Port-Of: odoo/enterprise#108436

This update fixes an issue where the "Submit" button was hidden when creating return types in the account reports. The change removes an outdated field requirement, ensuring the button is always visible for users to complete the return type creation process. This improves usability for users generating return reports.

When a user creates a return_type, the submit button is not visible as there is no type_external_id.
Since now, we have the states_workflow this is not useful anymore.

This commit is basically a back port of https://github.com/odoo/enterprise/commit/305b0078e584487036d907d6e18b7911bc7ff1de

Forward-Port-Of: odoo/enterprise#110328

This update corrects a previous error that occurred when the 'Payroll: Update Data' cron job ran, specifically within the Saudi Arabian payroll configuration. The issue stemmed from deleting salary rule categories, which caused a data mismatch during the update process. This fix ensures that the rule category data is updated before the salary rule data, preventing the error and maintaining accurate payroll processing.

Currently, an error occurs when the "Payroll: Update Data" scheduled action is executed.

**Steps to Reproduce:**
 - Install `l10n_sa_hr_payroll` with demo data.
 - Switch to `Saudi Arabian` company.
 - Go to `Payroll` > `Configuration` > `Salary` > `Rule Categories`.
 - Delete all records related to the Saudi Arabian company.
 - Go to `Scheduled Actions` and run `"Payroll: Update Data"`.

`ValueError: External ID not found in the system: l10n_sa_hr_payroll.l10n_sa_category_provision`

After [this commit], the category_id field becomes non-required, allowing users to delete 
a rule category record even if it is linked to a salary rule. When updating the data file [1], 
this causes an error due to the missing rule category [2].

This commit ensures that, when updating the salary rule data, the rule category data is updated 
beforehand, as shown here [3].

[this commit]: https://github.com/odoo/enterprise/commit/c663fd2a81b7f6b34f8199fdbdc4a75c4f21379e

[1]- https://github.com/odoo/enterprise/blob/5ab4cb8bbf8211783a23a4334b633d52633b0324/l10n_sa_hr_payroll/models/hr_payslip.py#L157-L165

[2]: https://github.com/odoo/enterprise/blob/5ab4cb8bbf8211783a23a4334b633d52633b0324/l10n_sa_hr_payroll/data/hr_salary_rule_saudi_data.xml#L249

[3]: https://github.com/odoo/enterprise/blob/5ab4cb8bbf8211783a23a4334b633d52633b0324/l10n_ke_hr_payroll/models/hr_payslip.py#L9-L18

sentry-7349905716

This update fixes an error in the reports generated for Ecuador (l10n_ec_reports_ats) by ensuring the correct 'tipoCliente' value is used for foreign partners. Previously, the system incorrectly identified company types, leading to inaccurate tax reporting. This change aligns with AFIP requirements and ensures compliance.

Since `tipoCliente` is now determined using the computed `is_company` field, the test data must reflect this logic.

`partner_ext` represents a foreign partner and is considered a company, therefore its `tipoCliente` should be set to '02'.

See: https://github.com/odoo/enterprise/commit/a779badac35cf4a8f483f490e8ae29eb6bf3d2c5

`l10n_ar_edi`: For foreign partners, AFIP requires the CUIT pais based on the partner’s country and document type, not on partner.is_company. In multi-localization databases, is_company may be influenced by local heuristics and lead to picking the wrong foreign tax identifier.
Use the identification type instead: VAT documents map to the legal-entity CUIT pais, while non-VAT documents map to the natural-person one.

See: https://github.com/odoo/enterprise/pull/86089#discussion_r2128977870

runbot-241126

This update resolves a technical issue related to how geographic data (specifically topoJSON) is processed within the Odoo Enterprise spreadsheet reports. The fix ensures accurate display of maps and charts based on location data, improving the reliability of reports. This change primarily impacts users who rely on location-based data visualizations.

test adaptation
Counterpart of github.com/odoo/odoo/pull/248847

Task-5224009

Forward-Port-Of: odoo/enterprise#107912

This update fixes a bug preventing portal users from viewing timesheets on helpdesk tickets linked to projects with 'Invited internal and portal users' visibility. The change expanded the domain to include both 'portal' and 'invited_users' visibility options, ensuring correct timesheet display for all users.

Steps to reproduce:

- Create Project A with visibility set to `Invited internal and portal users.`
- Create a Helpdesk Team and assign Project A to it.
- Create a helpdesk ticket.
- Log a timesheet on the ticket and share the ticket with the portal user.
- Log in as the portal user and check the timesheet.
- Observe that the timesheet is not visible to the portal user.

Cause:

- After introducing the `invited_users` option in `privacy_visibility`, the portal domain in `_timesheet_in_helpdesk_get_portal_domain` was not updated.

- The domain was still defined as: `('project_id.privacy_visibility', '=', 'portal')`

- As a result, timesheets linked to projects with visibility set to “Invited internal and portal users” were excluded from the portal user’s view.

Solution

Update the domain to include both visibility options: `('project_id.privacy_visibility', 'in', ['portal', 'invited_users'])`

- This ensures timesheets are visible to portal users when the project visibility is either portal or invited_users.

task-5924243

Forward-Port-Of: odoo/enterprise#107800

This update removes a lingering file that was unintentionally left behind after the l10n_it_xml_export module was removed in the previous release. This cleanup ensures a cleaner and more streamlined codebase, addressing a minor technical detail.

The module was removed in 19.0 by this commit:
https://github.com/odoo/enterprise/commit/761e08667a9c8172217afe8b709445d8e12b3872

However a file was accidentally left behind
This commit cleans up the remaining file

Forward-Port-Of: odoo/enterprise#111461

This update corrects a visual issue in the accounting reports where the company header was grayed out in dark mode. The change ensures the company header consistently uses the standard muted data color, providing a better and more consistent user experience across all Odoo environments.

Before this pr:
- The company header in the accounting reports is grayed out in the light mode
  only, not in the dark mode.

Reason:
- Until now, we have been using the hard-coded 'lightgrey' color for the company
  header.

After this pr:
- In this pr, we are changing the color of the company header from
  hard-coded 'lightgrey' color to the standard variable color
  '--AccountReport-muted-data-color' used for muted data in account reports.

Task-5960592

Forward-Port-Of: odoo/enterprise#111353
Forward-Port-Of: odoo/enterprise#110108

This update resolves a technical issue related to how geographic data (specifically topoJSON) is processed within the Enterprise edition's spreadsheet reports. The fix ensures accurate display of geographical charts and maps, improving the reliability of data visualization for business users. This change was part of a larger adaptation to improve testing.

test adaptation
Counterpart of github.com/odoo/odoo/pull/248847

Task-5224009

Forward-Port-Of: odoo/enterprise#107912

This update corrects a bug where payslip dates were incorrectly using the employee's start date instead of their first contract date within the company. The system now uses the employee's initial contract date, ensuring accurate payroll reporting and compliance. This change was implemented as a fix to improve data consistency.

…irst contract date in payslips

- `first_contract_in_company` is now a computed field instead of being manually populated in the departure notice wizard.
- `first_contract_in_company` is now used for the first contract date in payslip reports instead of using the current version's start date.
- in departure notice wizard fixed how `first_contract` is calculated by using the refactored `_get_first_version()` function.
- removed manual update of `first_contract_in_company` in the departure wizard as it is now handled by the compute.


Task: 5368029

This update resolves an issue where CFDI reports incorrectly displayed '99 - False' instead of '99 - Por definir' for payment method 99. The fix ensures that the correct payment method description is generated in the PDF reports, improving data accuracy for Mexican tax reporting.

**PROBLEM**
PR https://github.com/odoo/enterprise/commit/843d57b25f925a5d4f1848b85717adb4d1a9d388 Archives payment method 99, but because it's archived `_l10n_mx_edi_get_extra_invoice_report_values()` doesn't retrieve it. This leads the pdf report to display '99 - False' instead of '99 - Por definir'.

**STEP TO REPRODUCE**
1. Create an invoice with the mx company.
2. Set the due date sometime in the month later. (To have the PPD payment policy on the invoice).
3. Send and generate the invoice using cfdi.

opw-5927655

Forward-Port-Of: odoo/enterprise#111051
Forward-Port-Of: odoo/enterprise#107267

This update automatically calculates and transmits the required perception commission for Swiss employees' payrolls. This ensures accurate tax reporting to the Swiss tax authorities, addressing a previous reporting issue. The change improves compliance and reduces the risk of errors related to commission calculations.

Forward-Port-Of: odoo/enterprise#111143

This update corrects a bug where changes to view ordering within the Documents module's studio interface weren't consistently applied. The fix involved updating the code to correctly utilize the `defaultOrderBy` attribute on the relational model, ensuring that view order settings are properly saved and reflected.

Bug
===
When changing the order of the views using studio, it wasn't applied.

The reason is that we add a default order at the wrong place in JS, it should be done with the attribute made for that, `defaultOrderBy` on the relational model.

Task-6047024

Forward-Port-Of: odoo/enterprise#111395
Forward-Port-Of: odoo/enterprise#111091

This update fixes a visual inconsistency in the accounting reports. Previously, the company header was grayed out only in light mode. Now, it dynamically adjusts to the dark mode theme using a standard muted data color, ensuring a consistent and professional appearance across all viewing modes.

Before this pr:
- The company header in the accounting reports is grayed out in the light mode
  only, not in the dark mode.

Reason:
- Until now, we have been using the hard-coded 'lightgrey' color for the company
  header.

After this pr:
- In this pr, we are changing the color of the company header from
  hard-coded 'lightgrey' color to the standard variable color
  '--AccountReport-muted-data-color' used for muted data in account reports.

Task-5960592

Forward-Port-Of: odoo/enterprise#111353
Forward-Port-Of: odoo/enterprise#110108

This update corrects a map data issue where Russia was missing from the Asia map. It also includes a new map for Oceania, ensuring more accurate geographic representation. This improves the visual accuracy of location-based data within Odoo.

- Fix Asia map (russia was missing)
- Added Oceania map

Task-5224009

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#248847

This update resolves a technical issue related to how geographic data (specifically topoJSON) is processed within the Odoo Enterprise spreadsheet reports. The fix ensures accurate display of maps and charts based on location data, improving the reliability of reports that rely on geographic visualizations. This update primarily impacts the spreadsheet functionality.

test adaptation
Counterpart of github.com/odoo/odoo/pull/248847

Task-5224009

Forward-Port-Of: odoo/enterprise#107912

This update addresses a technical issue related to the validation of partner country information within the l10n_ec_edi module. The fix ensures that the identification type of a partner aligns with their registered country, resolving two failing tests. This improves the accuracy of EDI processing for Ecuadorian businesses.

In pr https://github.com/odoo/odoo/pull/248585
I added a check that verify if the l10n_latam_identification_type of a partner correspond to the partner country.
It breaks two tests which are fixed here.

opw-5801824

This update resolves an issue preventing invoices to Åland Island (AX) partners from being correctly sent via PEPPOL. Previously, invoices were generated but not transmitted, resulting in attachments but no chatter notifications. This change enables Peppol functionality for companies in Åland Island.

Before this commit, invoice to a partner in Åland Island can't be sent via Peppol.
XML and PDF are generated, linked to the account.move, but are not sent and don't appear in the chatter.

Steps to reproduce:
- Create a partner in Åland Island
- Create an invoice
- Send to Peppol

Current behavior:
- Invoice is not sent, appear in the attachment, but doesn't appear in the chatter.

Expected behavior:
- invoice is sent and attachments are in the chatter

This also allow activating Peppol for companies in Åland Island.

Ticket [link](https://www.odoo.com/odoo/project.task/5949439)
opw-5949439

This update optimizes how Odoo loads its registry, significantly reducing the time it takes to start up, especially for customers with large addon installations. By avoiding unnecessary file system scans, the change dramatically improves performance and responsiveness, leading to faster request processing.

In `ThreadedServer,` the http daemon will create threads to handle incoming requests. The creation of these threads doesn't wait until the registry is loaded because the request could be serving static files. In the WSGI application entry point `__call__`, the threads will be going into `self.get_static_file` and up until this point, there's no locking whatsoever on these threads. Inside `get_static_file`, the `self.statics` lazy_property is evaluated which will walk the addons path.

Before this PR, the order of the conditions in the or statement will always evaluate the lazy property regardless of the other parts of the condition. This means that every single request that comes in will do an unnecessary `os.listdir` on all addons paths.

For customers with a very large and deeply nested addons path like in opw-5877522 (they had over 93K dirs), this is a tremendous load on the system when there are multiple threads doing that due to the amount of syscalls involved for no reason whatsoever. This is especially worse on SH because disks are not local, so an individual syscall is more expensive.

This is slowing down all requests as well as the registry loading time which is a prerequisite for any non-static request.

This PR simply reorders this check to only evaluate the self.statics property if all other parts of the condition are False. This means it'll only have to do this expensive `os.list` for a fewer number of requests which are much more unlikely to coincide at the startup of a worker. On top of that it's a better optimization to avoid doing this expensive check for every request.

Benchmarks

|No. files in addons path| No. concurrent threads  | Registry loading time Before PR | Registry loading time After PR |
|--------|--------|--------|--------|
| 93447 | 5  | 53.23 s  | 4 s  |



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

Forward-Port-Of: odoo/odoo#254660

This update corrects a previous issue that prevented users from finding and adding a partner's bank account when creating a credit note. The system now correctly filters bank accounts based on the expected recipient, ensuring credit notes function as intended. This resolves a limitation that was impacting credit note processing.

Description of the issue this commit addresses:

The Recipient Bank field in the Other Info tab of the Account Move form view refilters accounts to only show you company's ones. This is expected for invoices but is blocking when doing a credit note. You can't find a partner's bank account to fill that field.

---

Steps to reproduce:

1. Install account.
2. Create an Invoice to a partner which has a bank account setup.
3. Create a Credit Note for that Invoice.
4. In the "Other Info" tab, remove the partner's bank account.
5. Try to search for his bank account to add it back. It won't show up.

---

Desired behavior after this commit is merged:

The Recipient Bank field prefilters bank accounts based on who is expected to be the recipient of the move.

---

task-5976951

---

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

Forward-Port-Of: odoo/odoo#254850
Forward-Port-Of: odoo/odoo#252961

This update resolves an issue where CFDI reports incorrectly displayed '99 - False' instead of '99 - Por definir' for payment method 99. The fix ensures accurate reporting of this payment method, addressing a discrepancy in the Mexican tax invoice generation process. This ensures compliance and accurate financial reporting.

**PROBLEM**
PR https://github.com/odoo/enterprise/commit/843d57b25f925a5d4f1848b85717adb4d1a9d388 Archives payment method 99, but because it's archived `_l10n_mx_edi_get_extra_invoice_report_values()` doesn't retrieve it. This leads the pdf report to display '99 - False' instead of '99 - Por definir'.

**STEP TO REPRODUCE**
1. Create an invoice with the mx company.
2. Set the due date sometime in the month later. (To have the PPD payment policy on the invoice).
3. Send and generate the invoice using cfdi.

opw-5927655

Forward-Port-Of: odoo/enterprise#111051
Forward-Port-Of: odoo/enterprise#107267

This update resolves an issue where PDF merging errors didn't consistently display user-friendly error messages. The fix ensures that a clear error message is always shown when PDF merging fails, regardless of the underlying cause. This improves the user experience and helps identify problems with generated reports.

When merging pdfs, if there is an error when meging those pdfs (due to a malformed PDF for example), the UserError that should be shown to the user is not due to an error in the arguments given to the handle_error function.

The aim here is to keep the same function signature and edit the signature of the local function used when a custom_handle_error was defined and edit the function itself.

The error message appeared when I was working on a task to change a
test and tested it on master and got the following stacktrace:
```
...
  File "/home/odoo/Desktop/src/odoo/odoo/addons/base/models/ir_actions_report.py", line 788, in _merge_pdfs
    handle_error(error=e, error_stream=stream)
TypeError: IrActionsReport._handle_merge_pdfs_error() missing 1 required positional argument: 'self'
```

Discovered during : task-3603619

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

Forward-Port-Of: odoo/odoo#211611

This update automatically calculates and transmits the necessary commission information for Swiss payroll declarations (ELM). Previously, this calculation was manual, introducing potential errors and delays. This change ensures accurate and timely reporting to Swiss tax authorities, streamlining the payroll process.

Forward-Port-Of: odoo/enterprise#111143

This update corrects a display issue where the 'Pick Up in Store' option was incorrectly shown for products with excluded tags. The fix ensures that unavailable delivery methods aren't presented to customers, improving the user experience and maintaining consistent behavior across the website.

Currently, when a product has a tag that is configured as an Excluded Tag on the Pick Up in Store delivery method, the method is still shown on the product page.

Steps to produce:
---
- Install `website_sale` module.
- Enable `Click and Collect` in settings.
- Go to `website > ecommerce > products > product tags.`
- Create a new tag and add a product in product template.
- Go to` website > configuration > ecommerce > delivery method.`
- Open` pick up in store`:
    - In the `Stores` tab, set your company warehouse.
    - In the `Availability` tab, add the created tag to Excluded Tags.
    - Publish the delivery method.
- Open the tagged product on the website.

Issue:
---
- The Pick Up in Store option is still displayed on the product page, even though the product has a tag listed in the carrier’s Excluded Tags.

Root cause:
---
- Here at [1], the method `_get_additional_combination_info ()` does not check whether the product has tags that are excluded by the delivery method.
- However, at [2], during checkout, the exclusion works correctly because `_match_excluded_tags` in `delivery.carrier` filters the carrier based on excluded tags.

Solution:
---
- Hide the Pick Up in Store option when the product has tags excluded
  for that delivery method. This keeps the behavior consistent across
  the website, avoids showing unavailable delivery options, does not
  impact other flows and aligns with the existing behavior during
  checkout.

[1]https://github.com/odoo/odoo/blob/1c483c3a8d7d079bd34a378f9f8716551e4bab93/addons/website_sale_collect/models/product_template.py#L17-L21
[2]https://github.com/odoo/odoo/blob/1c483c3a8d7d079bd34a378f9f8716551e4bab93/addons/delivery/models/delivery_carrier.py#L192-L194

opw-5921268

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

Forward-Port-Of: odoo/odoo#255066
Forward-Port-Of: odoo/odoo#250837

This update corrects a validation issue in the ZATCA XML generation for Saudi Arabia companies. Previously, the system didn't include cash rounding amounts in the payable calculation, leading to validation errors. This change ensures accurate payable amount calculations for invoice validation, aligning with ZATCA requirements.

Currently the generated ZATCA XML is not accounting for invoice
cash rounding, leading to an invoice validation issue due to a mismatch
in the calculation of PayableAmount.

Steps to reproduce:
- Have a SA Company setup
- Create a [cash rounding] with strategy 'Add invoice line' and rounding 1.00 (UP)
- Create an invoice for 99.55 + 15% Tax
- Set Cash Rounding Method to [cash rounding]
- Confirm and send xml for validation

Issue:
Validation will issue the following warning
`[202] BR-CO-16 : Amount due for payment (BT-115) = Invoice total amount
with VAT (BT-112) -Pre-Paid amount (BT-113) + Rounding amount (BT-114).`

Analysis:
The ZATCA implementation was calculating the payable amount strictly as
(TaxInclusiveAmount - PrepaidAmount).  This change ensures the rounding
amount is fetched and added to the total payable calculation

opw-5939550

Forward-Port-Of: odoo/odoo#254450
Forward-Port-Of: odoo/odoo#253555

This update corrects a visual issue where menu items on the website didn't align properly when using mobile view or hamburger menus. The fix adjusts how the menu items are styled, ensuring they align to the right or center based on the user's selection. This improves the overall user experience on mobile devices.

Steps to reproduce:
===================
1- Enter the website editor
2- Enable mobile view
3- Edit the alignment of the mobile menu to be center or right aligned

The group labels (e.g. "Shop", "Forum") stay left-aligned regardless
of the chosen alignment.

This can also be seen on desktop by switching to the sidebar header
template.

Cause:
======
The class .accordion-button uses `display:flex` and `text-align:left`
and that class is used for the menu groups labels.
this prevents the alignment from working.

Solution:
=========
When right-aligned (`text-end`), reverse the flex direction so the arrow
moves to the left and the text stays on the right.

When centered (`text-center`), let the text span fill the remaining
space and center its content via `text-align: center`,
keeping the arrow on its position.

The default left-aligned case is unchanged.

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

Forward-Port-Of: odoo/odoo#244565

This update strengthens Odoo's security by implementing checks for field access within SQL queries. Specifically, the system now verifies that fields used in SQL statements are correctly authorized, reducing potential vulnerabilities. This improves overall data protection and aligns with security best practices.

Methods creating SQL have their field access checked.

- account_accountant: check field access in group by
- documents: `is_folder` should be a field

This update incorporates the required 2033-F document, a crucial component of the French 'Liasse fiscal' reporting process. It also includes a confirmation dialog for the report action, improving user experience and data accuracy. This ensures compliance with French tax regulations.

This commit will add the 2033-F document of the "Liasse fiscal"

task-5417362

This update enhances the spreadsheet edition by replacing 'Cancel' buttons with 'Discard' buttons, providing a more intuitive user experience. Additionally, a new custom component called 'Select' was implemented to improve the visual appearance of dropdown menus within the spreadsheet, aligning with Odoo's design standards.

This pull request introduces a temporary feature within the Sale Stock module to manage rental stock transactions. It provides a basic framework for tracking rental stock, allowing for better control and reporting on rental activities. This is an initial implementation and will be refined in future development.

This update enhances the web_studio interface to allow users to hide search filters within search views, providing a more flexible way to manage search results. Previously, this functionality was missing, and this change improves the user experience by offering a simple 'invisible' option for filters.

It is not always possible to remove a filter from a searchview.
The alternative consists it making it invisible.

However the feature was not exposed in `web_studio`.

This commit exposes a `invisible` checkbox in the same way it was done
for fields; adding a `ModifierProperty` in the `SimpleElementEditor`.
This required to change the `node` parsing logic for the simple editor
which now gets the current node from the `viewEditorModel` directly.

task-5937406

This update aligns the design and behavior of the Documents module's search panel with the standard Odoo search panel. The changes enhance visual clarity and consistency across the Odoo platform, making it easier for users to find documents. This ensures a more unified and intuitive user experience.

Follow the changes made in community do keep consistency with the
search_panel.

task-5367727

Community: https://github.com/odoo/odoo/pull/249868

This update enhances the pay run workflow's user interface for better readability and ease of use. Changes include simplified data labels, adjusted table styles for clearer highlighting, and streamlined resource calendar names across various payroll localizations. These improvements aim to reduce confusion and improve the overall user experience.

Improvements to the pay run workflow UI. Change the table column names, highlight the entire cell instead of changing the text color, shorten the names of resource calendars for localisations. 

Task: 5979729

This update simplifies how tracking data is managed within Odoo, making it easier for developers to add tracking functionality to modules and ensuring consistent tracking behavior across the system. It focuses on reducing manual data manipulation and improving testability, ultimately leading to more reliable tracking information for reporting and analysis.

Main purposes

 * cover various use cases of tracking in addons. Several addons are doing
   manual calls to tracking API: '_mail_track' (generating tracking values),
   '_message_track' (generating valu and a tracking message) or calling
   'message_post' or '_message_log' with tracking values manually generated.
   Logging on a parent model is also a frequen need (e.g. move line change on
   move, esg factor line changes on factor, ...). Those should be covered by
   tests to assess the behavior.
 * update tracking API to remove low-level data manipulation and use simpler
   methods. Addons should not have to manipulate tracking values in any
   form.
 * locate tracking code being currently both generic for BaseModel and specific
   to mail.thread in a middle-ground mixin.

Specifications

Test various use case of tracking, notably when doing manual calls to
_message_track (which generates a tracking message), _mail_track
(which generates tracking values, to be included in a message_post)
or logging a message using either manually crafted tracking values or
a rendered body looking like tracking values.

Update docstring and arguments of tracking API. Add type annotations to
ease understanding of the various structures used in code.

Add a 'mail.track.mixin' mixin that allows to generate tracking values
without depending on 'mail.thread'. It also allows to remove part of the
code that was on BaseModel just for models not inheriting from 'mail.thread'.
Thread now mainly adds the posting capabilities based on tracking.

Update tracking API. Introduce '_track_add' when adding a manual tracking
on some values. Introduce '_track_record' when sending the tracking values
on another model (e.g. a parent for logging purpose).

Fix various crashing code bits discovered when adding tracking tests.
Note that most are going to be backported, hence may disappear from
this PR at merge time. Youpie.

Task-5935695 ([mail, various] Cleanup and test tracking usage)
Prepares Task-3645865 ([mail] In-body tracking)

Co-Authored-By: Prakash Prajapati <ppr@odoo.com>

This update simplifies the process for employees selecting time off by only showing leave types relevant to their company's country. This reduces confusion and ensures users see the appropriate time off options, improving the overall user experience.

In order to prevent the user from facing any difficulties or confusions while selecting the timeoff for their employees, the current flow will display only the leave types that matches the country of the specific company of the user.

Task: 5979706

This update enhances the way remuneration codes are managed within Odoo's payroll system. Previously, codes were hardcoded, but now they are dynamically pulled from the central hr_dmfa module, improving data consistency and reducing potential errors. This change simplifies payroll configuration and maintenance.

[IMP] l10n_be_payroll: remuneration code

The remuneration codes were defined in hr_dmfa statically. I added a new field for this code to salary rules and the code will be pulled from hr_dmfa now without hardcoding.

task - 6036346

This update ensures that product information in the website generator includes the product SKU (or default code), improving data accuracy and clarity. It also streamlines the variant display, allowing users to see newly created variants directly without needing to import them first.

An important change for the products to include the SKU (or default_code in Odoo) to the products.
Also now set the variant setting on so that the user can see the variants created directly without having this confusing in-between where we import variants but they cannot see them.

Forward-Port-Of: odoo/enterprise#111317

This update introduces the ability to generate images using AI through the Media Dialog, leveraging a state-of-the-art model for improved quality and speed. The changes also include bug fixes related to prompt handling and access controls, ensuring a more reliable and secure AI experience.

- Unify API of AI methods: including `_get_direct_response`, `_generate_next_response`, and `_generate_single_response` to accept and return parts. Parts represent a list of dicts where each dict has a type such as 'text' or 'inline_data' and a content dict.

- By returning structured AIMessageParts, the system can now support images alongside text.

- Allow image generation using AI from Media Dialog
  
  - Introduce a tool to allow image generation using Gemini Nano Banana which is the state of the art model for image generation in terms of quality, speed and prompt adherence.

  - Introduce logic inside `ai.attachment.vacuum` to remove unused AI generated images to avoid bloating the DB with large files.

  - Duplicate some code from `ir.binary` into `image_tools` to be able to retrieve attachments from paths that have one of the forms:
    - `/web/image/....` for attachments.
    - `/<module_name>/static/...` for files from addons, for example
    /ai/static/description/icon.png

  - Introduce messages quick action buttons to perform the same save logic of the `MediaDialog` and `CustomMediaDialog` by passing the save method from the media dialog to the `discuss_channel`.

- Fix the following bugs:
  - After https://github.com/odoo/enterprise/commit/2acc1178663d3607e96b64c17ea54f1f5c2e86f3, users have the ability to define prompts for ai.prompt.button records instead of using the name field as the prompt. However, the VoiceTranscription  component wasn't updated to use the new prompt field.

  - The _render_prompt method should return the 'name' of the 'ai.prompt.button' if no 'prompt' is defined or no rendering_record is passed to the method. However, this check didn't take into account that 'prompt' may contain empty HTML, for example `Markup(<p></p>)`.

  - Accessing render_model field on 'ai.prompt.button' records raises AccessError for non-admin users.

  - An error would occur if a public user (or portal) tried to chat with the AI using the live chat.

  - The order of prompt buttons in the discuss channel/transcription component was arbitrary. Now, they are sorted based on their sequence.

  - The composer retrieved by the TranscriptionComponent doesn't take the model of the current record into consideration.

  - Composers should be retrieved based on the interface key and record_model but get_direct_response retrieved composers based on interface key only. While not a bug because the only usage of the endpoint (website_seo_ai composer) will always be opened from the SEO component on the website, the retrieval of composers should be consistent everywhere.

- 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. The code is moved into 'ai_fields_tools.py'.

  - Previously, it was only possible to generate text using AI and AI actions such as 'Log as Note' and 'Send Message' only took text into account. Given that the AI now is capable of generating attachments i.e. images, the actions are updated to take the attachments into account.

task-5153846

This update aligns the net pay field within the payslip summary widget to create a more consistent and user-friendly experience across all views of the system. This change improves the overall presentation of payroll information, ensuring a cleaner and more organized display for users. Task 6055055.

To keep the user experience coherent and across all different views, the net wage field was aligned in the center of its parent widget

Task: 6055055

This update ensures that all data is properly cleared after testing within Odoo. This prevents inconsistencies and ensures that tests are reliable and accurate, leading to more stable releases. It's a key improvement for maintaining data integrity during development.

When testing, make sure all data is flushed properly.

odoo/odoo#196279

This update enhances the Odoo Enterprise Web Studio interface by ensuring the 'reset' button is only displayed when a logo is uploaded. This simplifies the user experience by preventing unnecessary options and focusing on the core functionality. It's a small but important refinement for usability.

SPECIFICATION:

The reset button should only be visible when a logo has been uploaded. If no logo is uploaded, the reset button should remain hidden.

Task-4010875

This update fixes a problem in the demo data for our time off system. Specifically, it ensures that leave allocations start correctly when using future dates (like 2027-01-01) to avoid errors and ensure the system functions properly for real-world 'time off to defer' scenarios.

Issue:
The Anita Oliver contract starts on %Y-01-01, so her leave allocation begins from that date.
When running with faketime set to 2027-01-01, the system attempts to create leave for the previous month, which results in an error stating that there is no allocation for that time off.

Fix:
Update the demo data to create the leave and payslip for the first month of the year. This prevents failures when using faketime and ensures it works correctly for real usage of `time off to defer`.

task-6026690

Forward-Port-Of: odoo/enterprise#111435
Forward-Port-Of: odoo/enterprise#110293

This update resolves an issue where the bulk payments feature would crash if a bank journal wasn't properly connected. A new user message will now appear, guiding users to ensure their bank account is linked before attempting to check the status of a payment batch. This improves the user experience and prevents unexpected errors.

This commit: https://github.com/odoo/enterprise/commit/c9cc89f58f7d98396afac3bdacfeff9b00a02a21
introduce the initiate bulk payments feature. When selecting a batch
you can also check the status of this batch. But for the moment, if you
select a batch that is not connected to a bank, the action will traceback with a
redirect.

This commit will add a user error to warn the user than the journal needs to be
connected to a bank.

task-6009083

Forward-Port-Of: odoo/enterprise#111327
Forward-Port-Of: odoo/enterprise#109956

This update resolves an error that occurred when using the 'hr_expense_stripe' module with unsupported currencies like INR. The module will no longer attempt to create a 'Stripe Issuing' journal, preventing the error and allowing users to access the invoicing dashboard. The fix ensures a stable experience when using specific currency configurations.

Currently, an error occurs when a user opens the invoicing dashboard after activating the `hr_expense_stripe` module for Stripe card issuing with only unsupported currencies active.

Steps to reproduce: (19.0)
- Install `account` module
- Set Company currency to `INR` and deactivate `USD` in currencies.
- Install `hr_expense_stripe`
- Create New company > Set `Country` and `Currency` (eg: India and INR) > 
  Switch to New company > Open `Invoicing` you will get the error.

Steps to reproduce: (saas-19.1)
- Install `account` module
- Set Company currency to `INR` and deactivate `USD` in currencies.
- Install `hr_expense_stripe` > Open `Invoicing` you will get the error.

Traceback:
`ValueError: Expected singleton: res.currency()`

In this [PR], the behavior is such that if `company.stripe_currency_id` is not set, we do not create the "Stripe Issuing".

In 19.0, `@template` was executed after the post-init hook, and we were preventing the creation of the [journal] at that stage. However, when a new company is created, the template data is automatically loaded for companies 
with a matching chart of accounts. As a result, the `stripe_issuing_journal` is created, which leads to the error.

However, in saas-19.1, due to recent improvements in a [commit], the `@template` will now loads data for companies without post init hook. As a result, the `stripe_issuing_journal` is being created, and we are encountering an error.

Solution:
- The`Stripe Issuing` journal will no longer be created on installing the module.
- For existing databases, we will use the company currency as a fallback value to ensure that a valid currency is applied.

[PR]: https://github.com/odoo/enterprise/pull/96271
[journal]: https://github.com/odoo/enterprise/blob/fea009f98885a97439edfea75376b7323c8c9a03/hr_expense_stripe/models/res_company.py#L186-L187
[commit]: https://github.com/odoo/odoo/pull/228950/changes/21fd14ed5e8bdd2cf203d466069437a62a87f2bd

sentry-7284934493

Forward-Port-Of: odoo/enterprise#108436

This update resolves a technical problem related to how Odoo handles data serialization in its localization modules (Arabic, Belgian, and Mexican editions). The fix ensures that data is correctly formatted, preventing potential errors and improving the stability of these important regional versions of Odoo. This change primarily impacts the functionality of these localized modules.

runbot-241772
https://github.com/odoo/odoo/pull/254995

This update ensures that Knowledge articles appear in the standard activity filters (My Activities, Today Activities, and Late Activities) when viewed from the systray. Previously, Knowledge was missing these filters, leading to inconsistent activity views. This change improves user experience and ensures all relevant articles are easily accessible.

Activity redirections from systray apply the default filters My Activities, Today Activities, and Late Activities.

However, Knowledge was missing these filters.

This commit fixes this so that the default activity filters are set in all models in the activity systray.

task-5424661

This update enhances product pricing by now sending unit of measure information (price per unit and quantity) to the system. It also resolves a previous issue where product tag updates weren't automatically triggered by changes to product barcodes or linked products, ensuring accurate pricing and tag synchronization.

If units of measure is configured, we now send
the price per unit and the amount of unit for
the current product.

This commit also fixes an issue where we didn't
call pricer API to update tags if we updated the
tag barcode, or if we updated the product linked
to it.

Task-5129442

This update ensures the topbar menu accurately reflects the menu selected through Odoo's AI Agent. Previously, the topbar didn't update when an AI Agent opened a menu, leading to a disjointed user experience. This fix corrects this behavior, providing a more consistent and intuitive interface for users.

Purpose:
--------
When a menu (view) was opened through an AI Agent, the menu in the topbar was not updated.
This commit fixes this behaviour by setting the menu when the menu's action has been loaded
Task-6017607

Forward-Port-Of: odoo/enterprise#109929

This update corrects a bug in the refund processing for multi-line orders. Previously, the system incorrectly summed line amounts, leading to inaccurate comparisons and potential refund failures due to rounding discrepancies. This change ensures refunds are calculated correctly, preventing order discrepancies and improving financial accuracy.

Before this commit, the some of individual line amounts were being summed to compare against the original order total when processing a refund. This could lead to incorrect comparisons due to rounding issues, resulting in errors when attempting to refund orders with multiple lines.

<img width="626" height="288" alt="image" src="https://github.com/user-attachments/assets/e1bdc126-64d9-4b9a-bd16-2b97ac75e40c" />

opw-5433201

Forward-Port-Of: odoo/enterprise#109124
Forward-Port-Of: odoo/enterprise#105301

This update automatically calculates and transmits the necessary commission payments related to employee compensation for Swiss payroll (ELM). Previously, this calculation was manual, and this change streamlines the process, ensuring accurate and timely reporting to Swiss tax authorities. This improves compliance and reduces the risk of errors.

task-6050810

Forward-Port-Of: odoo/enterprise#111143

This update resolves a bug that prevented invoices with the ICBPER tax code from being processed correctly. The issue stemmed from a technical detail in how the system handles fixed taxes, specifically when splitting them into separate base lines. By setting a configuration flag to false, the system now generates invoices with this tax without errors.

**Steps to reproduce:**
1. Install module `l10n_pe_edi`.
2. Switch company to PE.
3. Create a tax:
   - Name: ICBPER
   - Amount type: Fixed
   - Code: ICBPER
   - Amount: 0.5(e.g.)
   - Set the tax group to ICBPER (In Advance Option)
4. Create a invoice and add a product with ICBPER tax.
5. Post the invoice and click "Process Now" (at header).

**Issue:**
Processing the invoice raises:
    AttributeError: 'dict' object has no attribute '_get_downpayment_lines'

**Cause:**
When `fixed_taxes_as_allowance_charges` is True, `_setup_base_lines()` calls `_turn_emptying_taxes_as_new_base_lines()`, which splits fixed taxes (e.g., ICBPER) into separate base lines.

During this process, `base_line['record']` is no longer the original `account.move.line` record. Instead, it becomes a dictionary containing record under `base_line['record']['record']`.
  - With the flag enabled: `base_line['record']` -> dict `line._get_downpayment_lines()` -> AttributeError
  - With the flag disabled: `base_line['record']` -> `account.move.line``line._get_downpayment_lines()` -> works correctly
 
The Peru EDI implementation directly accesses `base_line['record']` expecting an `account.move.line`. The the nested dict structure causes the crash during file generation.

**Solution:**
Override `_add_invoice_config_vals()` to explicitly set `fixed_taxes_as_allowance_charges = False`
- Add test to ensure invoices with ICBPER fixed taxes generate XML without error

**opw-5809939**

Forward-Port-Of: odoo/enterprise#108638

This update resolves an issue where the payroll module wouldn't function correctly if only the core payroll components were installed. The `l10n_mx_min_wage_zone` field has been moved from a separate module to the main payroll module, ensuring compatibility and proper operation for all users.

The `l10n_mx_min_wage_zone` field is used in `l10n_mx_hr_payroll`, but it was originally defined in `l10n_mx_hr_payroll_account_edi`. This causes errors when a user only installs the `l10n_mx_hr_payroll` module, as the field is missing.

Related commit: 11bb6db4884083b3f48582b749c01ae75a09cf66

target: master
task-6047772

This update fixes an issue with the account reports where messages were displayed on multiple lines, making them difficult to read. Additionally, the VIES check hyperlink was corrected to ensure proper formatting. This improves the user experience and clarity of key account reporting information.

The company data check message was on multiple line.
<img width="555" height="99" alt="image" src="https://github.com/user-attachments/assets/3916a794-57b7-4abb-9e76-0b39e63b8dd6" />

The VIES check hyperlink wasn't Markup.
<img width="685" height="73" alt="image" src="https://github.com/user-attachments/assets/0d05d15e-7155-4435-9738-5e77263f6638" />

This update resolves a test issue caused by simultaneous data synchronization attempts within the Point of Sale Tax module. The fix ensures that backend processes complete before subsequent test steps are executed, preventing errors and improving test reliability. This enhances the overall stability of the Odoo Enterprise system.

In the test test_pos_avatax_flow, two calls are made to get_order_tax_details almost simultaneously, which causes the second call to raise an error due to both call trying to sync the same order at the same time. This commit fixes the test by waiting for the backend calls to be done before proceeding with the test next steps.

runbot-error: 238871, 238872

Forward-Port-Of: odoo/enterprise#110341

This update resolves an issue where the interactive POS tours wouldn't load correctly on databases without demo data, causing a crash. The fix ensures the tours are correctly loaded for the POS environment and prevents errors when steps are missing. This improves the user experience for new POS installations.

With the new interactive tour handling, an issue occurred when loading the POS on a database without demo data.

The tour steps were fetched from the "web_tour.tours" registry, but those tours were only loaded in the "web.assets_backend" bundle, while the tour service can also run in the frontend (POS). As a result, no tour was found in the registry when loading the POS, leading to empty steps. Since no steps were available, the tour tried to access the current action, which was undefined, causing a crash.

To fix this, a guard was added to ensure that steps exist before accessing the current action. If no steps are found, the tour test is put on hold, as it means the tour is not part of the currently loaded bundle and should not run.

Additionally, the "point_of_sale_tour" was improved to execute actions when the POS is loaded, instead of relying only on the backend. This required loading "web_tour.assets_frontend" into the "point_of_sale._assets_pos" bundle.

---

Task: https://www.odoo.com/odoo/project/1737/tasks/6050295

This update corrects a bug where changes to view ordering within the Odoo Studio interface weren't consistently applied. The fix involved updating the system to correctly utilize the `defaultOrderBy` attribute on the related models, ensuring that view order settings are properly saved and reflected.

Bug
===
When changing the order of the views using studio, it wasn't applied.

The reason is that we add a default order at the wrong place in JS, it should be done with the attribute made for that, `defaultOrderBy` on the relational model.

Task-6047024

Forward-Port-Of: odoo/enterprise#111395
Forward-Port-Of: odoo/enterprise#111091

This update streamlines how emojis are loaded and managed within Odoo, making it faster and more reliable. The changes improve performance in testing and reduce the overall memory footprint of the system. This enhancement contributes to a smoother user experience and more efficient test environments.

Feature that is aimed to ease and centralize the loading and management of emoji data.

Follow-up of https://github.com/odoo/odoo/pull/253344 in the same effort to reduce overall memory consumption and increase performance in tests to restore (some) nightly builds.

- Community: https://github.com/odoo/odoo/pull/253078

Forward-Port-Of: odoo/enterprise#110146

This update resolves a technical issue within the Point of Sale (POS) testing process. The previous test was incorrectly simulating order refunds, leading to errors and preventing proper refund processing. This fix ensures the test accurately reflects the backend refund workflow, improving reliability.

The test l10n_pe_edi_pos.RefundWithReasonTour was badly written at some steps. It was paying an order but not waiting it to be fully processed by the backend to try to refund it leading to some information missing and thus some future step failing. This commit is adding the necessary waiting steps.

runbot-error: 237981

Forward-Port-Of: odoo/enterprise#110484

Previously, when users uploaded multiple files to a WhatsApp Discuss channel, only the first file was delivered. This update corrects this issue by preventing the sending of multiple attachments, ensuring all files are successfully transmitted to the recipient. This improves the reliability of WhatsApp communication within Odoo.

Multiple attachments uploaded simultaneously to a WhatsApp Discuss channel result in only the first being delivered to the recipient.

### Steps to reproduce

1. Drag and drop multiple files into a WhatsApp Discuss channel.
2. Send the message.

-> Odoo shows all files, but only the first reaches the destination.

### Cause

WhatsApp's API permits only one media object per message. Odoo's "Composer" enforces this by blocking uploads if an attachment is already present. However, it only evaluates the *current* state; dropping multiple files into an empty composer passes the check because the count is zero. On the server, the WhatsApp backend (constrained by the API) is hardcoded to send only the first attachment, silently discarding the rest.

### Fix

Updated frontend validation to inspect the incoming file list during drop and paste actions. The process is now blocked if the total of existing plus incoming files exceeds one, ensuring the user is notified and preventing silent data loss.

opw-5889035

Forward-Port-Of: odoo/enterprise#111001
Forward-Port-Of: odoo/enterprise#107424

This update resolves an issue where long tax amounts on invoices caused display problems. The fix ensures tax totals are correctly shown, regardless of the number of digits, improving invoice clarity for users. This change impacts the l10n_ke_edi_oscu module.

This commit aims to:
Fix Display issue when the amount is long.

task-5162891

Forward-Port-Of: odoo/enterprise#111003
Forward-Port-Of: odoo/enterprise#100319

This update fixes a visual inconsistency in the accounting reports. Previously, the company header was grayed out only in light mode. Now, it uses a standard muted color, ensuring a consistent and professional appearance across both light and dark modes.

Before this pr:
- The company header in the accounting reports is grayed out in the light mode
  only, not in the dark mode.

Reason:
- Until now, we have been using the hard-coded 'lightgrey' color for the company
  header.

After this pr:
- In this pr, we are changing the color of the company header from
  hard-coded 'lightgrey' color to the standard variable color
  '--AccountReport-muted-data-color' used for muted data in account reports.

Task-5960592

Forward-Port-Of: odoo/enterprise#111509
Forward-Port-Of: odoo/enterprise#110108

This update enhances security within Odoo's spreadsheet modules by ensuring that users only have access to data based on their permissions. The changes align search filters with access controls, preventing unauthorized data viewing. This improves data security and protects sensitive information within spreadsheet applications.

This update resolves an issue where deleting large numbers of contract salary records could lead to incomplete deletions. By implementing a commit/rollback mechanism within the scheduled task, the system now ensures all records are fully processed, preventing data inconsistencies. This improves data integrity and reliability.

The CRON needs savepoints when deleting records to avoid partial deletes from happening when catching ValueError. Instead of savepoints, that are heavy in terms of recources, we can commit/rollback in this cron.

This update removes a redundant template from the Odoo Enterprise website. This cleanup is part of ongoing efforts to optimize the codebase and improve performance. Removing unused components helps streamline the system and reduces potential maintenance overhead.

PR [1] cleaned the enterprise codebase in preparation for OWL3. One of the affected templates (`SubscriptionPricingSelect`) seems to be unused since [2]. This commmit removes it.

[1]: https://github.com/odoo/enterprise/pull/110140
[2]: https://github.com/odoo/enterprise/commit/315be581a4212b46191e0c4f82b02a2c3fde51dc

This update modifies Odoo templates to align with upcoming OWL3 requirements, specifically by adding `.this` to template variables. This change is necessary to correctly target component variables within the Odoo rendering context, ensuring compatibility with the new OWL3 framework. The changes were made manually to ensure proper implementation.

In preparation for OWL3, where template variables will need to use `.this` to target component variables, we add `.this` to template variables that are targetting the component.

Community PR: https://github.com/odoo/odoo/pull/254865
Script PR: odoo/odoo#247965

task: OWL3 prep - add this. to template variables

This update streamlines the calculation and management of Belgian eco vouchers by automating the process through configuration. Previously, manual wizard steps were used; now, rules are defined centrally, improving accuracy and reducing manual effort. This change focuses on a more efficient and automated approach to managing these payments.

The previous eco voucher system wizard manually calculated amounts and set them on property inputs for the salary rule, where the purpose of the wizard was to create even though it is under the reporting sections.

This commit refactors the system to be automated and configuration-driven, while making the wizard's only relevance to the reporting:

- Introduce 'eco_voucher_config' rule parameter to define rules per Joint Committee (JC), including the payment month, maximum annual amount, and optional work-rate tiers (e.g., for CP200).

- Move the proration logic to the salary rule layer via 'hr.payslip._get_eco_vouchers_amount()'. The method evaluates the 12-month reference period, identifies worked days, subtracts invalid days (unpaid leaves), and calculates the final amount according to JC rules.

- Update the 'ECOVOUCHERS' salary rule to automatically trigger when the payslip month matches the configuration, provided no prior eco vouchers were paid in the same reference year. (this may not be needed in the future as the eco vouchers will then only be paid in the relevant month)

- Convert the 'eco_checks' field on 'hr.version' and 'hr.employee' into a computed readonly field to serve as a "Maximum Allowance" indicator based on the current contract's work rate and JC.

task-5421636

This update streamlines the way Odoo calculates task overlaps, resulting in faster and more efficient processing. The change utilizes a direct SQL query and a single calculation function, replacing a more complex internal ORM approach. This improves overall performance and responsiveness for task scheduling.

Use a simple SQL and call `_where_calc` once instead of using internal ORM methods.

This update restores the display of a proxy token within the Odoo Enterprise system, specifically for the l10n_eg_iot module used in Egypt. Previously, this token was hidden to avoid a modal prompt, but it's now reintroduced to ensure proper VAT processing. This change improves functionality for Egyptian users.

Proxy token generation was removed to avoid showing a modal with a token nobody cares about except Egypt. We reintroduce token generation, but display it to the database instead of showing a modal.

see odoo/odoo#255121

This update corrects a visual inconsistency in accounting reports. Previously, the company header was grayed out only in light mode. Now, it uses a standard muted color, ensuring a consistent and professional appearance across both light and dark modes.

Before this pr:
- The company header in the accounting reports is grayed out in the light mode
  only, not in the dark mode.

Reason:
- Until now, we have been using the hard-coded 'lightgrey' color for the company
  header.

After this pr:
- In this pr, we are changing the color of the company header from
  hard-coded 'lightgrey' color to the standard variable color
  '--AccountReport-muted-data-color' used for muted data in account reports.

Task-5960592

Forward-Port-Of: odoo/enterprise#111353
Forward-Port-Of: odoo/enterprise#110108

This update removes the outdated 'short' option from the `format_datetime` and `format_time` functions. This change is necessary for the Odoo 19.0 release as the `short_time_format` and `short_date_format` fields have been deprecated. It ensures consistent date and time formatting across the appointment, data cleaning, planning, and sale-renting modules.

modules: appointment, data_cleaning, planning, sale_renting

From this [commit], the methods `format_datetime` and `format_time` no longer handle `short` because the fields `short_time_format` and `short_date_format` are no longer available in 19.0.

[commit]: https://github.com/odoo/odoo/commit/062b14097033afc19252cf3b8bb1fc541f8c868d#diff-61162ac65633a1c7b054fc83ce1813f1a7984e3169ff36021713ef441f62a208

opw-6030342

This update resolves a technical issue related to how geographic data (specifically topoJSON) is processed within the Enterprise edition's spreadsheet functionality. The fix ensures accurate display of maps and charts generated from spreadsheet data, improving the user experience for business reporting. This change primarily impacts users relying on geographic visualizations within the Enterprise module.

test adaptation
Counterpart of github.com/odoo/odoo/pull/248847

Task-5224009

Forward-Port-Of: odoo/enterprise#107912

This update resolves an issue preventing invoices with the ICBPER tax code from generating correctly. The fix addresses a technical problem related to how the system handles fixed taxes, ensuring invoices with this tax now process without errors. This improves the reliability of invoice generation for Peru customers.

**Steps to reproduce:**
1. Install module `l10n_pe_edi`.
2. Switch company to PE.
3. Create a tax:
   - Name: ICBPER
   - Amount type: Fixed
   - Code: ICBPER
   - Amount: 0.5(e.g.)
   - Set the tax group to ICBPER (In Advance Option)
4. Create a invoice and add a product with ICBPER tax.
5. Post the invoice and click "Process Now" (at header).

**Issue:**
Processing the invoice raises:
    AttributeError: 'dict' object has no attribute '_get_downpayment_lines'

**Cause:**
When `fixed_taxes_as_allowance_charges` is True, `_setup_base_lines()` calls `_turn_emptying_taxes_as_new_base_lines()`, which splits fixed taxes (e.g., ICBPER) into separate base lines.

During this process, `base_line['record']` is no longer the original `account.move.line` record. Instead, it becomes a dictionary containing record under `base_line['record']['record']`.
  - With the flag enabled: `base_line['record']` -> dict `line._get_downpayment_lines()` -> AttributeError
  - With the flag disabled: `base_line['record']` -> `account.move.line``line._get_downpayment_lines()` -> works correctly
 
The Peru EDI implementation directly accesses `base_line['record']` expecting an `account.move.line`. The the nested dict structure causes the crash during file generation.

**Solution:**
Override `_add_invoice_config_vals()` to explicitly set `fixed_taxes_as_allowance_charges = False`
- Add test to ensure invoices with ICBPER fixed taxes generate XML without error

**opw-5809939**

This update fixes an issue where the 281.50 PDF report occasionally generated an extra page with header and footer content. The change optimizes the report layout to ensure it consistently appears on a single page for standard reports, improving readability and reducing unnecessary PDF sizes.

**Behavior:**
Currently when generating the 281.50 report the pdf ends up taking an extra page filled only with header and footer, the page appears when creating the report for a natural person and adding a national number.

The solution is not to fully prevent the report form being more than 1 page long, as some informations could span over more than one line which would make the pdf need an extra page. But to shave a few milimeters so that by default when filled with standard informations the pdf appears cleaner.

**Steps to reproduce:**
- Log to a Belgian company
- Create a contact that is a person
- Add the 281.50 tag to them
- Create a credit note for any positive amount for that person and set the date to the previous year
- Make sure the account used in the credit note has any 281.50 x tag assigned
- Go to Accounting/Reporting/Open 325 forms and create a new form for the year indicated in the credit note
- When generating the 281.50 PDF you'll seee it span over 2 pages if you have filled the national number of the contact

opw-5930339

This update fixes a technical error that occurred when users tried to take a picture without an IoT device connected to a quality control point. The fix prevents a system error and guides users to properly set up the device, ensuring a smoother workflow for quality checks.

Currently, an error occurs when the user clicks the Take Picture button without an IoT box set on the quality control point.

## Steps to replicate:
- Install Quality, Purchase, IoT
- Quality > Quality Control > Control points
- Create a new Control point with
   - Type: Take A Picture
   - Operations: My Company: Receipts
- Create and confirm a purchase order for a test product
- Receipts > Quality Checks > Take A picture

## Observed behavior:
TypeError: Cannot read properties of undefined (reading '0')

## Root cause:
This error occurs because no device has been set on the control point. When the user clicks the **Take a Picture** button, the `onClick` method [1] is triggered. Since `this.iotDevice` is false, both `iotBoxId` and `deviceIdentifier` are undefined.

These undefined values are then passed to the action function [2], which in turn passes them to the `_attemptFallbacks` function. At [3], a type error occurs because the system tries to index `iotBoxId` even though it is undefined.
[1]:
https://github.com/odoo/enterprise/blob/2c2e358695357a730b66480fd99c27d7e922bd0b/quality_iot/static/src/iot_picture_button.js#L7-L17 
[2]:
https://github.com/odoo/enterprise/blob/2c2e358695357a730b66480fd99c27d7e922bd0b/iot/static/src/network_utils/iot_http_service.js#L213-L236 
[3]:
https://github.com/odoo/enterprise/blob/2c2e358695357a730b66480fd99c27d7e922bd0b/iot/static/src/network_utils/iot_http_service.js#L149-L152 
[4]:
https://github.com/odoo/enterprise/blob/1d25675de808521dc8ad8c56bc9fbd320a0ae56b/quality_iot/static/src/iot_measure_button.js#L27-L32

## Solution:
Add a check for an unset device and notify the user to add a device to the quality point. This prevents a traceback and clearly informs the user about the issue. Similar to how it was done in [4]

opw-6010095

This update resolves an issue where the CFDI payment method '99' incorrectly displayed as '99 - False' on reports. The fix ensures that '99 - Por definir' is shown accurately, aligning with Mexican tax regulations. This improves report accuracy for invoices with payment method 99.

**PROBLEM**
PR https://github.com/odoo/enterprise/commit/843d57b25f925a5d4f1848b85717adb4d1a9d388 Archives payment method 99, but because it's archived `_l10n_mx_edi_get_extra_invoice_report_values()` doesn't retrieve it. This leads the pdf report to display '99 - False' instead of '99 - Por definir'.

**STEP TO REPRODUCE**
1. Create an invoice with the mx company.
2. Set the due date sometime in the month later. (To have the PPD payment policy on the invoice).
3. Send and generate the invoice using cfdi.

opw-5927655

Forward-Port-Of: odoo/enterprise#111051
Forward-Port-Of: odoo/enterprise#107267

This update resolves a test issue caused by simultaneous requests for order tax details, which previously triggered errors. The fix ensures that backend processes complete before subsequent test steps are executed, improving the reliability of the POS tax test. This enhances the overall stability of the Odoo Enterprise Point of Sale module.

In the test test_pos_avatax_flow, two calls are made to get_order_tax_details almost simultaneously, which causes the second call to raise an error due to both call trying to sync the same order at the same time. This commit fixes the test by waiting for the backend calls to be done before proceeding with the test next steps.

runbot-error: 238871, 238872

Forward-Port-Of: odoo/enterprise#110341

This commit cleans up the codebase by removing a previously merged module that contained a dead file. This ensures our system remains efficient and free of outdated components. The removal addresses a technical issue identified during the integration process.

Description of the issue this commit addresses:

When Faulty PR¹ was merged, one file was not removed resulting in a dead module staying in the codebase with a single dead file.

¹: [Faulty PR](https://github.com/odoo/enterprise/pull/92769)

---

Desired behavior after this commit is merged:

This commit removes said module and therefore dead files.

---

task-[none](https://github.com/odoo/enterprise/pull/92769#issuecomment-4097703654)

This update resolves an issue where tiny overtime hours (like seconds) were causing incorrect rate calculations on US payslip PDFs. The fix directly calculates the rate from hourly wage and multiplier, mirroring a previous solution for Australia, ensuring accurate overtime pay is displayed. This improves payroll accuracy for employees with very short overtime periods.

The Rate column on the US payslip PDF is computed as amount / hours, but amount is a Monetary field rounded to 2 decimals. For small hour values (e.g. seconds from the attendance app), the rounding error causes us to compute the wrong rate.

For example, working 6 seconds of overtime at an hourly rate of $26 with a 1.5x overtime multiplier results in this calculation:

$26/hour * 1.5 * 0.00166667 hour = $0.065 ≈ $0.06

We then attempted to calculate the rate in reverse for the PDF:

$0.06 / 0.00166667 hour = $35.9999 ≈ $36.00

Because of the rounding that happened, it doesn't show the expected $39/hour rate ($26 * 1.5).

We now compute the rate directly from hourly_wage * multiplier instead, inspired by edc4ed3c21b which did the same for Australia.

task-6052711

This update addresses a security vulnerability where automated email scanners could unintentionally cancel appointments through a simple link. By changing the appointment cancellation link to a POST form, we now require a deliberate user action to cancel, mitigating this risk and improving security.

Mail link scanners often follow GET links in emails to check for malicious content. If the appointment cancelation link is a simple GET link, these scanners can inadvertently cancel the appointment.

This commit converts the link into a POST form to ensure that cancellation requires a deliberate user action and is not triggered by automated scanners.

opw-5722533

A bug was causing updates to Studio Approval Rules to inadvertently delete those rules from the database. This issue, identified during an upgrade, has been fixed by ensuring new records created by the system have a flag to prevent automatic deletion. This prevents data loss and ensures the stability of approval workflows.

Server and automated actions created by the ORM for the purpose of revoking approval rights are created without `noupdate=True` which leads to said records being removed by the ORM becuase of not being found in the source.

Such records created on the fly should have `noupdate=True` to prevent that from happening.

This bug can be reproduced by going to Settings > Technical > User Interface > Studio Approval Rules and creating a new record from there and updating `web_studio`. The update will drop the record from the database.

Issue originally detected in the upgrade process from 18.0 to 19.0.

This fix will be complemented by an upgrade script that fixes erronous records.

This update resolves a bug in Odoo's Web Studio where invisible fields would lose their visibility settings when toggling the 'Show Invisible Elements' option. The fix ensures that invisible field attributes are correctly retained and applied within the studio editor, improving user experience and data consistency.

Steps to reproduce
==================

- Install contacts,web_studio
- Login as admin
- Go to contacts
- Open any record
- Open studio
- Click on any field
- Add the "Role / Portal" group
- Toggle the "Show invisible Elements" checkbox
- Click on the same field

=> The field is marked as invisible

- Add an invisible condition

=> The invisible condition is lost (but still applied on the view)

Cause of the issue
==================

In studio, when fetching the view, the invisible attribute is set to True when the user does not have access to the field (when he is not part of the groups).

The goal is to make the field invisible in studio unless the "Show invisible Elements" is toggled.

But this causes the actual value of the invisible attribute to be lost.

Note that this also applies to the column_invisible attribute.

Solution
========

If an invisible/column_invisible attribute is present on the nodes with missing access, we copy the actual value to the `actual_invisible` attribute.

We then use that value in the editor, when present.

opw-6026971

This update automatically calculates and includes the necessary commission deductions for Swiss payroll reports (ELM) based on employee data. This ensures accurate reporting to tax authorities, addressing a previous reporting issue and improving compliance with Swiss regulations. The change impacts the Swiss payroll module.

Forward-Port-Of: odoo/enterprise#111143

This update automatically calculates and transmits the necessary commission payments for Swiss payroll (ELM) declarations. Previously, this calculation was manual, and this change streamlines the process, ensuring accurate and timely reporting to tax authorities. This improves compliance and reduces the risk of errors related to commission calculations.

task-6050810

This update prevents the entire report cron process from stopping if a single report export fails. Now, the cron will continue to attempt exporting other reports, ensuring timely delivery of all necessary reports. This improves reliability and reduces potential data delays.

If an error is raised during the export of reports cron execution, the whole cron stops due to the fact that the error is never catched This commit will ensure that even if there is an error with one of the report export, the cron won't top and will try to send to other documents

task-5469038