Steps: - Create a partner and it's parent partner and set different salesperson on each. - Login with child partner and add product to cart. - Go to backend and open related quotation. Issue: - Salesperson set on quotation is customer's parent partner's salesperson even though salesperson set on customer. While in backend it first check customer's salesperson and if customer does not have salesperson then it set parent's salesperson. Cause: - In eCommerce we gave parent's salesperson

Steps:
- Create a partner and it's parent partner and set different salesperson on each.
- Login with child partner and add product to cart.
- Go to backend and open related quotation.

Issue:
- Salesperson set on quotation is customer's parent partner's salesperson even though salesperson set on customer. While in backend it first check customer's salesperson and if customer does not have salesperson then it set parent's salesperson.

Cause:
- In eCommerce we gave parent's salesperson first priority then customer's salesperson.

Fix:
- Swap priority to set first customer's salesperson

opw-4757042

Forward-Port-Of: odoo/odoo#209062

Description: --- The action to update Taxes and Accounts when changing the fiscal pos on invoice isn't considering the change in price_unit for lines with price included taxes. Steps to Reproduce: --- 1- Create a 21% tax and another 6% tax, both are included in price 2- Create a fiscal position that will map the 21% tax by the 6% tax 3- Create a product with Price = 121€, and Tax = 21% 4- Create an invoice with this product. 5- On the (Other info) tab, set the Fiscal Position to the o

Description:
---
The action to update Taxes and Accounts when changing the fiscal pos on invoice isn't considering the change in price_unit for lines with price included taxes.

Steps to Reproduce:
---
1- Create a 21% tax and another 6% tax, both are included in price
2- Create a fiscal position that will map the 21% tax by the 6% tax
3- Create a product with Price = 121€, and Tax = 21%
4- Create an invoice with this product.
5- On the (Other info) tab, set the Fiscal Position to the one created (from 21 to 6).
6- Click on update taxes and accounts: 
The price will still be 121 while the taxes will change to 6%, and total = 121.
7- Then if you added a new line with the product now after setting the fiscal pos , you will get
price= 106, tax=6%, total = 106. which are the right values.

Cause:
---
The action created for updating taxes and accounts didn't consider price changes for price included taxes.

Fix:
---
Add call to _compute_price_unit()

opw-4672466

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

Forward-Port-Of: odoo/odoo#208780

Before this PR, the name_search function would perform a search on products by injecting a list of ids in the domain instead of using a subquery. In cases where this list of ids is way too big, the search query becomes extremely slow. This PR uses a subquery instead in the domain to avoid this problem. Benchmarks: |Num. product_ids| Before PR | After PR | |---------------------|---------------|--------------| |28801| 65 s| <1 s| opw-4743566 --- I confirm I have signed the CLA

Before this PR, the name_search function would perform a search on products by injecting a list of ids in the domain instead of using a subquery. In cases where this list of ids is way too big, the search query becomes extremely slow.

This PR uses a subquery instead in the domain to avoid this problem.

Benchmarks:

|Num. product_ids| Before PR | After PR |
|---------------------|---------------|--------------| 
|28801| 65 s| <1 s|

opw-4743566

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

Forward-Port-Of: odoo/odoo#209506
Forward-Port-Of: odoo/odoo#207953

Before this commit, resizing columns in list views when being in right-to-left didn't work as expected: when resizing a column, the column was resized in the opposite direction. This commit makes it work. opw~4782197 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#210290

Before this commit, resizing columns in list views when being in right-to-left didn't work as expected: when resizing a column, the column was resized in the opposite direction. This commit makes it work.

opw~4782197

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#210290

Problem: For a gift card with 0 points which have its price changed a popup error is displayed saying the gift card has already been sold Steps to reproduce: - Install "point_of_sale" app and "pos_loyalty" module - Select "Scan existing cards" in the promotions settings - Generate a gift card with a value of 0.00 $ and copy its code - Start a shop session - Select the gift card product and enter the code - Change the price of the gift card (must be an integer < 10) - Proceed to the pa

