When a coupon is generated from POS order, you get a traceback saying
you don't have access rights on "coupon.coupon" when you are only a pos
user.

So when we need to create the coupons and write on it, we are doing it
in sudo, to let the pos process generate the coupon.

Task-id: 2742528
Part-of: odoo/odoo#84544

The aim of this commit is to set partner on anglosaxon
aml in order to help our client in their stock
reconciliation process in case it hasn't been done automatically.

Before this commit:
anglosaxon line were created without partner

After this commit:
A partner is set when anglosaxon line are created

closes odoo/odoo#84525

Ticket: 2692308
Community-pr: https://github.com/odoo/odoo/pull/84468


X-original-commit: abfe37fc
Signed-off-by: William André (wan) <wan@odoo.com>

Steps to reproduce the bug:
- Go to inventory > configuration > Products > Attributes
- Create a new Dynamic Attributes > add two attribute values
- Create a storable Product “Test”:
    - Add the two attributes
    - Save
    - Create a BOM related to this product
- Create a new manufacturing order:
    - Do not choose a product
    - Select the BOM related to the product “test”

Problem:
Traceback is triggered because as the product template only has dynamic variants, there is not a `product.product` record created yet.
but we try to access it in the onchange: https://github.com/odoo/odoo/blob/14.0/addons/mrp/models/mrp_production.py#L598



Solution:
do not set the product when a BOM of a product_tmpl without a variant was chosen
opw-2732254

closes odoo/odoo#84522

X-original-commit: 50b538e7
Signed-off-by: Arnold Moyaux <arm@odoo.com>

Current behavior:
When trying to open the gift card list you get an access error if one of the cards has been used in another company.
This error appears because you cannot access SO from another company and the used gift cards were linked to a SO.
So shouldn't be able to use a gift card that was created in another company.

Steps to reproduce:
-Create a gift card in company A
-Use it in company B
-Try to access it from company A
opw-2732973

closes odoo/odoo#83901

Signed-off-by: Masereel Pierre <pim@odoo.com>

closes odoo/odoo#84509

Related: odoo/enterprise#24302
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Steps to reproduce:

 - Activate Debug mode
 - Go to Settings -> Companies
 - Create company A and B and set a different favicon for each company
 - Refresh the page or switch company

Issue:

  The favicon is not the right one.

Cause:

  Code (that update favicon) removed when refractoring of owl.
  Related commit: https://github.com/odoo/odoo/commit/0573acae2306bf5da2005852da9323ddc59e5431



Solution:

  When web client start, update in JS the favicons (desktop and mobiles)
  with current company favicon.

opw-2664525

closes odoo/odoo#80113

Signed-off-by: Jérémy Kersten <jke@odoo.com>

The configurator introduced at [1] uses a frontend controller to
display its content. However this results in inconsistent language
translation as the python code uses the users's language but the
localization services uses the frontend's language when on a frontend
page.

Steps to reproduce:
- Create a database with the only language being french
- Install website
- In the configurator, all the pages will be in french except
  "Pages and Features"

With this commit, the language for the configurator will always be
the language of the website it's configuring. A test also make sure
that this is the current behavior.

[1]: https://github.com/odoo/odoo/commit/e8a5af2e28a4724f86783746706cb59175f086bf



task-2687416

closes odoo/odoo#80055

Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: JKE-be <jke@odoo.com>

- Create a sale.order with a product with an optional product
- Confirm order A
- Copy this order A, a new order B is created
--> Issue: the new line of order B are linked with an line of order A

closes odoo/odoo#84206

X-original-commit: 8f07d9d1
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Steps to Reproduce:

  - Install 'account' module
  - Go to Settings and set a token for Google Drive
  - Activate Google Spreadsheet
  - Go to Invoicing -> Invoices
  - Under Search bar, click on Favorites -> Add to Google Spreadsheet

Issue:

  A spreadsheet does open but with no data (no formula or config).

Cause:

  The V3 API we were using was turned down in August 2021 and therefore
  not able to use the api to write on the spreadsheet.
  https://cloud.google.com/blog/products/g-suite/migrate-your-apps-use-latest-sheets-api)

Note: In case that the system parameters `​google_drive_client_id` and
`google_drive_client_secret` has been changed (and therefore also the
default templates), it must be ensured that the `client` has the
Google Sheet API (v4) activated and the scope
`https://www.googleapis.com/auth/spreadsheets` set.

