The follow-up trust widget now receives the missing information it needs to load correctly. This prevents a client-side error that could appear in debug mode, improving reliability for users working with account follow-ups.

The trust widget was missing a prop causing a client stacktrace when in debug mode.

It appears in saas-17.2 due to https://github.com/odoo/enterprise/commit/47434fba1acd9b7bcc0a4eb74f6b2dc4454f0068

opw-4058127

The aim of this commit is reverting a part of this commit [1]. We have to do that because by removing the call to consent expiring date after the sucess, users don't receive the new consent date directly. Users have to wait until the next call to the refresh token and this call is made every 24h so users have the feeling that the consent wasn't updated. In one case, we don't have the consent expiring date provided by the TPP directly. For that case, we keep the call after the renew token. [1

The aim of this commit is reverting a part of this commit [1]. We have to do that because by removing the call to consent expiring date after the sucess, users don't receive the new consent date directly. Users have to wait until the next call to the refresh token and this call is made every 24h so users have the feeling that the consent wasn't updated.
In one case, we don't have the consent expiring date provided by the TPP directly. For that case, we keep the call after the renew token.

[1]: https://github.com/odoo/enterprise/commit/25ec0ba479372126f84fd1ece6f34aea7b1eb829

Forward-Port-Of: odoo/enterprise#65408

…bill Forward-Port-Of: odoo/enterprise#66846

…bill

Forward-Port-Of: odoo/enterprise#66846

Problem --- When a stock picking is clicked from the barcode view, its responsible is always automatically assigned to the current user. Fix --- assign current user only if they change anything (validate, edit a line, etc) but not if they just look. opw-3878484 Forward-Port-Of: odoo/enterprise#61456

Problem
---
When a stock picking is clicked from the barcode view,
its responsible is always automatically assigned to the current user.

Fix
---
assign current user only if they change anything (validate, edit a line,
etc) but not if they just look.

opw-3878484

Forward-Port-Of: odoo/enterprise#61456

**Steps to reproduce:** - Install Accounting, Sales, l10n_mx_edi - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Create a SO: * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA) * Order Lines: Product | Quantity | Unit Price | Taxes ---------------|----------------|----------------|---------- Product A | 1.00 | 1000.00 | 16% Product B | 1.00 | 1500.00 | 16% Product C | 1.00 |

**Steps to reproduce:**
- Install Accounting, Sales, l10n_mx_edi
- Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE)
- Create a SO:
  * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA)
  * Order Lines:

       Product   |   Quantity   |   Unit Price   |   Taxes
    ---------------|----------------|----------------|----------
      Product A  |     1.00     |     1000.00    |    16%
      Product B  |     1.00     |     1500.00    |    16%
      Product C  |     1.00     |     3000.00    |    16%

- Confirm the SO
- Create a 90% down payment
- Confirm down payment and generate CFDI via "Send & Print" button
- Create a regular invoice for the remaining amount
- Confirm the invoice and generate CFDI

**Issue:**
The verification of the CDFI fails because there is one line with a negative base amount.

**Cause:**
The down payment line has a negative amount.
This negative amount is dispatched between the other lines and the "base" and "importe" values of these other lines are recomputed depending on the amount that is deducted from it.
However, the computation is based on a ratio computed from the price subtotal of the negative line, but the ratio is then applied to the remaining "base" amount of the negative line, which decreases for each deducted line.
This generates incorrect values in "transferred_values_list" field for the the second line and the following ones on which some amount is dispatched.
The issue only happens on the last line on which some amount has been dispatched because it receives the remaining amount that is too high due to the values deducted by the other lines being lower than what it should has been.

**Solution:**
The ratio should be computed from the remaining "base" amount of the negative line.

opw-4033979

Forward-Port-Of: odoo/enterprise#66715

Steps to reproduce: - Install "Field Service" - Open a random task - Click on "Navigate To" Issues: The link is constructed using the coordinates, however Google will convert those coordinates back to an address which will cause a potential discrepancy between the two. opw-4004846 Forward-Port-Of: odoo/enterprise#66691 Forward-Port-Of: odoo/enterprise#65893

Steps to reproduce:
- Install "Field Service"
- Open a random task
- Click on "Navigate To"

Issues:
The link is constructed using the coordinates, however Google will convert those coordinates back to an address which will cause a potential discrepancy between the two.

opw-4004846

Forward-Port-Of: odoo/enterprise#66691
Forward-Port-Of: odoo/enterprise#65893