Problem:
For a gift card with 0 points which have its price changed a popup error is displayed saying the gift card has already been sold

Steps to reproduce:
- Install "point_of_sale" app and "pos_loyalty" module
- Select "Scan existing cards" in the promotions settings
- Generate a gift card with a value of 0.00 $ and copy its code
- Start a shop session
- Select the gift card product and enter the code
- Change the price of the gift card (must be an integer < 10)
- Proceed to the payment
- See the popup error

Cause:
As the gift card has no points, `couponPointChanges` stays empty. But when the price is modified, `couponPointChanges` is updated but has no giftCardId so the error is triggered (see `validateOrder` in PaymentScreen.js). There is no issue if the price is > 10 or is not an integer because `_updatePrograms` is called after each click on the numpad and `changesPerProgram` gets the values of `couponPointChanges` which are the saved in `oldChanges` which is modified by getting the values of `pointsAdded` which has `giftCardId` so `couponPointChanges` get the `giftCardId`

opw-3909019


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

Forward-Port-Of: odoo/odoo#175086
Forward-Port-Of: odoo/odoo#174538

**[FIX] web_editor, website: prevent snippet tabs nav items removal** Steps to reproduce: 1. Go to Website edit mode. 2. Add a "Tabs" block. 3. Double-click a tab title to select it. 4. Start typing a new title. :white_check_mark: Expected: The tab title is replaced with the new text. :x: Actual: The tab is deleted and merged with the next one. This commit fixes the bug by preventing the deletion of elements with the `data-bs-toggle: 'tab'` attribute. These are clearly not eleme

**[FIX] web_editor, website: prevent snippet tabs nav items removal**

Steps to reproduce:

1. Go to Website edit mode.
2. Add a "Tabs" block.
3. Double-click a tab title to select it.
4. Start typing a new title.

:white_check_mark: Expected: The tab title is replaced with the new text.
:x: Actual: The tab is deleted and merged with the next one.

This commit fixes the bug by preventing the deletion of elements with the `data-bs-toggle: 'tab'` attribute.
These are clearly not elements that an user should ever be allowed to delete.

This commit also adds a test for the "Tab" snippet to prevent the bug from coming back.
It also covers other flows that were previously known to be buggy in the "Tabs" snippet.

opw-4791238

Forward-Port-Of: odoo/odoo#209935

This reverts commit d413a9895742594d064084cd6dafbf1f2ec97221. This fix was decided after https://github.com/odoo/enterprise/pull/74127 that was trying to prevent invoicing users to see accounting features, when it seemed to be unwanted to have the two property accounts fields required while having no CoA installed. The issue is, now when having Accounting installed, we can create a user without having CoA as these two fields are not required anymore, but we end up with a error message when cre

This reverts commit d413a9895742594d064084cd6dafbf1f2ec97221.

This fix was decided after https://github.com/odoo/enterprise/pull/74127
that was trying to prevent invoicing users to see accounting features,
when it seemed to be unwanted to have the two property accounts fields
required while having no CoA installed.