API activation and configuration available here :
https://console.developers.google.com/apis/dashboard?project=[PROJECT]
https://console.developers.google.com/apis/credentials/consent/edit?project=[PROJECT]


**[PROJECT]** : Google project that will be linked to `​google_drive_client_id`.

opw-2633951

closes odoo/odoo#84480

X-original-commit: d73c79d7
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>

Chart.js did badly compute the graph canvas container height (width) by
using clientHeight (resp. clientWidth) that may be rounded up by the
browser. This leads to the appearence of a useless scrollbar in the
graph view and makes it flicker on some update.

closes odoo/odoo#84454

X-original-commit: 6bceae94
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

closes odoo/odoo#84463

X-original-commit: bdde46da
Signed-off-by: Olivier Dony <odo@odoo.com>

This commit ensures that changes are applied in the same order as the
events are triggered on the we-matrix. This was not the case because of
another bug we had to consider and which is not there anymore, this is
why this fix is done in 15.0 and not before.

This commit is the continuation of [1] which applied the same change for
we-input.

[1]: https://github.com/odoo/odoo/commit/db62a5fac123fc72e37e94709b1a0c80f32a8a29



task-2761187

closes odoo/odoo#84337

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Steps to reproduce the bug:
- Go to any Contact > Sales and Purchase tab
- Edit > Change the barcode, and click Save
- Then click Edit, and try to erase (empty) the barcode > save

Problem:
A validation error is triggered, the constraint will check if other partners do not have the same barcode
but as it is empty there will be several other partners

Solution:
When the barcode is empty, no need to check if other partners have the same

opw-2753291

closes odoo/odoo#84434

X-original-commit: 32754ebc
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>

Adds chrome path discovery for windows, and spawns sub-chrome via
subprocess (since fork is not a thing).

closes odoo/odoo#84427

X-original-commit: 0c0ac49e
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Adding a test to verify if `send_payment_request` is used once and
only once, and under the right conditions.
In the utils, we change the direct use of `opener` in
portal_transaction for a softer use of `url_open` which manage the
url and then call the `opener` for a same end result.

task-2659750

closes odoo/odoo#80590

Related: odoo/enterprise#22854
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

This commit lighten payment onboarding form in order to take advantage
of the Stripe Connect Onboarding Flow. It integrates the Stripe
Onboarding using the IAP proxy.

Purpose
=======
Help users easily onboard with Stripe by using the Stripe Connect API.

Specifications
==============
During the payment onboarding, if the user selects Stripe, they will
start the Stripe Onboarding. (NB: The process uses a proxy that handles
the Stripe Onboarding calls and signs them with the Stripe Connect key)
1) A call is made through the proxy to get the Stripe account token;
2) A call is made through the proxy to get the Stripe account link which
   contains the URL of the Onboarding;
3) The user is redirected to the Stripe Onboarding;
4) The user completes the Stripe Onboarding;
5) The user comes back to the acquirer form of Stripe and is able to get
   their keys.
6) The user can directly create their webhook after having copied/pasted
   their API keys.

During the website sale onboarding, the user doesn't go through the
onboarding wizard but is directly prompted to activate their account.

Note that the Onboarding status isn't stored in the database so there is
no call to Stripe API to validate the account status.

API Documentation :
- Connect Onboarding: https://stripe.com/docs/connect/standard-accounts
- Webhook creation: https://stripe.com/docs/api/webhook_endpoints/create



task-2685160
task-2691213

closes odoo/odoo#79621

Related: odoo/enterprise#23060
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

This commit adds payment icon sequence to display the icon in a more
famous-more visible order.

task-2685160

Part-of: odoo/odoo#79621

Commit 57701b2 resulted in another bug as links could not longer be
edited. This refines it so it fixes the bug it solved without the
nefarious side effect.

closes odoo/odoo#84428

Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>

The function `_compute_amount` on `account.tax` returns None if the value of
`amount_type` is not a standard Odoo value. During normal use, this will never
be the case, and if the value is  modified by a custom module the method is
overriden in its code to account for that case.

During an upgrade, however, custom modules are not available. During the tests,
if a field needs to be computed using that function, it will break with
`TypeError: unsupported operand type(s) for /: 'NoneType' and 'float'`

Adding a default return to the function in case the `amount_type` is not
recognisef will help prevent this.