This commit changes the user for the test `:TestWKnowledgeSecurity.test_models_as_user` which should test ACLs for internal users. Initially it used `portal_user`, which is not internal but portal. It is now replaced by `employee`. We also update the values for asserts on stages as the number of accessible articles for `employee` is different. This user has access to more articles which may contain stages. task-4059967 Forward-Port-Of: odoo/enterprise#66869

This commit changes the user for the test
`:TestWKnowledgeSecurity.test_models_as_user` which should test ACLs for internal users.
Initially it used `portal_user`, which is not internal but portal. It is now replaced by `employee`.

We also update the values for asserts on stages as the number of accessible
articles for `employee` is different.
This user has access to more articles which may contain stages.

task-4059967

Forward-Port-Of: odoo/enterprise#66869

Issue: -------------------- When you open a sign template you can see there are double scroll bars on the iframe Cause: ---------------------- The sign item toolbar placed on the left side is given 100% height and 1px border which is causing the iframe body to overflow Solution: ----------------------------- The 100% height given to the toolbar is changed with -webkit-fill-available task-4014519 Forward-Port-Of: odoo/enterprise#65609

Issue:
--------------------
When you open a sign template you can see there are double scroll bars on the iframe

Cause:
----------------------
The sign item toolbar placed on the left side is given 100% height and  1px border which is causing the iframe body to overflow

Solution:
-----------------------------
The 100% height given to the toolbar is changed with -webkit-fill-available

task-4014519

Forward-Port-Of: odoo/enterprise#65609

The accounting date is used as acquisition date instead of bill date. Steps: 2 flows leads to the bug: 1) - Create and confirm a bill with different accoutning and bill dates - Open a new asset form and click on "select related purchases" button - Select the bill -> The acquisition is set as the accounting date instead of the bill date 2) - Set the expense account to create an asset - Create and confirm a bill with line using the expense account - An asset should be

The accounting date is used as acquisition date instead of
bill date.

Steps:

2 flows leads to the bug:

1) - Create and confirm a bill with different accoutning and bill dates
   - Open a new asset form and click on "select related purchases"
     button
   - Select the bill
   -> The acquisition is set as the accounting date instead of the bill
      date

2) - Set the expense account to create an asset
   - Create and confirm a bill with line using the expense account
   - An asset should be created, open it
   -> Same as before

Cause:

In the `_compute_acquisition_date`, we use the field `date` from
`account.move.line` which is a related field to the `date` field of
`account_move`

Fix:

In the compute, we get the `invoice_date` field from the related move
of each `original_move_line_ids` then fallback to `date` if it is not
set (case of journal entries)

opw-4000259

Forward-Port-Of: odoo/enterprise#66921
Forward-Port-Of: odoo/enterprise#65769

When you select a city from the city list (city_id field) on the res.partner the cities are filtered by country in standard. However this is complicated to use because more often than not there are many cities with the same name. This is specially frequent in large countries. So simply changing it to domain="[('state_id', '=', state_id)]" solves the issue. task: 4027290 Forward-Port-Of: odoo/enterprise#66582 Forward-Port-Of: odoo/enterprise#66495

When you select a city from the city list (city_id field) on the res.partner the cities are filtered by country in standard. However this is complicated to use because more often than not there are many cities with the same name. This is specially frequent in large countries.
So simply changing it to domain="[('state_id', '=', state_id)]" solves the issue.

task: 4027290

Forward-Port-Of: odoo/enterprise#66582
Forward-Port-Of: odoo/enterprise#66495

Before this commit, when clicking on the action with the hierarchy enabled, the parent line were not unfolded which cause the purpose of the action to be useless. task-3839845 Forward-Port-Of: odoo/enterprise#66531 Forward-Port-Of: odoo/enterprise#63965

Before this commit, when clicking on the action with the hierarchy enabled, the parent line were not unfolded which cause the purpose of the action to be useless.

task-3839845

Forward-Port-Of: odoo/enterprise#66531
Forward-Port-Of: odoo/enterprise#63965

Saskatchewan tax report was missing a line for `Total before Sales` opw-3955926 Forward-Port-Of: odoo/odoo#171033

Saskatchewan tax report was missing a line for
`Total before Sales`

opw-3955926

Forward-Port-Of: odoo/odoo#171033

Description of the issue/feature this PR addresses: [CLA] add corporate samadeva.md to contribute as developper Current behavior before PR: Desired behavior after PR is merged: --- v I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173597

Description of the issue/feature this PR addresses:

[CLA] add corporate samadeva.md to contribute as developper

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#173597

Forward-Port-Of: odoo/odoo#173617