The issue is, now when having Accounting installed, we can create a user
without having CoA as these two fields are not required anymore, but
we end up with a error message when creating an invoice ('no CoA
installed') although we could be have added accounts manually instead
of installing a CoAi (which is not possible for invoicing user).
In this situation, we should be able to create a contact, and having these
fields required will force the user to create them.

Finally, it is ok to revert the full chain, as the original issue is
fixed by this commit https://github.com/odoo/enterprise/commit/68f6c1f9fd3ff6762c98e1a405ade035129efce0

Forward-Port-Of: odoo/odoo#210344
Forward-Port-Of: odoo/odoo#209832

Steps to print the check: 1. Ensure l10n_us_check_printing is installed 2. Set the check layout to Print Check (Middle) - US 3. Create a PO and a bill from it. 4. Create a payment for the bill using checks as your payment method 5. Click Print Check on the payment Current behavior before PR: The checks would print the vendor's name in the stubs, and the date alignment in the (middle) format was overlapping with the check number. Description of the issue/feature this PR addresses: Th

Steps to print the check:
1. Ensure l10n_us_check_printing is installed
2. Set the check layout to Print Check (Middle) - US
3. Create a PO and a bill from it.
4. Create a payment for the bill using checks as your payment method
5. Click Print Check on the payment

Current behavior before PR:
The checks would print the vendor's name in the stubs, and the date alignment in the (middle) format was overlapping with the check number.

Description of the issue/feature this PR addresses:
The checks are aligned with the expected format and conditionally render the correct fields in the document's intended areas.

Desired behavior after PR is merged:
The printed check will now match the format and alignment of the templates used here:
https://checkdepot.net/collections/odoo-checks/products/odoo-checks-top- format. 

Additionally, the check will now avoid printing the issuing company name on the stubs when the manual numbering setting on the bank journal is switched off. This assumes that the checks are preprinted with the company name and check number.

opw-4557006
opw-4738359
Enterprise PR: https://github.com/odoo/enterprise/pull/84644
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#210074
Forward-Port-Of: odoo/odoo#208357

Originally, we compute rules for stock orderpoints based on product_id through `product_id._get_rules_from_location`, however, this function only relies on `product_id.route_ids` or `product_id.categ_id.total_route_ids` which usually don't change a lot per product. This PR leverages this idea that we can simply extend the caching key to include the routes_ids and categ_id.total_route_ids of products so we don't have to calculate the same value twice. For products without route_ids, it simply

Originally, we compute rules for stock orderpoints based on product_id through `product_id._get_rules_from_location`, however, this function only relies on `product_id.route_ids` or
`product_id.categ_id.total_route_ids` which usually don't change a lot per product.

This PR leverages this idea that we can simply extend the caching key to include the routes_ids and categ_id.total_route_ids of products so we don't have to calculate the same value twice. For products without route_ids, it simply falls back to the original cache key.

Benchmarks

|Num. orderpoints| Before PR | After PR |
|---------------------|---------------|--------------|
|5636| 56.2  s| 39.5 s|

opw-4649249


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

Forward-Port-Of: odoo/odoo#202365

Versions -------- - 17.0+ Steps ----- 1. Have a company partner with a credit limit; 2. add an employee partner to the company; 3. create a sales order for the employee; 4. have the total amount exceed the credit limit; 5. confirm order; 6. create a copy. Issue ----- The credit warning isn't updated with the new order's amount. Cause ----- The `credit` field gets computed on the `commercial_partner_id` while `credit_to_invoice` gets computed on the current partner. Solut

Versions
--------
- 17.0+

Steps
-----
1. Have a company partner with a credit limit;
2. add an employee partner to the company;
3. create a sales order for the employee;
4. have the total amount exceed the credit limit;
5. confirm order;
6. create a copy.

Issue
-----
The credit warning isn't updated with the new order's amount.

Cause
-----
The `credit` field gets computed on the `commercial_partner_id` while `credit_to_invoice` gets computed on the current partner.

Solution
--------
Compute the `credit_to_invoice` on the `commercial_partner_id`.

Also, search sales orders on `partner_invoice_id` instead of `partner_id` to compute `credit_to_invoice`.

opw-4654476

Forward-Port-Of: odoo/odoo#210177

This reverts commit 7ce1ba9f29f9b1edd5f2507492e45ef92d9ba868. Before the commit (1) We would iterate through the possible items and see if the partner has the field. As the partner in the test setup does not have `company_registry`, it will iterate on the second value, `vat`, which is set on the partner https://github.com/odoo/odoo/blob/037fabd81efc28c12359700ee8e21e0454e0535e/addons/l10n_dk/models/res_partner.py#L7-L18 which will be the key `0198` For this key, we have mocked the respons

This reverts commit 7ce1ba9f29f9b1edd5f2507492e45ef92d9ba868.

Before the commit (1)
We would iterate through the possible items and see if the partner has the field. As the partner in the test setup does not have `company_registry`, it will iterate on the second value, `vat`, which is set on the partner https://github.com/odoo/odoo/blob/037fabd81efc28c12359700ee8e21e0454e0535e/addons/l10n_dk/models/res_partner.py#L7-L18 which will be the key `0198`

For this key, we have mocked the response:
https://github.com/odoo/odoo/blob/e62a86939b0b327e2c16a82b0829dac80ef1ff32/addons/account_peppol/tests/test_peppol_messages.py#L153-L155

After the commit (1), we stop at the first iteration since `vat` is defined on the partner's fields. The key is `0184` -> we don't have any mocked response for this key, we we wazt to load the response's body which does not exist -> kaboom

I'm not sure that we wanted to change this value in the first place as from Julien, we wanted the company registry https://github.com/odoo/odoo/commit/ad37ebefb9fb7cb3c9593730f174dd6f1d73a31e https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/DK-R-014/

+ the company registry == the vat for the danish localisation https://github.com/odoo/odoo/blob/037fabd81efc28c12359700ee8e21e0454e0535e/addons/l10n_dk/models/res_partner.py#L7-L18

---
commit (1) https://github.com/odoo/odoo/commit/7ce1ba9f29f9

runbot-163142

Forward-Port-Of: odoo/odoo#209498

Scheduling a custom activity plan on a single record should do a `soft_reload` of the current view in order to avoid breadcrumbs pollution. The most frequent use case for that action is scheduling a plan from the chatter of the form view of a record, and retriggering an unnamed default form act_window would only restrict possible operations for the user. After this commit, the current view will be reloaded and the user will most probably be able to see its enabled plan in the chatter. t

Scheduling a custom activity plan on a single record should do a `soft_reload` of the current view in order to avoid breadcrumbs pollution.

The most frequent use case for that action is scheduling a plan from the chatter of the form view of a record, and retriggering an unnamed default form act_window would only restrict possible operations for the user.

After this commit, the current view will be reloaded and the user will most probably be able to see its enabled plan in the chatter.

task-4525830

Forward-Port-Of: odoo/odoo#210168

1. Install `l10n_it_stock_ddt` (Accounting, Sales, Italian localization, Italian delivery slip) 2. Create an invoice with one or more products 3. Set the quantity on the order lines to a relatively high value, like 200 4. Set the unit price to include decimal values so that rounding becomes relevant 5. Confirm the invoice. 6. Click on the delivery smart button. 7. Click on Validate > Print. The total for each product line and the overall total should be correctly calculated as the unit

1. Install `l10n_it_stock_ddt` (Accounting, Sales, Italian localization, Italian delivery slip)
2. Create an invoice with one or more products
3. Set the quantity on the order lines to a relatively high value, like 200
4. Set the unit price to include decimal values so that rounding becomes relevant
5. Confirm the invoice.
6. Click on the delivery smart button.
7. Click on Validate > Print.

The total for each product line and the overall total should be correctly calculated as the unit price multiplied by the quantity, then the tax must be added.

Doing this in incorrect order, can result in discrepancies per unit due to the rounding being done before applying the tax, and that becomes significant when a large number of items is sold.

Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4666634)
opw-4666634