closes odoo/odoo#84413

X-original-commit: 8489da59
Signed-off-by: Olivier Colson <oco@odoo.com>

To reproduce the issue:
    - create a cash basis tax, with different account and tags for invoice and refund
    - make an customer invoice using this tax, post it, and register a full payment for it
    - unreconcile the payment

=> Two cash basis moves have been generated: one for the initial reconciliation, and another one reverting it when the reconciliation got cancelled.

=> Bug: the reverse move uses the refund repartition, while the original one is using the invoice's one, so they don't sum up to zero. It's wrong: since the reconciliation got cancelled, we want the impact of the invoice on our tax report to be 0 again, just as if it was brand new.

closes odoo/odoo#84246

closes odoo/odoo#84419

Forward-port-of: https://github.com/odoo/odoo/pull/83837


Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Olivier Colson <oco@odoo.com>

2f6a35eb introduced the fact that when doing a full refund of an invoice, the same account was used as on the original invoice, instead of the one on the tax refund repartition lines, though the tags were still the refund ones. This is wrong.

Also, it restored an inconsistent data setup in a test, while the current version was actually correct.

Forward-port-of: https://github.com/odoo/odoo/pull/83837
Part-of: odoo/odoo#84419

Icons converted to images were improperly aligned because as inline
elements their vertical-align style property used their first block
ancestor as reference.

closes odoo/odoo#84088

Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

The final mail to be sent will have to use a mail-safe font everywhere
so we can't allow other fonts to be applied in some elements. Because of
the way the css was declared, we still had other fonts on some elements,
like .btn. As a result, we had a different look between readonly and
edit modes.

Part-of: odoo/odoo#84088

The conversion of the comparison snippet for mail compatibility involves
heavy changes in the html. In order to preserve the style, some style
changes were needed as well. This change to the style of cards allows us
to restore the border around the snippet.

Part-of: odoo/odoo#84088

jQuery was used extensively in `convert_inline`, slowing it down by a
factor of more than 2. This replaces all use of jQuery with vanilla
javascript so as to improve performance significantly.

Part-of: odoo/odoo#84088
Co-authored-by: Antoine Guenet <age@odoo.com>
Co-authored-by: Nicolas Bayet <nby@odoo.com>

Rules used to be applied in the DOM sequencially, in traversal order.
This is slow and confusing to debug. Meanwhile, most functions had been
adapted to process the rules in a simple loop on the concerned nodes.
This commit does that for `classToStyle`, the last remaining function
that wasn't doing it yet, and removes the utility function
`_applyOverDescendants` altogether.

Part-of: odoo/odoo#84088

This improves performance of `classToStyle` by first selecting which
nodes and which rules will be concerned.
When parsing the css rules, we computed their specificity and normalized
their styles one by one. This applies these processes only on the
concerned rules, all at once.

Part-of: odoo/odoo#84088
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>

Since some css was loaded twice, when parsing rules, we grouped similar
rules in order to minimize the amount of rules on which to iterate
during conversion, so as to improve performance. This is not needed
anymore now css is loaded only once, so we can remove this extra
processing.

Part-of: odoo/odoo#84088
Co-authored-by: Antoine Guenet <age@odoo.com>
Co-authored-by: Nicolas Bayet <nby@odoo.com>

This batches all writes in the `formatTables` method of `convert_inline`
so as to minimize layout thrashing and therefore improve performance.

Part-of: odoo/odoo#84088
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>

This batches all writes in the `classToStyle` method of `convert_inline`
so as to minimize layout thrashing and therefore improve performance.

Part-of: odoo/odoo#84088
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>

`web.assets_frontend` was called in `wysiwyg_iframe_editor_assets` _and_
in `iframe_css_assets_edit`. As a result, they were loaded twice in edit
mode.

Part-of: odoo/odoo#84088
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>

`__extraAssetsForIframe` had been kept in `mass_mailing` and
`web_editor` for historical reasons but was not used anymore. This
removes it.

Part-of: odoo/odoo#84088

Some tests depended on a variable to be defined, which was only defined
in other tests.

Part-of: odoo/odoo#84088

When a warehouse used multi-steps for incoming/outgoing shipments,
negative procurements could create returns pickings instead of reducing
the quantity of subsequent moves down the chain.

