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

X-original-commit: 43994da9980e4133274984f720bb58f3546ea0f9
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

When the user submits a form, a lead will be created but the language
won't be the one selected by the user.

To reproduce the error:
(Enable debug mode)
1. Settings > Translations > Languages
2. Activate another language L_other
3. On website, add a form:
    - Action: Create an Opportunity
4. Add an existing field: "Language"
5. Submit the form
    - Language must be L_other
6. Consult the new lead

Error: The language is not the selected one.

OPW-2486276

closes odoo/odoo#69941

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

Before this update if you would update the module the default livechat details would be reset.
By wrapping it in a no-update they're not updated with a module update.

closes odoo/odoo#69961

Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

This commit allows the `form_builder_send` widget to be reused.
Moreover, the creation of `post_form` allows other modules to specify
how post the form to the server

(Linked to OPW-2473001)

closes odoo/odoo#69401

Related: odoo/enterprise#17757
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

uuid should be unique even after copying

closes odoo/odoo#65319

Related: odoo/enterprise#16052
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

These changes have been made to be able to add some behaviors in some specific points of the flow when overridden.

Steps to reproduce the bug :
- Create a French company
- Go to accounting settings > in “Fiscal Localization” install French accounting
- Install “l10n_ch_qriban”
- Go to contacts > Configuration > Bank accounts
- Create a new bank account > add a French company newly created in the “Account Holder” field

Problem:
The specific fields to a Swiss company appear.

Solution :
Check if the country of the company encoded in the “Account Holder” field is Switzerland.

opw-2504699

closes odoo/odoo#69813

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

The media modal's document tab has cells with icons and filenames. If
the filename was too long, it would overflow its cell, which caused an
ugly design glitch. This ensures an ellipsis on the filename when it is
too long.

closes odoo/odoo#69893

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

Suppose Google Calendar synced with Odoo. When the user updates a
recurrent event on Google, syncing with Odoo may cancel the change.

To reproduce the error:
(Need google_calendar)
1. [On Google Calendar] Create a recurrent event
2. Sync with Google Calendar
3. [On Google Calendar] Move one of the recurrent events
    - Its date must be different
4. Sync with Google Calendar

Error: The updated event didn't move. On Google Calendar, the event has
moved to its initial date.

At some point, when updating a recurrent event that has moved, the
method `detach_recurring_event` is called. This method is in charge of
getting all data before creating the moved event. However, to get all
data, it first calls the `read` method and then adds some other
information:
https://github.com/odoo/odoo/blob/acaca80f0ce544d1c9a738a5aac992a8ac9c75b2/addons/calendar/models/calendar.py#L1409-L1420


And here is the problem. The method `read` provides additional
information, such as `start_datetime` and `stop_datetime`. However,
theses fields are computed based on the *calendar_id* of the event. Such
an identifier is like `<ID>-<Date>` where *Date* is the initial date of
the event. Therefore, `start`, `stop`, `start_datetime`, ... will be
incorrect.
Back to `detach_recurring_event`, `data` will be updated with some other
values and with `values`. Hopefully, since the latter contains the new
start and stop dates, `start` and `stop` will be overwrote with correct
values (i.e., dates of the moved event). However, `start_datetime` and
`stop_datetime` are still present and incorrect.
Therefore, because of the presence of these two variables, the method
`_inverse_dates` is triggered on creation of the new event. This one
recomputes `start` and `stop` based on `start_datetime` and
`stop_datetime`, but theses fields are incorrect (they are equal to
intial start and stop dates). This is the reason why (1) the updated
event didn't move and thus (2) on Google Calendar, the event has moved
back to its initial date.
This fix suggests to remove several fields from `read` method, because
some undesirable behaviors may happen. Moreover, since these fields are
computable, it's easy to get their (correct) value.

OPW-2474721

closes odoo/odoo#69150

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

This revision solves two things:
 - On installation of `l10n_latam_base`,
   `l10n_latam_base` is set as default as `l10n_latam_identification_type_id`
   for all partners in the database.
   The ORM method `write` was used to do so.
   With a database having a large number of partners,
   such as multiple hundred of thousands,
   this leaded to performance issues when `l10n_latam_base`
   got installed.
   I checked compute methods that could depends on this field,
   and the only one I found is `_compute_l10n_ar_vat`,
   which is not yet `installed/loaded` when this posthook takes place,
   as it's in the module `l10n_ar` which depends on `l10n_latam_base`
   and therefore is loaded after. So, it was already not executed/computed
   when using the ORM `write` method before this revision.
   Therefore, the use of plain SQL can be used to speed up the performance.
 - Also, the ORM `write` triggered unexpected compute fields
   which could raise exceptions, because of the `commercial_partner_id`
   synchronization.
   For instance:
```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/14.0/odoo/service/server.py", line 1198, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "/home/odoo/src/odoo/14.0/odoo/modules/registry.py", line 89, in new
    odoo.modules.load_modules(registry._db, force_demo, status, update_module)
  File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 455, in load_modules
    loaded_modules, update_module, models_to_check)
  File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 348, in load_marked_modules
    perform_checks=perform_checks, models_to_check=models_to_check
  File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 239, in load_module_graph
    getattr(py_module, post_init)(cr, registry)
  File "/home/odoo/src/odoo/14.0/addons/l10n_latam_base/__init__.py", line 8, in _set_default_identification_type
    env['res.partner'].search([]).write({'l10n_latam_identification_type_id': env.ref('l10n_latam_base.it_vat').id})
  File "/home/odoo/src/odoo/14.0/addons/base_vat/models/res_partner.py", line 538, in write
    return super(ResPartner, self).write(values)
  File "/home/odoo/src/odoo/14.0/addons/snailmail/models/res_partner.py", line 26, in write
    return super(ResPartner, self).write(vals)
  File "/home/odoo/src/odoo/14.0/addons/partner_autocomplete/models/res_partner.py", line 199, in write
    res = super(ResPartner, self).write(values)
  File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 550, in write
    partner._fields_sync(vals)
  File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 469, in _fields_sync
    self._children_sync(values)
  File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 478, in _children_sync
    self._commercial_sync_to_children()
  File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 452, in _commercial_sync_to_children
    sync_children._compute_commercial_partner()
  File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 297, in _compute_commercial_partner
    partner.commercial_partner_id = partner.parent_id.commercial_partner_id
  File "/home/odoo/src/odoo/14.0/odoo/fields.py", line 1127, in __set__
    records.write({self.name: write_value})
  File "/home/odoo/src/odoo/14.0/addons/base_vat/models/res_partner.py", line 538, in write
    return super(ResPartner, self).write(values)
  File "/home/odoo/src/odoo/14.0/addons/snailmail/models/res_partner.py", line 26, in write
    return super(ResPartner, self).write(vals)
  File "/home/odoo/src/odoo/14.0/addons/partner_autocomplete/models/res_partner.py", line 199, in write
    res = super(ResPartner, self).write(values)
  File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 546, in write
    result = result and super(Partner, self).write(vals)
  File "/home/odoo/src/odoo/14.0/addons/mail/models/mail_activity.py", line 766, in write
    return super(MailActivityMixin, self).write(vals)
  File "/home/odoo/src/odoo/14.0/addons/mail/models/mail_thread.py", line 322, in write
    result = super(MailThread, self).write(values)
  File "/home/odoo/src/odoo/14.0/addons/website/models/mixins.py", line 182, in write
    return super(WebsitePublishedMixin, self).write(values)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 3640, in write
    self.modified(relational_names, before=True)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5786, in modified
    tocompute = list(tocompute)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5862, in _modified_triggers
    yield from records._modified_triggers(val)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5858, in _modified_triggers
    records |= model.search([(key.name, 'in', real_records.ids)], order='id')
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 1708, in search
    res = self._search(args, offset=offset, limit=limit, order=order, count=count)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 4492, in _search
    self._flush_search(args, order=order)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 4470, in _flush_search
    self.env[model_name].flush(field_names)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5442, in flush
    self.recompute(fnames, records=records)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5908, in recompute
    process(field)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5879, in process
    field.recompute(recs)
  File "/home/odoo/src/odoo/14.0/odoo/fields.py", line 1145, in recompute
    self.compute_value(record)
  File "/home/odoo/src/odoo/14.0/odoo/fields.py", line 1175, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/src/odoo/14.0/addons/mail/models/mail_thread.py", line 410, in _compute_field_value
    return super()._compute_field_value(field)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 4068, in _compute_field_value
    self.filtered('id')._validate_fields(fnames)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 1260, in _validate_fields
    check(self)
  File "/home/odoo/src/odoo/14.0/addons/sale_project/models/project.py", line 70, in _check_sale_line_type
    product_id=task.sale_line_id.product_id.display_name,
odoo.exceptions.ValidationError: You cannot link the order item SO/2019/11374 - [COMOD2H] Servicio de Correctivo dos Horas to this task because it is a re-invoiced expense.
```
upg-11324

closes odoo/odoo#69869

Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>

A computed field on event may crash if current user is a portal user as it
tries to access registrations to know if current user is already participating
to the event.

We also fix ACL on the registrations as most code already use it as sudo and
do not access it directly. Only the event users or admins should access it
directly.