Forward-Port-Of: odoo/odoo#204531

The `subscribe to known partner presences` test ensures that a bus subscription is sent when discovering a new partner whose presence needs tracking. However, the test triggers a channel join, which itself causes a bus subscription. Since both `add_channel` and `force_update_channels` are debounced, the outcome depends on which one executes first. As a result, `force_update_channels` may or may not include the newly added channel, making the test non-deterministic. In practice, this doesn'

The `subscribe to known partner presences` test ensures that a bus subscription is sent when discovering a new partner whose presence needs tracking. However, the test triggers a channel join, which itself causes a bus subscription.

Since both `add_channel` and `force_update_channels` are debounced, the outcome depends on which one executes first. As a result, `force_update_channels` may or may not include the newly added channel, making the test non-deterministic.

In practice, this doesn't matter: if `force_update_channels` omits the new channel, `add_channel` will later update the subscription as needed.

This commit resolves the issue by ignoring `force_update_channels` in the test, since it's irrelevant in this context.

fixes runbot-161223,182043,182044

Forward-Port-Of: odoo/odoo#210534

Versions -------- - 17.0+ Steps ----- 1. Create a coupon that grants a discount; 2. add a second reward giving free products; 3. use a product tag to turn it into a multiproduct reward; 4. save program, generate coupons, and copy a code; 5. add the free product tag to two or more products; 6. go to eCommerce; 7. add any product to cart and go to checkout; 8. apply coupon code; 9. claim a reward. Issue ----- - Claiming a free product results in a traceback. - Claiming the dis