For example a two-step delivery, a sale order with 5 product A would
have the following pickings linked :
Pick:
- product A : 5 qty
Out:
- product A : 5 qty

Then reducing the amount of product A to 2 in the sale order would do :
Pick:
- product A : 2 qty
Out:
- product A : 5 qty
Return:
- product A : 3 qty

closes odoo/odoo#84414

Signed-off-by: Arnold Moyaux <arm@odoo.com>

Before this commit, on Chrome browser, the page url input and the
visiblity password input were autocompleted with the user's login and
password in the page properties options.

After this commit, they are no longer.

Regarding the url input page, it seems to be because Chrome considers
that the first text input located before a password input in the DOM is
a login input.

task-2502747

closes odoo/odoo#84386

X-original-commit: 7f458229
Signed-off-by: Romain Derie (rde) <rde@odoo.com>

[FIX] survey: Avoid forbidding access to survey when the answer cookie corresponds to no actual answer

To reproduce:

1) Create a survey and open it with a portal user with its /survey/start/*** link

2) In a private window, connect as the admin and remove the answer in 'Not started yet' state that step 1 created.

3) Go back to your portal user window and re-enter the same /survey/start/*** URL.
==> The portal user is brought back to the home page. He has no way to access the survey anymore, the link will always redirect him there.

This is because of cookies. The first time the user opens the survey, it creates a cookie in his browser allowing him to reload the answer he was working on. In our example, this answer has been deleted for some reason (maybe some cleaning of too old 'not started' or 'in progress' stuff); so the token stored in the cookie does not correspond to anything anymore. Instead of crashing and redirecting to home page, this commit makes it so that we now ignore the cookie in that case, so that the user directly has access to the survey to build a new answer.

Task-2729738

closes odoo/odoo#84373

X-original-commit: c642be8e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Olivier Colson <oco@odoo.com>

To reproduce the issue:

1) Create a survey requiring user login, with multiple pages

2) Create portal user A and B

3) With user A, go to URL /survey/start/****, where **** is the access token of your test survey. Fill in the first pages of the survey, but don't finish your submission (so: the answer has to stay 'in progress').

4) Logout from user A.

5) From the same browser window (or without cleaning cookies, at least), directly login with user B, and go to the same /survey/start/**** link

====> The 'in progress' answer from A is loaded, even though we are connected with B and should hence not have access to it. Instead, we should have created a new blank answer for B.

This is due to our cookie management. When a cookie is kept in the browser with the token of a previously entered answer, we reload it without checking its owner.

Task-2729738

X-original-commit: 0be94b7f
Part-of: odoo/odoo#84373

Filtering stock_pickings by selecting the product in the dropdown menu doesn't return anything

Steps to reproduce:
1. Install Inventory
2. Go to Inventory > Operations > Transfers
3. In the search field, begin typing the name of a product for which there is a transfer (e.g. Large Cabinet)
4. Click on the small arrow to the left of `Search Product for:` in the dropdown menu
5. Select the product you were typing
6. There is no result to the search even though there are transfers containing the product

Solution:
Remove `filter_domain`
The filter will be handled in the backend by `_name_search` of `product.product`, which already covers the same criteria (`default_code`, `name` and `barcode`)

Problem:
The display name (e.g. "[E-COM07] Large Cabinet") wasn't matched by the `filter_domain` because the domain sent in the RPC was:
```
"domain": [
	"|",
        "|",
        [
            "product_id.default_code",
            "ilike",
            "[E-COM07] Large Cabinet"
        ],
        [
            "product_id.name",
            "ilike",
            "[E-COM07] Large Cabinet"
        ],
        [
            "product_id.barcode",
            "ilike",
            "[E-COM07] Large Cabinet"
        ]
    ]
```

OPW-2732804

closes odoo/odoo#84368

X-original-commit: abd951b0
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>

The es-check help specify that the `--module` optional argument as to be
given at the end of the cli. After an update to version `6.2.1` it led
to errors on runbot's where the Dockerfile was updated.  The error was
like if the `--module` cli argument was not given at all.  e.g.: `error:
SyntaxError: 'import' and 'export' may appear only with 'sourceType:
module'`

With this commit, the argument is given at the end of the cli as
expected.

closes odoo/odoo#84365

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

closes odoo/odoo#84360

X-original-commit: 5c295fd1
Signed-off-by: Kevin Baptiste <kba@odoo.com>