Forward-Port-Of: odoo/odoo#173617

Steps to reproduce: 1) Install and enable wire transfer. 2) Disable and enable it again. 3) Go to the payment form and see that wire transfer is not in the list of available payment methods. Reason: No default payment method codes were defined to activate with the provider. opw-4042165 Forward-Port-Of: odoo/odoo#173637

Steps to reproduce:
1) Install and enable wire transfer.
2) Disable and enable it again.
3) Go to the payment form and see that wire transfer is not in the list of available payment methods.

Reason:
No default payment method codes were defined to activate with the provider.

opw-4042165

Forward-Port-Of: odoo/odoo#173637

Introduced in 5f4add917a55f62c024a7a79c9240dc628a9f14f, we allowed filtering on 'done' activities. This induced a change in the search method of activity_user_id field, now readonly, to allow searching on done activities. As user_id is required on mail.activity, we can do as we do for the activity_date_dateline search method (date_dateline being required too on mail.activity): when using 'is not set' as a custom domain (~ '= False'), return records having no activities, and therefore no activ

Introduced in 5f4add917a55f62c024a7a79c9240dc628a9f14f, we allowed filtering on 'done' activities. This induced a change in the search method of activity_user_id field, now readonly, to allow searching on done activities.

As user_id is required on mail.activity, we can do as we do for the activity_date_dateline search method (date_dateline being required too on mail.activity): when using 'is not set' as a custom domain (~ '= False'), return records having no activities, and therefore no activity_user_id.

A small test is added in test_mail

Task-4027928

Forward-Port-Of: odoo/odoo#172082

Steps to reproduce: - Add a product to your cart (not a service) - Try to pay with express checkout with payment_demo - Validation Error:No shipping method is selected. After this PR the first available shipping method will be assigned to the order when payment with demo express checkout. opw-4010925 Forward-Port-Of: odoo/odoo#173297 Forward-Port-Of: odoo/odoo#171180

Steps to reproduce:
- Add a product to your cart (not a service)
- Try to pay with express checkout with payment_demo
- Validation Error:No shipping method is selected.

After this PR the first available shipping method will be assigned to the order when payment with demo express checkout.

opw-4010925

Forward-Port-Of: odoo/odoo#173297
Forward-Port-Of: odoo/odoo#171180

In the list view of the Chart of Accounts, the only available tags in the field Tags are the ones applicable to Accounts. In the list view of journal items, the only available tags in the field Tax Grids are the ones applicable to Taxes. task-4016899 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173686 Forward-Port-Of: odoo/odoo#173138

In the list view of the Chart of Accounts, the only available tags in the field Tags are the ones applicable to Accounts.
In the list view of journal items, the only available tags in the field Tax Grids are the ones applicable to Taxes.

task-4016899

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

Forward-Port-Of: odoo/odoo#173686
Forward-Port-Of: odoo/odoo#173138

Since https://github.com/odoo/odoo/issues/113974, Properties fields can contain separator (virtual `<group>`) information inside its value. But in the view list, these separator can be selected in the optional fields. It doesn't make sense because there no value associated. Also it avoids a warning in the JS console ("Missing widget: separator for field of type separator"). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/o

Since https://github.com/odoo/odoo/issues/113974, Properties fields can contain separator (virtual `<group>`) 
information inside its value. But in the view list, these separator can be selected in the optional fields. It doesn't make sense because there no value associated.