Versions
--------
- 17.0+

Steps
-----
1. Create a coupon that grants a discount;
2. add a second reward giving free products;
3. use a product tag to turn it into a multiproduct reward;
4. save program, generate coupons, and copy a code;
5. add the free product tag to two or more products;
6. go to eCommerce;
7. add any product to cart and go to checkout;
8. apply coupon code;
9. claim a reward.

Issue
-----
- Claiming a free product results in a traceback.
- Claiming the discount does not apply the discount.

Cause
-----
Commit db3ffae3ef5a5 modified the reward claiming logic to allow for multiproduct rewards, but overlooked the possibility of the program having multiple rewards, multiproduct being one of them.

It therefore passes all of the coupon's rewards to `_apply_reward`, which only expects a single reward.

This is also a consequence of commit 6525d5fba40c, which moved part of the `claim_reward` logic to `pricelist`, without passing which reward was claimed to `pricelist`.

Solution
--------
Add an optional `reward_id` parameter to `pricelist`, letting it know which reward we intend to claim.

opw-4778945

Forward-Port-Of: odoo/odoo#209610

This commit adds translations for Luxembourg VAT report in the official languages of Luxembourg. The translation is added for languages Luxembourgish, German, and French. task-4717339 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208673

This commit adds translations for Luxembourg VAT report in the official languages of Luxembourg. The translation is added for languages Luxembourgish, German, and French.

task-4717339




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

Forward-Port-Of: odoo/odoo#208673

When you settle a sale order that has a payment term, it was always ignored in the PoS. But it should only be ignored when the payment term has an early discount. Steps to reproduce: ------------------- * Create a sale order with a payment term that has no early discount * Go to the PoS and settle the sale order * Invoice and validate the order > Observation: In the backend, the sale order has the payment term applied on the invoice Why the fix: ------------ Some modules needs

When you settle a sale order that has a payment term, it was always
ignored in the PoS. But it should only be ignored when the payment term
has an early discount.

Steps to reproduce:
-------------------
* Create a sale order with a payment term that has no early discount
* Go to the PoS and settle the sale order
* Invoice and validate the order
> Observation: In the backend, the sale order has the payment term
  applied on the invoice

Why the fix:
------------
Some modules needs the invoice to have payment terms set
(l10n_mx for example). But the PoS invoice was always ignoring it. We
should only ignore it if the payment terms has an early discount.

opw-4670234

Forward-Port-Of: odoo/odoo#207231

Abandoned cart emails would send twice because the email values for the abandoned cart template would include the partner on the record already, but we were also including the partner email in the email values. Adjusted the email values to be empty when there is already a recipient found on the template. opw-4684534 Forward-Port-Of: odoo/odoo#206158

Abandoned cart emails would send twice because the email values for the abandoned cart template would include the partner on the record already, but we were also including the partner email in the email values.

Adjusted the email values to be empty when there is already a recipient found on the template.

opw-4684534

Forward-Port-Of: odoo/odoo#206158