Task ID-2322411
PR odoo/odoo#

closes odoo/odoo#69928

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

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#

Steps to reproduce the bug:

- Try to export mail.message records

Bug:

A traceback was raised

Wrong forward-port of 69b27ac3

opw:2514584

closes odoo/odoo#69839

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

Description of the issue/feature this PR addresses:
_compute_quantities calls _compute_quantities_dict which calls _get_domain_locations, this last function depends also on 'location' and 'warehouse' from context, so also this variables should be put in the depends_context decorator

Current behavior before PR:
product.qty_available and product.with_context(location=x).qty_available return the same value also if the product in stored in more than one location
Desired behavior after PR is merged:
product.with_context(location=x).qty_available should return the quantity available only in location x

This has been already fixed in 14.0.
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

closes odoo/odoo#69874

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

Before this commit, we would compare a lang `code` (used in context) and a lang
`url_code`. For languages where those 2 are differents, the `if` condition
would always be falsy, making the canonical URL impossible to be reached.

Technically, this condition is used to get the translated name of records to
later construct the canonical URL.

Since the canonical URL will be incorrect and unreachable, the whole system to
tell search engine/crawler about translation won't work since no
`alternate/hreflang`[1] will be set in the DOM.

[1] see https://developers.google.com/search/docs/advanced/crawling/localized-versions



--------

Technical explanation:
- italian language `code` = `it_IT`, `url_code` = `it`
- belgian french language `code` = `fr_BE`, `url_code` = `fr_BE`
Install those languages on website as secondary languages.
Translate blog `Travel` to `Voyager` in french and `Viaggi` in italian.
Visiting `/fr_BE/blog/travel-1/post/post-1` will redirect to
`/fr_BE/blog/voyager-1/post/post-1` as it should, and the canonical URL will be
set to that same URL.
Visiting `/it/blog/travel-1/post/post-1` will redirect to
`/it/blog/voyager-1/post/post-1` as it should, but the canonical URL will be
set to `/it/blog/travel-1/post/post-1`.

opw-2486918

closes odoo/odoo#69503

Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>

closes odoo/odoo#69681

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

When retreiving the list of badge owners in `_get_owners_info()`,
we should apply `res.users` ir rules to be sure to respect multi-company
rules.

upg-7081

closes odoo/odoo#69357

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

- Create an invoice with an empty fiscal position
- Create a line with a product having 100.0 as sale price and 21.0% price-included tax
=> price_unit equals 99.99

This is because 100 / 1.21 ~= 82.64 but 82.64 * 1.21 ~= 99.99 != 100.0.
The bug only appears when managing a fiscal position because the code is trying to adapt the product price_unit to the newly computed taxes.

closes odoo/odoo#69522

Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.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#69748

X-original-commit: 5945806c
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#69753

X-original-commit: 93439c75fee5280fbca451b4aa2fcd8c86f8b325
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.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#69688

X-original-commit: 899ae3e0
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

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

OPW-2477541

closes odoo/odoo#69698

X-original-commit: 3039a613
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>

Before this commit:

  When there is too much records to post and it's take time more than 15 minutes then server was restarted.
  So scheduler action will do the process with the same records again and again.

After this commit:

  post record in batch of 1000

opw-2451446

closes odoo/odoo#66467

Related: odoo/enterprise#17668
Signed-off-by: William André (wan) <wan@odoo.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#69705

X-original-commit: 98179a08
Signed-off-by: Adrien Widart <adwid@users.noreply.github.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#69630

X-original-commit: 379f1490
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>

Mail holds a "Pay Now" notification template holding notably customized
links to portal for records like sale orders or invoices. It allow to
give a more personalized button than a plain simple "View document" link.

Currently frontend / backend links are not always correctly computed in this
template. This commit fixes that behavior.

Task ID-2513724
COM PR #69607
ENT PR odoo/enterprise#17849

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

Purpose of this commit is to fix computation of access link. In some cases
msg_vals modification leads to invalid URL computation, notably for frontend
or backend differentiation for target recipients.

Followup of odoo/odoo#63292 .

Task ID-2513724
COM PR odoo/odoo#69607
ENT PR odoo/enterprise#17849

When l10n_latam_invoice_document is installed and the current company
does not have a custom header (in stable, only Chile and Argentina with
their localization installed use custom header), printing multiple
invoice at once, one out of two had no header or footer.

This is because `<div class="header"/>` and `<div class="footer"/>`
should be unique per record being printed, and when a custom header was
not used they were duplicated with the duplicate empty.

As an example, if we had 3 documents:

- record 1 : good header
- record 1 : empty header
- record 1 : body
- record 1 : good footer
- record 1 : empty footer

- record 2 : good header
- record 2 : empty header
- record 2 : body
- record 2 : good footer
- record 2 : empty footer

- record 3 : good header
- record 3 : empty header
- record 3 : body
- record 3 : good footer
- record 3 : empty footer

When we give them to wkhtmltopdf, it would be mismatched:

- headers:
  - record 1 : good header
  - record 1 : empty header
  - record 2 : good header

- bodies:
  - record 1 : body
  - record 2 : body
  - record 3 : body

- footers:
  - record 1 : good footer
  - record 1 : empty footer
  - record 2 : good footer

so record 2 will have empty header/footer, and record 3 will get those
of record 2.

opw-2507137

closes odoo/odoo#69686

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

What are the steps to reproduce your issue ?

    1. Add a coupon program with the following condition sale_ok == True & name == 'Large Desk'
    2. Add 'Buy 1 get 2 free' 'Large Cabinet'
    3. Create a quotation with 1 Large Desk and 2 Large Cabinet
    4. Add the coupon code

What is currently happening ?

    Promotion will only remove one * Large Cabinet price instead of 2

What are you expecting to happen ?

    Promotion remove two * Large Cabinet price

Why is this happening ?

    The products quantity was mixed with the reward products quantity

opw-2496940

closes odoo/odoo#69365

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

- Create a product:
  * Invoicing Policy: Delivered quantities
  * Re-invoice Expenses: At cost
- Create a SO with the created product in Order Lines
- Make sure the subtotal of the SO line is equal to 0, by setting an Unit Price to 0
  or by applying a 100% discount
- Confirm SO and create an invoice (Regular invoice)
- Post the invoice
A new line with the same product and the same delivered quantity is added to the SO.

It is not possible to invoice a SO line with a product having an expense policy and
a subtotal equal to 0, without having it reinvoiced to the SO.

This fix will prevent account move lines linked to a SO line from being reinvoiced.

opw-2479560

closes odoo/odoo#69491

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

When trying to send&print a move without partner_id, which can be done
from the tree view of the account moves, a traceback will be raised when
 the address is being validated.

This change will make sure to avoid that and also shows that the adress
is not complete in the wizard if needed.

closes odoo/odoo#66646

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

When a pos user combines payment methods with and without rounding, we
must be sure that the rounding is made by payment method and not only on
the total amount of the order.

As the total may change depending on the combination of payment method
used, we had to adapt the methods that checks that an order is paid, and
also propagate the new rounding made on the invoice.

We also don't allow anymore a user to validate an order with a payment
badly rounded.

closes odoo/odoo#69395

Signed-off-by: pimodoo <pimodoo@users.noreply.github.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#69535

X-original-commit: 36ebbb6f
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>

When we change partner in reconciliation, current lines are excluded
from the search and kept. So if we eg. have partner "Azure Interior":

[no partner shown] line 1
[no partner shown] line 2

then search "Deco Addict" that find a line 4, we would have this result:

Azure Interior line 1
Azure Interior line 2
line 4

That might make things messy to find the right line.

opw-2504501

closes odoo/odoo#69424

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

- Open POS session
- Make an order to a customer, generating the invoice.
- Close POS session and go to the invoice
- Unreconcile the payment.

User is now stuck because the invoice is still marked as paid and is no
longer possible to record a payment or add an outstanding amount as
payment

opw-2349727

closes odoo/odoo#69316

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

Have a large number of attachments with res_field set
Then go to Settings -> Technical -> Attachments -> add a filter "Res
Field" is set.

You will have traceback. This occur because the `_search` function will
omit from results records with res_field set, forcing recursive calls
until either we scan the whole table (80 records at a time) or we hit
max recursion limit

opw-2463634

closes odoo/odoo#68471

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

Before this commit, There would be Expected singleton error
on changing Credit/Debit for multile account in single call.

Now, We are proocess one record to set `_set_opening_debit_credit`

closes odoo/odoo#69208

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

In this commit, we add all the data related to the Argentinean
perceptions for each jurisdiction.

For each jurisdiction (xx) we have a new:
 * Tax: Percepción IIBB xx Sufrida
 * Tax: Percepción IIBB Catamarca Aplicada
 * Tax group: Perc IIBB xx
 * Account: Saldo a favor IIBB xx
 * Account: Retención IIBB xx sufrida
 * Account: Percepción IIBB xx sufrida
 * Account: Retención IIBB xx aplicada
 * Account: Percepción IIBB xx aplicada
 * Account: IIBB xx

Also, we activate some perceptions to work with demo data

closes odoo/odoo#67149

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