Purpose
=======

When creating an attendee from frontend some fields may be added in
parameters, notably through inheritance (questions, ...). We want the
defaults values to have the priority on those parameters (e.g. barcode code).

Task ID-2322411
PR odoo/odoo#68699

X-Original-Commit: odoo/odoo@5391df9a81a42d2ec783e505d8e98f4c75abf13d

Give a coherent group as otherwise we could have access errors. Simple
case: an Admin Rights user goes into a mail message form which is only
available in debug mode which sets `group.no_one` into such user. This
model is only readeable by `base.group_sytem` so an AccessError will
raise.

closes odoo/odoo#67621

Signed-off-by: Simon Goffin (sig) <sig@openerp.com>

The changed test uses the drag&drop helper, and an operation does
not work as expected with the given params on chrome 90. The runbot
currently uses chrome 80, so it is not an issue, but if your chrome
is up-to-date, and you try to run the test suite, this test would
fail.

closes odoo/odoo#69964

Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>

Description of the issue/feature this PR addresses and current behavior before PR:
There is a discrepancy in the wording of the error message provided. The error reads that an 'internal user' is linked but really its a 'portal user.'.

Desired behavior after PR is merged:
The wording of the error is clearer, and it now says 'portal user' instead of 'internal user'.

OPW: 2498139

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

closes odoo/odoo#69550

Signed-off-by: Simon Goffin (sig) <sig@openerp.com>

*: account_payment, payment, sale

Steps:
- Install eCommerce
- Go to Website / Configuration / eCommerce / Payment Acquirers
- Configure Stripe:
  - Save Cards: Always
  - Payment Flow: Redirection to the acquirer website