In the Italian balance sheet, the section for “d-bis. Other enterprises” is not added to the calculation for the section “1. Holdings in:”. As a result, it is not included in the calculation for assets in the balance sheet. This commit adds the section “d-bis. Other enterprises” to the calculation of “1. Holdings in”. This specification is based on Article 2424(1) of the Italian Civil Code: https://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:regio.decreto:1942-03-16;262 Steps to Repro

In the Italian balance sheet, the section for “d-bis. Other enterprises” is not added to the calculation for the section “1. Holdings in:”. As a result, it is not included in the calculation for assets in the balance sheet.

This commit adds the section “d-bis. Other enterprises” to the calculation of “1. Holdings in”.

This specification is based on Article 2424(1) of the Italian Civil Code:
https://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:regio.decreto:1942-03-16;262

Steps to Reproduce on Runbot:

1. Install l10n_it_reports
2. Create an account starting with 1306
3. Create a journal entry using account 1306 as the debit line and balance it with a credit line
4. Check the Italian balance sheet and notice that “d-bis. Other enterprises” is not included in the calculation for assets in the Italian balance sheet

Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4763868)
opw-4763868

Forward-Port-Of: odoo/enterprise#84586

After ELM Certification, monthly summary was not properly adapted for the two available aggregation modes Forward-Port-Of: odoo/enterprise#85287

After ELM Certification, monthly summary was not properly adapted for the two available aggregation modes

Forward-Port-Of: odoo/enterprise#85287

Steps to reproduce: - Open Follow-up levels for 15 days -Check the option for “Automatic” - Go to the email template set in the “Content Template” and set a test email in the CC of the email configuration. - Open the follow up reports for a sample customer who is in the “15 days” stage and change the next reminder date to be a day before today. The reminder must be set to automatic. - There will appear a red ribbon on the right corner that says “In need of action” - In another tab, open sch

Steps to reproduce:
- Open Follow-up levels for 15 days -Check the option for “Automatic”
- Go to the email template set in the “Content Template” and set a test email in the CC of the email configuration.
- Open the follow up reports for a sample customer who is in the “15 days” stage and change the next reminder date to be a day before today. The reminder must be set to automatic.
- There will appear a red ribbon on the right corner that says “In need of action”
- In another tab, open scheduled actions and Open the action “Account Report Followup; Execute followup”
- Run this action manually

Issue:
Go to the previous tab and notice that the email is only sent out to the customer partner record and not the cc email address

Note:
This issue only occurs if the automatic followup is set. If we try to manually followup by clicking on the “Follow Up” button on the customer report, the email is sent correctly to both addresses.

Cause:
When running the cron, the recipients aren't in the options

Solution:
Add an helper to find all necessary recipients from the template if no recipient ids in the options

opw-4527398

Forward-Port-Of: odoo/enterprise#83944