Also it avoids a warning in the JS console ("Missing widget: separator
for field of type separator").

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

Forward-Port-Of: odoo/odoo#173362

Purpose ======= Fix the undo button in the website snippets which is enabled after choosing a template from the theme selector. The undo button shouldn't be enabled as the first selected theme is meant to be the first history step. Specification ============= After selecting a theme in the theme selector, the history steps are reset. However the undo/redo buttons of the website snippets aren't being updated with the reset. This happens because the method which updates the undo/redo but

Purpose
=======
Fix the undo button in the website snippets which is enabled after choosing a template from the theme selector. The undo button shouldn't be enabled as the first selected theme is meant to be the first history step.

Specification
=============
After selecting a theme in the theme selector, the history steps are reset. However the undo/redo buttons of the website snippets aren't being updated with the reset.

This happens because the method which updates the undo/redo buttons is triggered on the 'historyStep' event and this event is only trigerred when adding a new step in the history, not when resetting the history.

Fixing the issue by trigerring the 'historyStep' event after reseting the history so that the undo/redo buttons are correctly being updated with the reset.

Task-4000990

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

Forward-Port-Of: odoo/odoo#170998

Before this commit, some calendar didn't show multiple days events in day and week modes. This commit enables the day slots in every calendar to show these events. opw-3933140 opw-3981108 Forward-Port-Of: odoo/odoo#172729

Before this commit, some calendar didn't show multiple days events in day and week modes. This commit enables the day slots in every calendar to show these events.

opw-3933140
opw-3981108

Forward-Port-Of: odoo/odoo#172729

Issue: ====== We can update the content of the editable before we choose the theme which results in unexpected behaviors. Steps to reproduce the issue: ============================= - Open the email marketing app - In the browser dev tools, set a big network throttle - Create a new mailing - Write in the editable zone before the template selection has had a chance to appear - Click on design tab in the sidebar - Traceback Spec: ===== We should not be able to write in the edi

Issue:
======
We can update the content of the editable before we choose the theme
which results in unexpected behaviors.

Steps to reproduce the issue:
=============================
- Open the email marketing app
- In the browser dev tools, set a big network throttle
- Create a new mailing
- Write in the editable zone before the template selection has had a
  chance to appear
- Click on design tab in the sidebar
- Traceback

Spec:
=====
We should not be able to write in the editable zone before choosing a
template.

Solution:
=========
We add a new option `waitForSnippets` for the `wysiwyg` to force the
editable element as `contenteditable="false"` until the snippets are
loaded. Once the snippets are loaded we set `contenteditable="true"`
back again.

Note 1: Removing the line of `this._activatecontenteditable` from
`_onMouseDown` in `odooEditor` because it keeps setting the editable
element as `contenteditable="true"` everytime we click. The line can be
safely removed because it's a leftorver from when clicking on links
would set everything to `contenteditable=false` except the link itself,
then clicking somewhere else would reactivate it. (introduced here
https://github.com/odoo/odoo/commit/72dd8d6e3c95f614353b1e87322a67c877c255c7)
. When it was outside the condition, it was hard to guess that it was not
needed anymore when we removed that `contenteditable` hack for links.

Note 2: the `odoo-editor` div in website have `contenteditable=false`
so dropped snippets will not be editable too. We call
`activatecontenteditable` after the drop of the snippets.

task-3901534

Forward-Port-Of: odoo/odoo#173642
Forward-Port-Of: odoo/odoo#168008

Issue: ====== Half of the colorpicker isn't visible in the sidebar toolbar. Steps to reproduce the issue: ============================= - Go to mass mailing and choose any template with a button. - Click on the button, make it a link. - Choose style as custom in the sidebar - Click on the circles for text color or fill color - Colorpicker is not position correctly. Origin of the issue: ==================== See commit: https://github.com/odoo/odoo/commit/88c16966b6b2d29d464ac3b43c

Issue:
======
Half of the colorpicker isn't visible in the sidebar toolbar.

Steps to reproduce the issue:
=============================
- Go to mass mailing and choose any template with a button.
- Click on the button, make it a link.
- Choose style as custom in the sidebar
- Click on the circles for text color or fill color
- Colorpicker is not position correctly.

Origin of the issue:
====================
See commit: https://github.com/odoo/odoo/commit/88c16966b6b2d29d464ac3b43cc4998d3f4fe0e2

Solution:
=========
Fixing this issue properly would require huge changes to how the
SnippetsMenu is constructed and would most likely require going
back to the slow iframe with all the assets inside. That would not
be a desirable outcome, especially in a stable version. With that
in mind, and considering the issue doesn't exist in saas-17.1, we
decided it was a prime example where a local change in the popper.js
library was actually the best fix. The library is very unlikely to
be updated in a stable version and the change won't reach saas-17.1.

co-authored with dmo-odoo

opw-3984170

Forward-Port-Of: odoo/odoo#170278

Steps to reproduce: - Go to Contact - Select Abigail Peterson - Set her as a company, don't fill the field country - In Partner assignment, set partner level, activation, level weight - Cick on go to website - Back to Resellers What happens: Error with traceback ending in "TypeError: 'bool' object is not subscriptable". This is due to the country field of a reseller not being filled in, the resellers page tries to load the list of all countries with resellers and displays either res

Steps to reproduce:
- Go to Contact
- Select Abigail Peterson
- Set her as a company, don't fill the field country
- In Partner assignment, set partner level, activation, level weight
- Cick on go to website
- Back to Resellers

What happens:
Error with traceback ending in "TypeError: 'bool' object is not subscriptable".
This is due to the country field of a reseller not being filled in,
the resellers page tries to load the list of all countries with
resellers and displays either resellers of the user's country or all
resellers if no match is found. If any reseller's country is not filled
in there is no 'country.id' to access leading to the error above.

Expected behavior:
Fallback: Show all partners when user's country has no resellers (as
described in the file itself by comments).

opw-4042404

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

Forward-Port-Of: odoo/odoo#173086

In the contact form view, click on "Add" in the x2many on a record that isn't a company. In the dialog, select the type "Contact" and click on the "Title" label. Before this commit, the many2one autocomplete dropdown of the title field behind the dialog (in the main form view) opens, instead of the one inside the dialog. This is because the id associated with that occurrence of the field and used as "for" attribute of the label isn't unique cross form views (we only ensured it to be unique in

In the contact form view, click on "Add" in the x2many on a record that isn't a company. In the dialog, select the type "Contact" and click on the "Title" label. Before this commit, the many2one autocomplete dropdown of the title field behind the dialog (in the main form view) opens, instead of the one inside the dialog.

This is because the id associated with that occurrence of the field and used as "for" attribute of the label isn't unique cross form views (we only ensured it to be unique inside a given form view).

There are several ways to fix this, but to minimize the diff and to comply with stable policy, this commit temporarily removes the ids that are already in the DOM (behind the dialog), and resets them when the dialog is closed.

In master, we may explore alternative solutions, like generate (globally) unique ids in the arch parser.

opw 3996642

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#173689
Forward-Port-Of: odoo/odoo#173584

A VAT number in Spain is a concatenation of the country prefix ES and another code, either: NIF - Número de Identificación Fiscal for individuals. CIF - Certificado de Identificación Fiscal for registered companies. The `res_partner.vat` field in Odoo is labelled "NIF" in the UI, and supports both the full VAT code with ES prefix and the shorter one without. This fix addresses two cases where the code assumed the ES prefix was present and incorrectly trimmed the first two characters away.

A VAT number in Spain is a concatenation of the country prefix ES and another code, either:

NIF - Número de Identificación Fiscal for individuals.
CIF - Certificado de Identificación Fiscal for registered companies.

The `res_partner.vat` field in Odoo is labelled "NIF" in the UI, and supports both the full VAT code with ES prefix and the shorter one without. This fix addresses two cases where the code assumed the ES prefix was present and incorrectly trimmed the first two characters away.

Reference: https://www.strongabogados.com/tax-id-spain.php

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

Forward-Port-Of: odoo/odoo#168052

Backport of #171924 `git cherry-pick 61a166af43cfc0d7659626c664f89d1cd4163a7c..0414da47d3548270380c9d577f84fbbcd0d5967e` Conflict notes: - requirements.txt conflicted on Babel and chardet, kept as the target Forward-Port-Of: odoo/odoo#173788

Backport of #171924

`git cherry-pick 61a166af43cfc0d7659626c664f89d1cd4163a7c..0414da47d3548270380c9d577f84fbbcd0d5967e`

Conflict notes: 
- requirements.txt conflicted on Babel and chardet, kept as the target

Forward-Port-Of: odoo/odoo#173788

Before this commit, the avatar for the employees in the org chart is loaded by the URL but also when we fetched the data. This commit avoid fetching image fields with `hierarchy_read`. Forward-Port-Of: odoo/odoo#173040 Forward-Port-Of: odoo/odoo#172934

Before this commit, the avatar for the employees in the org chart is loaded by the URL but also when we fetched the data.

This commit avoid fetching image fields with `hierarchy_read`.

Forward-Port-Of: odoo/odoo#173040
Forward-Port-Of: odoo/odoo#172934

This commit's purpose is to keep the user input when he creates an sol from the formview sol. Step to reproduce : - open project update - cilck on 'sols' stat button - click on 'new' to create a new sol - give a name 'youpi' to the sol - save the sol The name of the sol will be overwritten with a default one. Expected behavior: The name of the sol should be the one the user has set. Source of the problem: The name of sol is used for some computation in some use case when the fo

This commit's purpose is to keep the user input when he creates an sol from the formview sol.

Step to reproduce :

- open project update
- cilck on 'sols' stat button
- click on 'new' to create a new sol
- give a name 'youpi' to the sol
- save the sol

The name of the sol will be overwritten with a default one. Expected behavior:
The name of the sol should be the one the user has set.

Source of the problem:
The name of sol is used for some computation in some use case when the form view of sol from the sale_project module is used. But this form view is also used in the use case where the name override is not needed.

Solution: add a context key to differentiate the 2 use cases.

task - 4031977
version : 17.0 - master

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