- Go to /shop
- Add a product to the cart
- Process Checkout
- Select Stripe
- Pay Now
- Enter test data in Stripe Checkout form (https://stripe.com/docs/testing#cards)
- Pay
- Go to /shop
- Add a product to the cart
- Process Checkout
- Select your saved card
- Pay Now

Bug:
Stripe Error:
The provided PaymentMethod was previously used with a PaymentIntent
without Customer attachment, shared with a connected account without
Customer attachment, or was detached from a Customer. It may not be used
again. To use a PaymentMethod multiple times, you must attach it to a
Customer first.

Explanation:
https://stripe.com/docs/api/checkout/sessions/create#create_checkout_session-payment_intent_data-setup_future_usage


> Indicates that you intend to make future payments with the payment
> method collected by this Checkout Session.

According to this doc, `setup_future_usage` must be set in order to use
the saved card afterwards.

opw:2452452
opw:2498571
opw:2509897

closes odoo/odoo#69692

Signed-off-by: backspac <backspac@users.noreply.github.com>

Before this commit, it might happen that, in some situations,
with several tabs opened, the CrossTabBus called the longpolling
route repeatedly, thus slowing down the server, and freezing the
webclient.

The issue was tricky to reproduce. It was a race-condition that
could occur when several tabs performed simultanous calls to
addChannel, while being unloaded or becoming mastertab in the
meantime (e.g. when opening/closing/refreshing several tabs
simultaneously).

This issue has been introduced by [1] which by mistake (probably)
made each tab calling itself the localStorage to update the list
of channels when it was notified that the list of channels in
the localStorage just changed. So if several tabs had a slightly
different list of channels at a given moment (e.g. at startup),
it might happen that they in turn, undo what another tab just
put in the localStorage, and thus produced an infinite loop of
localStorage writes and longpolling request aborts/calls.

The issue could be reproduced with the OCA module [2], which
performs several addChannel at webclient startup.

This commit restores this part of the code as it was initially
written in [3].

Closes #69067

opw~2502799
maybe opw~2451865 as well

[1] https://github.com/odoo/odoo/commit/6448420
[2] https://odoo-community.org/shop/product/web-notify-2670#attr=10773
[3] https://github.com/odoo/odoo/commit/38581f67236377daa767ca2216529a26b8708b00#diff-f6eccad21ae3543606ab8f97b8b097d015412caeaee2bf8cc928eb3ccabac9f5R149



closes odoo/odoo#69383

Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>

To reproduce the error:
(Need sale_management)
1. In Settings:
    - Line Subtotals Tax Display: Tax-Included
2. Create a tax T:
    - Included in Price: True
3. Create and save a SO
    - Add a line with T
4. Switch to mobile view

Error: The amount of the order line is incorrect, it does not consider
the option from step 1.

OPW-2484646

closes odoo/odoo#69627

Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>

The IBAN template of Costa Rica is incorrect
Backport of #66730

OPW-2477541

closes odoo/odoo#69620

Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>

Before this commit

When someone tries to send a mail to a restricted alias (which can be
anywhere in 'To', 'CC' or 'BCC') and if the sender is not allowed to do
so, the mail bounces. However bounced mail shows info as if it bounced due
to address provided in 'To', even though it is not always the case.

Example you send a message to

  * 'To': 'valid@gmail.com' (okay)
  * 'Cc': 'myalias@odoo.com' (not allowed for you)

Mail bounces because you are not allowed to send a mail to alias provided
in 'Cc', but it shows the message that: `The following email sent to
valid@gmail.com cannot be accepted because [...]`.

After this commit

Boucing alias is shown in message body. Above example becomes `The following
email sent to myalias@odoo.com cannot be accepted [...].`

Note: Because the alias can be present in `Bcc` too (which will not available
in the message values we get in `message_route_verify` method), we simply use
display name of the alias instead of finding mail address matching with alias
from the message values.

Task ID-2390310

closes odoo/odoo#66654

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Steps to reproduce the bug:

- Let's consider a company in $
- Let's consider two sales taxes T1 (10% included) and T2 (0%)
- Define a fiscal position FP that maps T1 to T2
- Define a product P with T1, price = 11$ and available in the shop
- Define a pricelist PL in € such as 1€ = 2$, show discount to customer and discount P with 50%
- Define a portal user PU with FP and PL
- Log with PU
- Add P in the cart

Bug:

The unit price of P was 2,75€ instead of 2,5€ and the discounted price was 10€ instead of 5€

PS: Before adding P in the cart, the correct unit price and discounted price were displayed.

opw:2472528

closes odoo/odoo#69502

Signed-off-by: Simon Goffin (sig) <sig@openerp.com>

The try/except is there to check that the string can be interpolated, so
it is catching a ValueError. But if there is a singleton error (when the
length of `self` is bigger than 1), it will raise a ValueError too.
The UserError raised in the except is then weird/wrong.

closes odoo/odoo#69515

Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

This is a cherry-pick of commit: https://github.com/odoo/odoo/commit/72a5e2b273e5faeccf49c0ef3fbb9f470e1a1c71



- Install Website and Email Marketing
- Go to Settings
- Click on "Manage Languages" and activate French
- Click on "Activate and Translate" and check the websites to translate
- Go to Preferences and set user language to "French"
- Go to Website > Configuration > Settings and make sure that French is in the languages list
  and that it is default
- Go to Email Marketing
- Create a new mailing
- Make sure that current user is in the Recipients list
- Send the mailing (it will be scheduled)
- In debug mode, go to Settings > Technical > Scheduled actions to run the action manually
- Check the received mail and click on the "unsubscribe" link
On the unsubscribe page there is text that is not translated.

Some of the translations on this page is done in JS.
But the translations are not available at that moment.

The translations have to be loaded manually before letting the JS doing its work.

opw-2501708

closes odoo/odoo#69457

Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>

Issue

    - Install Time Off
    - Marc Demo > Create leave request
    - Admin > Validate the leave request
    - Marc Demo > Add an attachment

    Nothing happens

Cause

    There is a access right issue that is not handled in the
    JS.

Solution

    Handle it by doing a do_warn.

OPW-2171791

12.0 backport of #43464

note: backport for 12.0

opw-2500564

closes odoo/odoo#69463

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

In windows chrome 89 (seemed ok at version 89.0.4389.90 (13 march 2021)
and broken at version 89.0.4389.114 (29 march 2021)), clicking on a
select option doesn't trigger jQuery events if they are delegated.

For example this happen when selecting a field for custom group or
custom filter in the search view and when selecting a field the dropdown
closes.

This happens because:

- chrome now sends MouseEvent.button[^1] with value -1 instead of
  previousvalue of 0.

- jquery in odoo 12 and under is version 1.11.1 and only executes the
  delegated event if the button value is 0

Reproduction case of the issue [^2]: clicking to choose an option only
logs "non-delegated click".

So for version 12.0 and only 12.0, this commit is cherry-picking
jquery's commit that is fixing the issue:

https://github.com/jquery/jquery/commit/c82a6685bb9

[^1]: https://developer.mozilla.org/docs/Web/API/MouseEvent/button
[^2]: http://jsfiddle.net/cox4gzae



opw-2497859
opw-2499415
opw-2499305
opw-2466991
opw-2506676

fixes #66848

closes odoo/odoo#69274

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

Steps to reproduce the bug:

- Go to Settings > Technical > Messages
- Select some records and export it

Bug:

A traceback was raised because

PS: When exporting data, the function export_date is called from web/controllers/main.py
with the attribute raw_data

opw:2504763

closes odoo/odoo#69228

Signed-off-by: Simon Goffin (sig) <sig@openerp.com>

on large database module installation may be aborted because of timeout error.

---

opw-2475335

closes odoo/odoo#68400

Signed-off-by: Adrian Torres (adt) <adt@odoo.com>

currently, in fetchmail while create an incoming
mail server, Set a server name while being in POP
or IMAP server type and Switch to "Local" server type
the server name is erased.

with this commit, the value of the server name
should not be erased with onchange.

closes odoo/odoo#69125

Taskid: 2258523
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Backport of https://github.com/odoo/odoo/pull/61267



opw:2478217

closes odoo/odoo#69180

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

If the user type his website URL as suggested by the helper, and he redirects
his `http` to `https` (nginx, cloudflare..), then his canonical url won't ever
be reachable.
Most critical issue will be that we won't display the `alternate/hreflang` tag,
which basically tells the search engines what and where is our translated
content.

opw-2486918

closes odoo/odoo#69056

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

The transcoder (transforming CSS rules into inline CSS for mail clients)
was not working for text-decoration property because it would transform
text-decoration values in:

{'text-decoration-thickness': 'normal', 'text-decoration': none}

And the regex that ensures we don't add duplicates check if there is:

"(^|;)\s*text-decoration"

so if there is text-decoration-thickness, text-decoration is not added.

The regexp could be changed to:

"(^|;)\s*text-decoration[^\w-]"

but we already have special case for other text-decoration-* properties.

With this change we should get text-decoration applied in:

- edit mode (was already the case)
- readonly mode (new)
- mail client (only if mail client does not override it)

As a side note: text-decoration-thickness seems to be rather new[^1] so
at one point in time there was probably no issue.

[^1]: https://developer.mozilla.org/docs/Web/CSS/text-decoration-thickness



opw-2496490

closes odoo/odoo#69061

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Co-authored-by: Kamen Zhekov <kzh@odoo.com>

What are the steps to reproduce your issue ?

    1. Go to Contacts > Configuration > Localization > Countries > Select a country
    2. Edit the 'Layout in reports' (enable debug mode) and add an invalid field
    3. Create a Quotation and search for a customer from the country you edited.

What is currently happening ?

    Traceback is raised and you can't select the customer anymore

Why is this happening ?

    Because the key is not defined.

How to fix the bug ?

    Handle KeyError to detect if the user put an undefined key
    Handle ValueError to detect if the user put an invalid format key

opw-2447078

closes odoo/odoo#68923

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

Doing domains like [('something_ids', 'in', 4)] crashed the emulator because it was trying to check something was 'in 4', instead of reversing the check (as real form views do).

closes odoo/odoo#68875

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

https://github.com/odoo/odoo/pull/68253 fixed a bug in check_vat that caused it not to run any check when called on a partner with no country.

However, doing this caused another issue because of an ORM limitation: when writing vat and country_id with a single write() on the res.company, two distinct write are triggered on the related res.partner, one for each field. Both those write trigger the check_vat constraint.

Depending on the order in which the keys of the dictionnary passed to res.company's write were ordered, country_id could or could not be written before vat. If vat was written first and did not start with a country code, the write() on res.partner failed the constraint, because country_id wasn't set yet. This was wrong, but used to pass as there was no country_id on the partner, before https://github.com/odoo/odoo/pull/68253

 fixed that.

To circumvent the issue, we now allow entering any vat number without performing any check if it does not start with a country code and no country_id is set on the partner.

closes odoo/odoo#68896

Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

Open Website sale dashboard
The pie chart "Conversion Rate" labels display true/false which is not
meaningful for the user.
This occur because the labels are not taken into consideration for
boolean fields

opw-2454547

closes odoo/odoo#68841

Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>

closes odoo/odoo#68795

Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>

In https://www.agenciatributaria.es/AEAT.internet/Inicio/La_Agencia_Tributaria/Campanas/Retenciones/Cuadro_informativo_tipos_de_retencion_aplicables__2020_.shtml


we can check that this retention fee is applied for
'Rendimientos del art. 75.2.b): cesión derecho de imagen   (art. 101.1 RIRPF)'

It's not the regular retention, but there are cases where it can be
used, so we need to support it the same as others.

closes odoo/odoo#67911

Signed-off-by: Josse Colpaert <jco@openerp.com>

Before this commit:
When someone sends mail with help of mail_composer(mail.compose.message)
without having a mail template set, mail is not deleted after being sent
(and causes unwanted/unexpected burden on DB). This bug was introduced
with commit[1], where auto deletion was disabled if template is not set
on the composer.

After this commit:
If there is no mail template set on the composer, or if the template is
set and 'auto_delete' is enalbed on that template, the mail sent from
composer will be deleted after being sent successfully.

commit[1] - https://github.com/odoo/odoo/commit/8a026e26c6ae25e3fdb5369a7fa3343d70fab782#diff-898a3d5c08a567c1a7b82c026a213d796e850e376cbdb1c9e7936409f440d37aR257



Task id: 2484915

closes odoo/odoo#68403

Pr: #68403
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Before this commit, when creating a quotation from a CRM, the tags
weren't copied from the CRM to the quotation.

Now, the tags from the CRM are put it as default on the newly created
quotation. This behaviour is the same on version 13 and new, and it was
also the case on version 11.

opw-2483149

closes odoo/odoo#68690

Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>

The website is now referenced to Odoo's website, with the most updated documentation.

closes odoo/odoo#68672

Signed-off-by: Josse Colpaert <jco@openerp.com>

When using "Generate Missing Terms" we export all translations and
reimport them with `create_empty_translation` so they empty translation
are made available.

But since we export all modules in the same PO file, the same terms that
might have different translation in different modules would get the same
translation value after using "Generate missing terms" which is
unexpected => usually we import/export PO file by module and so a term
translation is unique for one module only.

With this changeset, we import translation module by module.

When testing speed of Generate Missing Terms with 90 modules and 37000
translations, the timing taken change like this:

- original code: 21 seconds
- exporting/importing 1 PO file per module: 45 seconds
- exporting 1 TGZ file total/importing 1 PO file per module: 23 seconds

opw-2439029

closes odoo/odoo#68306

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

A domain with a negated thruty leaf raises an exception here
https://github.com/odoo/odoo/blob/835197e48fbbee1c8ac35d52287537fa6f0bdd36/odoo/osv/expression.py#L614
due to
https://github.com/odoo/odoo/blob/835197e48fbbee1c8ac35d52287537fa6f0bdd36/odoo/osv/expression.py#L670


and the fact that `FALSE_LEAF != (1, "!=", 1)` and `TRUE_LEAF != (0, "!=", 1)`

Current wrong behaviour:
```
>>> distribute_not(['!', TRUE_LEAF])
[(1, '!=', 1)]
>>> is_leaf((1, '!=', 1))
False
```

This issue was noticed when adapting domains for fields that have been
removed during migration. Example (extract of) traceback:
```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/13.0/odoo/http.py", line 624, in _handle_exception
    return super(JsonRequest, self)._handle_exception(exception)
  ...
  File "/home/odoo/src/odoo/13.0/odoo/osv/expression.py", line 677, in __init__
    self.parse()
  File "/home/odoo/src/odoo/13.0/odoo/osv/expression.py", line 814, in parse
    self.stack = [ExtendedLeaf(leaf, self.root_model) for leaf in self.expression]
  File "/home/odoo/src/odoo/13.0/odoo/osv/expression.py", line 814, in <listcomp>
    self.stack = [ExtendedLeaf(leaf, self.root_model) for leaf in self.expression]
  File "/home/odoo/src/odoo/13.0/odoo/osv/expression.py", line 562, in __init__
    self.check_leaf(internal)
  File "/home/odoo/src/odoo/13.0/odoo/osv/expression.py", line 618, in check_leaf
    raise ValueError("Invalid leaf %s" % str(self.leaf))
ValueError: Invalid leaf (0, '!=', 1)
```

closes odoo/odoo#68615

Signed-off-by: Christophe Simonis <chs@odoo.com>

Current URL regexp doesn't support special, but still valid, character like `é`,
`è`, `ỗ`, `ặ`, etc.

Url like `https://tenor.com/view/chỗgiặt-dog-smile-gif-13860250` are not going
to be matched correctly.

This commit adds the support for Latin-1 Supplement, Latin Extended-A,
Latin Extended-B and Latin Extended Additional unicode.

Some relevant stackoverflow discussion:
https://stackoverflow.com/questions/20690499/concrete-javascript-regex-for-accented-characters-diacritics



task-2088895

closes odoo/odoo#68462

Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

The rubrics 900 and 910 were missing in Décompte TVA Suisse

opw:2479885

closes odoo/odoo#68016

Related: odoo/enterprise#17089
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Co-authored-by: jco-odoo <jco@odoo.com>

Special character in reference (eg. '#' character in invoice sequence)
might cause error for payment acquirer.

For example with stripe we get the error on:

    {'error': {'code': 'url_invalid',
     'doc_url': 'https://stripe.com/docs/error-codes/url-invalid

',
     'message': 'Not a valid URL', 'param': 'success_url',
     'type': 'invalid_request_error'}}

Or an error because prepare_tx_url is broken.

With this changeset, when a payment reference is used inside an url, we
quote it.

opw-2479658

closes odoo/odoo#68480

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

closes odoo/odoo#67968

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

At commit https://github.com/odoo/odoo/commit/9f172a61e0f2c
it was added prior updating the Journal Entry

At commit https://github.com/odoo/odoo/commit/8ffc0c9f81487


it was added again after updating the Journal Entry

Each commit was added without knowing of each other and they end up
being merged in to the same method.

For a few records being deleted this is not a big deal but when
deleting a lot of records this become a hassle.

closes odoo/odoo#68452

Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>