Steps to print the check: 1. Ensure l10n_us_check_printing is installed 2. Set the check layout to Print Check (Middle) - US in the settings 3. Create a PO and a bill from it. 4. Create a payment for the bill using checks as your payment method 5. Click Print Check on the payment The printed check will now match the format and alignment of the templates used [here](https://checkdepot.net/collections/odoo-checks?_pos=1&_psq=odoo&_ss=e&_v=1.0). Additionally, the check will now avoid printi

Steps to print the check:
1. Ensure l10n_us_check_printing is installed
2. Set the check layout to Print Check (Middle) - US in the settings
3. Create a PO and a bill from it.
4. Create a payment for the bill using checks as your payment method
5. Click Print Check on the payment

The printed check will now match the format and alignment of the templates used [here](https://checkdepot.net/collections/odoo-checks?_pos=1&_psq=odoo&_ss=e&_v=1.0). Additionally, the check will now avoid printing the issuing company name on the stubs when the manual numbering setting on the bank journal is switched off. This assumes that the checks are preprinted with the company name and check number.
Before the fix, the checks printed the vendor's name in the stubs, and the date alignment in the (middle) format overlapped with the check number.

After the fix, the checks are aligned with the expected format and conditionally render the correct fields in the document's intended areas.

opw-4557006
opw-4738359
odoo PR: https://github.com/odoo/odoo/pull/208357

Forward-Port-Of: odoo/enterprise#85578
Forward-Port-Of: odoo/enterprise#84644

This reverts commit e4111ac8f817f97b3d6128453659a1014b6db00f. This fix was decided after https://github.com/odoo/enterprise/pull/74127 that was trying to prevent invoicing users to see accounting features, when it seemed to be unwanted to have the two property accounts fields required while having no CoA installed. The issue is, now when having Accounting installed, we can create a user without having CoA as these two fields are not required anymore, but we end up with a error message when cre

This reverts commit e4111ac8f817f97b3d6128453659a1014b6db00f.

This fix was decided after https://github.com/odoo/enterprise/pull/74127
that was trying to prevent invoicing users to see accounting features,
when it seemed to be unwanted to have the two property accounts fields
required while having no CoA installed.

The issue is, now when having Accounting installed, we can create a user
without having CoA as these two fields are not required anymore, but
we end up with a error message when creating an invoice ('no CoA
installed') although we could be have added accounts manually instead
of installing a CoAi (which is not possible for invoicing user).
In this situation, we should be able to create a contact, and having these
fields required will force the user to create them.

Finally, it is ok to revert the full chain, as the original issue is
fixed by this commit https://github.com/odoo/enterprise/commit/68f6c1f9fd3ff6762c98e1a405ade035129efce0

Forward-Port-Of: odoo/enterprise#85736
Forward-Port-Of: odoo/enterprise#85446

In this commit: https://github.com/odoo/enterprise/pull/84728/commits/d3b3de47ca3f174e97eb598187b32e31077a2ddb since the transaction details field was in fact a string in version lower than 18.2 the get would traceback no task id Forward-Port-Of: odoo/enterprise#85848

In this commit: https://github.com/odoo/enterprise/pull/84728/commits/d3b3de47ca3f174e97eb598187b32e31077a2ddb since the transaction details field was in fact a string in version lower than 18.2 the get would traceback

no task id

Forward-Port-Of: odoo/enterprise#85848

Currently, entering only spaces in the Full Name field when signing in auto mode enables the sign button, allowing users to proceed without a valid name. Steps to reproduce: 1. Sign > Create a request 2. Attempt to sign in auto mode with only spaces in the Full Name field 3. Observe that the sign button becomes enabled Cause: The system does not checks for whitespace-only name Solution: Add a validation to disable the sign button if the trimmed name is empty in auto mode. opw-462

Currently, entering only spaces in the Full Name field when signing in auto mode enables the sign button, allowing users to proceed without a valid name.

Steps to reproduce:
1. Sign > Create a request
2. Attempt to sign in auto mode with only spaces in the Full Name field
3. Observe that the sign button becomes enabled

Cause:
The system does not checks for whitespace-only name 
Solution:
Add a validation to disable the sign button if the trimmed name is empty in auto mode.

opw-4628577

Forward-Port-Of: odoo/enterprise#84613

Currently you are able to select the button to settle customer account/ deposit money even though the config does not have access to a paylater payment method. This will never settle the customer account. Steps to reproduce: ------------------- * Remove the customer account payment method from the config * Open the pos session * Find a customer that has an amount due * Select "Settle due accounts" * Process > Observation: The customer account is never settled. Why the fix: --------

Currently you are able to select the button to settle customer account/ deposit money even though the config does not have access to a paylater payment method. This will never settle the customer account.

Steps to reproduce:
-------------------
* Remove the customer account payment method from the config
* Open the pos session
* Find a customer that has an amount due
* Select "Settle due accounts"
* Process
> Observation: The customer account is never settled.

Why the fix:
------------
If there is no payment method of type "pay_later" we should not show the button whose purpose is to use such payment method.

opw-4488571

Forward-Port-Of: odoo/enterprise#83995