This adds a payment step to appointment booking so customers can be required to pay before their slot is fully confirmed. It helps businesses reduce unpaid bookings, manage appointment capacity more accurately, and send confirmations only after payment when required.

WIP

Task-3079302

This update adds safeguards to discourage point-of-sale modules from directly using the shared POS state inside business data models. It helps reduce future maintenance risk and supports a cleaner, more reliable POS architecture without changing day-to-day user workflows.

*: all pos related modules

The pos_store is a global variable that is used to store the current
state of the POS. Before we were able to access it from the models
directly, but this is not a good practice.

For the moment a patch is added to keep the use of it in differents
places, but in the future we should remove it from the models and
use the pos_store only in the components.

A eslint rule is added to prevent the use of pos_store in the models.

A new debug report helps teams understand why payment methods or providers are available or unavailable in specific payment forms. This improves troubleshooting for payment setup across subscriptions, appointments, SEPA direct debit, and website upsell flows while also standardizing related naming internally.

Since 17.0 payment methods were introduced to the user and it became
more difficult to debug them in the payment form. For that reason with
this commit we added the availability report in payment form that can
be displayed in debug mode. The report includes information about
compatibility of each payment method and each provider for the given
payment context and the reason if it is incompatible.

task-2882668

The cleanup is included in this PR as well. 
- Unified variable name

See related PR:

- https://github.com/odoo/odoo/pull/151040
- https://github.com/odoo/upgrade/pull/5858

Payroll structure types now have a consistent ordering, preventing the system from picking different records in identical situations. This improves reliability in payroll processing and avoids unexpected behavior caused by database ordering differences.

This fixes an issue that was revealed by the change in the record updates.  The root cause is the fact that the order on model `hr.payroll.structure.type` is nondeterministic.  Because the order of row updates is slightly different, `search()` with `limit=1` was returning a different record!

Spreadsheet formula suggestions now use the updated names for pivot functions. This prevents confusion when users type formulas and helps them select the correct pivot-related options.

Pivot functions have been recently renamed by 8f797f954

The auto-complete code was not updated accordingly (it was done in //)

Task: 3823297

Point-of-sale related test files were renamed and reorganized to follow a consistent structure across modules. This internal cleanup makes tests easier for teams to find and maintain, without changing customer-facing behavior.

*: all pos-related modules

1. Use snake_case on file names similar to how we name other files.
2. Tour files are suffixed with `_tour`.
3. Helper files are moved to `/tours/utils` and are suffixed with `_util`.

tasks id : 3794884

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

The issue: In the accounting report, in the process of creating the temporary table analytic_temp_account_move_line, that should match the account_move_line schema, we opt for NULL values, casting them to match the column type to match account_move_line table columns type. Now, if you have a field of any type that is not standard in PSQL (like HTML) in the account.move.line model, the query will try to cast a NULL to this type (which is HTML in this case), therefore will throw a traceback

The issue:
In the accounting report, in the process of creating the temporary table analytic_temp_account_move_line,
that should match the account_move_line schema, we opt for NULL values, casting them to match the column type to match account_move_line table columns type.
Now, if you have a field of any type that is not standard in PSQL (like HTML) in the account.move.line model, the query will try to cast a NULL to this type (which is HTML in this case), therefore will throw a traceback

The fix:
Instead of casting NULL to Odoo type, which is in some cases not a valid type for PSQL (Like HTML type), this PR aims to cast any of these fields to the appropriate PSQL type

opw-3782724

Forward-Port-Of: odoo/enterprise#58617

Before this commit, if setting a condition on a column in studio, it was on the 'column_invisible'. In result, the column was not invisible because it was conditional on the lines. So you cannot make the column dissapear on some line and not other in a list view. After this commit, the property selected when setting a condition is 'invisible'. Like that the cell is invisible and not the column. opw-ticket: 3667210 Forward-Port-Of: odoo/enterprise#58283 Forward-Port-Of: odoo/enterprise#545

Before this commit, if setting a condition on a column in studio, it was on the 'column_invisible'. In result, the column was not invisible because it was conditional on the lines. So you cannot make the column dissapear on some line and not other in a list view.

After this commit, the property selected when setting a condition is 'invisible'. Like that the cell is invisible and not the column.

opw-ticket: 3667210

Forward-Port-Of: odoo/enterprise#58283
Forward-Port-Of: odoo/enterprise#54527

Before this commit, when duplicating a read-only template a traceback was being triggered since we were passing a single template to the copy method. After this commit, we call the copy function passing a batch of a single element, which will return a list of templates containing a single template. After that, we call the action to open this copied template. task-3790206 Forward-Port-Of: odoo/enterprise#59198

Before this commit, when duplicating a read-only template a traceback was being triggered since we were passing a single template to the copy method.

After this commit, we call the copy function passing a batch of a single element, which will return a list of templates containing a single template. After that, we call the action to open this copied template.

task-3790206

Forward-Port-Of: odoo/enterprise#59198

**Steps to reproduce the bug:** - Create a storable product P1 with BoM: - Workorder: OP1 workcenter: Assembly 1 - Create a MO with P1 and confirm it - Go to the shop floor: - Select “Assembly 1” and “Drill 1” - Go to assembly 1 > select the workorder OP1 - on the right side of the footer in as ": (option)" button, which opens a pop-up window with additional options for the work order - click on “Move to workcenter” - Select “Drill 1” **Problem:** Change is

**Steps to reproduce the bug:**
- Create a storable product P1 with BoM:
    - Workorder: OP1 workcenter: Assembly 1

- Create a MO with P1 and confirm it
- Go to the shop floor:
    - Select “Assembly 1” and “Drill 1”
    - Go to assembly 1 > select the workorder OP1
    - on the right side of the footer in as ": (option)" button, which opens a pop-up window with additional options for the work order

   - click on “Move to workcenter”
   - Select “Drill 1”

**Problem:**
Change is applied in the frontend view (JS side) but not in the backend. If you refresh the page, the change will be lost. This is due to this commit:

https://github.com/odoo/odoo/commit/6bd2c1fdfb5722b1f2d4fc2684f20ed067b93b7d The purpose of this commit is to no longer save the record of an x2many when an autosave field is applied to an update

**Solution:**
Revert the changes made in this commit:
https://github.com/odoo/enterprise/commit/518dcd935094e30c8a39982be9b3ddb161bd03cd#diff-7df14ba8355f342f6f776e8ea293eb97ab75660c0f57245f5941e8d1da9a49bbR42-R45

opw-3816964

Forward-Port-Of: odoo/enterprise#59184
Forward-Port-Of: odoo/enterprise#59120

Before this commit on the sign request when leaving the validity field empty and clicking on a different place, the following error occurs: """ .... if self.validity < fields.Date.today(): TypeError: '<' not supported between instances of 'bool' and 'datetime.date' """ This commit aims to fix this issue by adding an additional condition before comparing the validity. Task: 3750526 Forward-Port-Of: odoo/enterprise#57196

Before this commit on the sign request when leaving the validity field empty and clicking on a different place, the following error occurs: """
....

if self.validity < fields.Date.today():
TypeError: '<' not supported between instances of 'bool' and 'datetime.date' """
This commit aims to fix this issue by adding an additional condition before comparing the validity.

Task: 3750526

Forward-Port-Of: odoo/enterprise#57196

Importing large winbooks zip files can sometimes lead to a MemoryError. For instance, importing 360 000 account.moves in one go requires 3.1Gb of allocated memory, too much for a 2gb worker. This commit uses the fact that the get_dbfrecords function returns an iterator. The result_iterator yields all the items that pass the BOOKYEAR and DOCNUMBER condition. Also, yielding a frozendict allows to remove duplicate at the time of building the grouped defaultdict instead of when consuming the dbfr

Importing large winbooks zip files can sometimes lead to a MemoryError. For instance, importing 360 000 account.moves in one go requires 3.1Gb of allocated memory, too much for a 2gb worker.

This commit uses the fact that the get_dbfrecords function returns an iterator. The result_iterator yields all the items that pass the BOOKYEAR and DOCNUMBER condition. Also, yielding a frozendict allows to remove duplicate at the time of building the grouped defaultdict instead of when consuming the dbfrecords iterator. That's because frozendict are hashable. By removing the intermediate recs and result local variables in `_import_move`, the memory peak drops to 1.6Gb, allowing to import the winbooks export on a 2gb worker.

Add a more user-friendly error when there is no sub_zips in the main zip container. This can happen if the customer extracts the winbooks archive and tries to import the sub_zip directly.

#### Benchmark
Customer v17 database importing a 102Mb zip winbooks export containing 357825 moves.

##### Memray stats before PR, peak at 3.1Gb
![memray_winbooks_stable-min](https://github.com/odoo/enterprise/assets/9673274/21e4dc9e-efc1-4809-bfc5-2174c8906943)


##### Memray stats after PR, peak at 1.6Gb

![memray_winbooks_branch-min](https://github.com/odoo/enterprise/assets/9673274/8f427a2d-923e-4d84-9f24-f4ba0d0fcbd6)

Forward-Port-Of: odoo/enterprise#56059

Since [1], it's now possible for a client action to use the resId and update the resId on the URL as a form view will do. To do this two props are given to the client action: resId and updateResId. This commit adds the missing props to existing client actions that were forgotten by the initial commit. [1] https://github.com/odoo/odoo/commit/3ad4fd65387f60b524e5f786556963ead8ae9dfe Forward-Port-Of: odoo/enterprise#59352

Since [1], it's now possible for a client action to use the resId and update the resId on the URL as a form view will do. To do this two props are given to the client action: resId and updateResId.

This commit adds the missing props to existing client actions that were forgotten by the initial commit.

[1] https://github.com/odoo/odoo/commit/3ad4fd65387f60b524e5f786556963ead8ae9dfe

Forward-Port-Of: odoo/enterprise#59352

Steps to reproduce: - Set up DHL shipping - Create Sale order, add dhl shipping and validate the delivery Bug: the shipper and reciver referrence are empty on the created comercial invoice opw-3775347 Forward-Port-Of: odoo/enterprise#59318 Forward-Port-Of: odoo/enterprise#59208

Steps to reproduce:
- Set up DHL shipping
- Create Sale order, add dhl shipping and validate the delivery

Bug:
the shipper and reciver referrence are empty on
the created comercial invoice


opw-3775347

Forward-Port-Of: odoo/enterprise#59318
Forward-Port-Of: odoo/enterprise#59208

Before: Spreadsheet can be renamed to blank spaces. After: If a spreadsheet is renamed to blank spaces, the placeholder value will auto reset back to original name or default untitled name. Task: 3559704 Forward-Port-Of: odoo/enterprise#59145 Forward-Port-Of: odoo/enterprise#51550

Before:
Spreadsheet can be renamed to blank spaces.

After:
If a spreadsheet is renamed to blank spaces, the placeholder value will auto reset back to original name or default untitled name.

Task: 3559704

Forward-Port-Of: odoo/enterprise#59145
Forward-Port-Of: odoo/enterprise#51550

Before: when a CFDI wasn't created successfully, the retry button wasn't shown to force the user to go back to the send & print button to generate the invoice PDF. Now: the retry button is shown and the generation of the PDF is done by manually triggering the send and print process. task-3687266 Forward-Port-Of: odoo/enterprise#54835

Before: when a CFDI wasn't created successfully, the retry button wasn't shown to force the user to go back to the send & print button to generate the invoice PDF.

Now: the retry button is shown and the generation of the PDF is done by manually triggering the send and print process.

task-3687266

Forward-Port-Of: odoo/enterprise#54835

When having an asset beginning at the beginning of a period and having one period, the board values are wrongly computed although the depreciation move lines are good. Steps: - Create an asset with acquisition date set at the first day of a month - Set the period to 1 month - Set the same account as fixed asset account and depreciation account - Compute board and show depreciation moves tab -> Depreciation value, remaining value and cumulated depreciation are wrong The reason is that we en

When having an asset beginning at the beginning of a period
and having one period, the board values are wrongly computed
although the depreciation move lines are good.

Steps:

- Create an asset with acquisition date set at the first day of a month
- Set the period to 1 month
- Set the same account as fixed asset account and depreciation account
- Compute board and show depreciation moves tab
-> Depreciation value, remaining value and cumulated depreciation are
   wrong

The reason is that we enter in a condition meant for set the value of
closing entry when needed, which is not the case here.
As there is no way, at the moment we enter this condition, to check if
the asset is ment to be closed (state is still set to 'open'), the
solution is to add a context key to achieve that.

opw-3750254

Forward-Port-Of: odoo/enterprise#58595

# Issue: Data Cleaning App is slow. # Analyze: - There is no check on model duplication to generate subqueries. - For each domain search, the queries have subqueries joined with "UNION" which are slow and can't be optimized by the Planner. # Fix: - Remove duplicated models which generate the same condition. - Avoid subqueries and make one big query with each one of the subqueries. # Benchmark: | # Input data | Before PR | After PR | |:-------------:|:----------:|:---------:| |

# Issue:
Data Cleaning App is slow.

# Analyze:
- There is no check on model duplication to generate subqueries.
- For each domain search, the queries have subqueries joined with
"UNION" which are slow and can't be optimized by the Planner.

# Fix:
- Remove duplicated models which generate the same condition.
- Avoid subqueries and make one big query with each one of the subqueries.

# Benchmark:
| # Input data | Before PR | After PR |
|:-------------:|:----------:|:---------:|
|  5144  dmr (3 models)                   |      1,91 s          |        0,31 s       |
|  974 931  dmr (3 models)                 |      7:09 min          |        33,86 s ( Hot cache : 5,62s)      |
|  8 804 632  dmr (6 models)                   |      Crash after 5:30 min          |        1:19 min       |

# Note:
- I tried it with the biggest database I could access, I didn't crash but
on big databases with a lot of related model, there would be a bunch of
LEFT JOIN and that could have a Memory Limit. (In any case it wouldn't
work with current implementation)
- The index could help on the planner, but it is not required (while it
  can't hurt to have an index on a Many2One).

# Related task:
opw-3696044

Speedscope in attachment in the task

Forward-Port-Of: odoo/enterprise#56536

Steps to reproduce: - Set up DHL shipping - Create Sale order with a currency different than the company one - Add dhl shipping and validate the delivery Bug: the created comercial invoice is in the company currency instead of the SO Fix: apply same logic as 15.0 set currency to SO and fallback to the company currency if no SO is linked to the delivery opw-3775347 Forward-Port-Of: odoo/enterprise#59177

Steps to reproduce:
- Set up DHL shipping
- Create Sale order with a currency different than the company one
- Add dhl shipping and validate the delivery

Bug:
the created comercial invoice is in the company currency instead of the SO

Fix:
apply same logic as 15.0 set currency to SO and fallback to the company currency if no SO is linked to the delivery

opw-3775347

Forward-Port-Of: odoo/enterprise#59177

Currently, when the user and the target both are in multiple companies, the profile button cannot be displayed correctly. Since the employee_id uses `('company_id', '=', self.env.company.id)` rather than `in`. In community branch we fixed it by checking employee_ids directly and if it is found, the profile button will be displayed correctly. In order to accommodate that change, we needed to filter out employee_ids and add employee_id in fields for patchAvatarCardResourcePopover, as resourc

Currently, when the user and the target both are in multiple companies, the profile button cannot be displayed correctly. Since the employee_id uses `('company_id', '=', self.env.company.id)` rather than `in`.

In community branch we fixed it by checking employee_ids directly and if it is found, the profile button will be displayed correctly.

In order to accommodate that change, we needed to filter out employee_ids and add employee_id in fields for patchAvatarCardResourcePopover, as resource.resource has no field employee_ids.

Forward-Port-Of: odoo/enterprise#59058
Forward-Port-Of: odoo/enterprise#58964

Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10: https://github.com/odoo/odoo/pull/155639

Part 1: https://github.com/odoo/odoo/pull/152930
Part 2: https://github.com/odoo/odoo/pull/153018
Part 3: https://github.com/odoo/odoo/pull/153023
Part 4: https://github.com/odoo/odoo/pull/153203
Part 5: https://github.com/odoo/odoo/pull/153425
Part 6: https://github.com/odoo/odoo/pull/153700
Part 7: https://github.com/odoo/odoo/pull/154054
Part 8: https://github.com/odoo/odoo/pull/154579
Part 9: https://github.com/odoo/odoo/pull/155073
Part 10: https://github.com/odoo/odoo/pull/155639
Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135
Part 12: https://github.com/odoo/odoo/pull/156869

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

This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details.

Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk.

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

Forward-Port-Of: odoo/enterprise#59019