It may be a recordset in case of partner duplicates. The variable
bounced_partner is simple search by email:

https://github.com/odoo/odoo/blob/72b5a17fc0e6f439d462647a7b55c9a26235a8df/addons/mail/models/mail_thread.py#L1349



closes odoo/odoo#70447

X-original-commit: 5996bdd1
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Bug
===
1. Login as "Portal"
2. Go to "/my/opportunity"
3. Create an opportunity
4. Edit this opportunity from the frontend and set the probability empty
=> Save, an error is raised

Technical
=========
The probability is set to "None" and not to "False", therefor the
verification "probability >= 100" in the write method of the lead will
raise an error.

By using False instead of None, this verification will work.

Task-2613208

closes odoo/odoo#75084

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

In the xml file of the list view, it is possible to define a button that
will be placed in a new column. When the user clicks on a button from a
list view, the script will execute the action linked to the corresponding
button. Unfortunately, all the buttons of the list views are not necessary
linked to an action: This is for example the case for the trophy icon of
the survey module. An exception can hence be thrown if the user clicks on
such button.

To solve the issue, we will add the 'disabled' property support for the
buttons and we will add that property to the buttons that do not have
an action. With this property, the script will bind no listener to the
button and it will hence not call the listener causing the error.

task-2612033

closes odoo/odoo#75013

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

Steps to reproduce the bug:
- Create a storable product, e.g:”Product A”, with a AVCO + Automated category
- Make sure to assign an account in the price difference account field
- Create an RFQ with the “Product A”
- Confirm RFQ and receive the product
- Create the vendor bill and edit to change the unit cost from 55 to 56
- Post the bill
- Check journal items

Problem:
Price difference accounts have no partner_id

opw-2616388

closes odoo/odoo#75038

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

Step to follow

Create a sale order for a kit with a quantity of one and Dozens as a unit of
measure
Confirm and validate the delivery
The delivered quantity will be 12 instead of 1

Cause of the issue

The delivered quantity wasn't recomputed in relation to the sales order
quantity

opw-2535193

closes odoo/odoo#75022

X-original-commit: 5ce39d13
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

In subcontracting, there wasn't a way to make
the subcontracting resupply delivery plan before
the subcontracting receipt.

Now the hidden subcontracted MO, take in account
(in his planning) the `produce_delay` (in days) of
the product which is automatically plan the
subcontracting resupply delivery correctly.

task-2486811

closes odoo/odoo#74999

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

In new version of chrome (92) or firefox when some fonts (eg. courier)
were used:

- either the page would never finish loading (odoo 13 and below)
- or the text would in this font would not be shown (odoo 14 and over)

This was solved in pdf.js whith this commit:

https://github.com/mozilla/pdf.js/commit/8805614a03



And this PR is backporting that commit in 12.0 version up to master.

opw-2621405 opw-2613412 opw-2620186 opw-2618225 opw-2616690 opw-2615502
opw-2616249 opw-2615144 opw-2613969 opw-2613793 opw-2618129 opw-2617736
opw-2622506 opw-2614508 opw-2620883 opw-2622105 opw-2620863 opw-2615326
opw-2622842 opw-2620220 opw-2622842 opw-2620220 opw-2615346 opw-2615026
opw-2618389 opw-2619382 opw-2613286 opw-2621730 opw-2613412 opw-2622029
opw-2620625 opw-2622311

closes #75020

closes odoo/odoo#75051

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

Before this commit: when typing something on many2many_tags widget and clicking
on 'Create and Edit' from many2many_tags widget shows form dialog, now clicking
on the 'Save & new' button shows the old value in the name field instead of the
blank value it is because of default context passed, clicking 'Save & New' will
pass old context due to which name field will have old value, this will create
issue when there is unique name constraint, pressing 'Save & New' and then
again clicking 'Save & New' will raise constraint.

After this commit: clicking on the 'Save & new' button will shows the blank
value in the name field, to fix this issue, we removed 'default_name' key from
context.

TaskID-2323194

closes odoo/odoo#74992

X-original-commit: c14b17c4
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>

Steps to reproduce the bug:

When making a payment intent from Adyen terminal with the POS, the payment intent was validated by Adyen
but Odoo stopped polling because a connection failure happened  and then on retry it made second payment
even if the first one was successful.

Fix:

Now after a failure, it will try to poll again the last transaction (with get_latest_adyen_status)
and set the payment as successful or cancelled based on the last response.

opw:2587625

closes odoo/odoo#74972

Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Co-authored-by: nle-odoo <nle@odoo.com>

When creating a meeting from a partner/lead, the invitations won't be
created/sent

To reproduce the error:
1. Open a lead
2. Click on Meeting
3. Create a meeting
    - On meeting creation, directly click on "Create", not "Edit"

Error: No invitation has been sent. When editing the created event,
there isn't any invitation on Invitations tab. Same error will happen
when opening the form of a customer instead of a lead (step 1)

For an attendee to be created, the partners associated with the meeting
must be explicitly listed in the creation values:
https://github.com/odoo/odoo/blob/3e20e68f0790a0b0f3b5c4d43f59f235b7d20fef/addons/calendar/models/calendar_event.py#L710-L713


However, in the above use case, the partners identifiers are given
through the context. This explains why the attendees are not created.

OPW-2531496

closes odoo/odoo#74734

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

When the option that set default terms and conditions is set in the
invoice setting, it is not taken into account on invoices created from
the point of sale.

We are now set the default terms and conditions on the invoices created
from the POS.

closes odoo/odoo#75016

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

Courtesy of Friederike (frfa)

closes odoo/odoo#74979

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

closes odoo/odoo#74945

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

reserved_availability is expressed in move uom
forecast_availability must be in product base uom

closes odoo/odoo#74961

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

Steps to reproduce the bug:
- Go to purchase app > create a request for quotation
- click on confirm > Lock

Problem:
Date confirmation becomes invisible, and date order becomes visible

Solution:
As we have already confirmed the purchase order and the lock button only appears when the PO is confirmed,
it makes sense to leave the confirmation date visible

https://github.com/odoo/odoo/blob/13.0/addons/purchase/views/purchase_views.xml#L138-L139



opw-2612608

closes odoo/odoo#74980

X-original-commit: 4d21eafd
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>

Steps to reproduce:
Step 1: make a MO and create less than the quantity to produce
Step 2: Mark As Done (with no backorder)
Step 3: duplicate the MO and try to change the quantity to produce

Expected result: qty to produce changes as expected
Actual result: server error

Issue is due to the copied MO's `move_finished_ids` including a copy
of the cancelled finished move (i.e. the qty not backordered) so there
were 2 `move_finished_ids` for the product to produce. This resulted in
an access error since the onchange to update the `move_finished_ids`
only expects 1 move for the product to produce and results in a
singleton error.

Issue 2 of Task: 2618962

closes odoo/odoo#74864

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

closes odoo/odoo#74987

X-original-commit: 99a77602
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Steps to reproduce the bug:

- Website in another language than English
- Go to Courses (elarning) and share a title by email
- The "Thank you" message is in English no matter what the language of the website is

opw:2574385

closes odoo/odoo#74877

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

Before this commit:
No "image" metadata was available for products on the ecommerce /shop page.
As such search engines SEO will be less effective.
Using "Google Search Console" would give the message:
 `Missing field 'image'` as a "Top Warning"

Note:
This issue was introduced by:
https://github.com/odoo/odoo/pull/30656
and was partially solved by:
https://github.com/odoo/odoo/pull/37870/commits/c66892e65d2ae0ca31a686f65d4b517a9d7ffd0b



opw-2509546

closes odoo/odoo#74907

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

Steps to reproduce:

  - Install Inventory and Studio modules
  - Go to Inventory -> Products -> Products
  - Open Studio
  - Click on Reports tab
  - Select `Product Routes Report`

Issue:

  Traceback is raised.

Cause:

  No 'product_id' provided in data while getting report values.

Solution:

  If no `product_id` key or value in data, set `docids` (or an empty
  list if no docids) as product_id and set 'warehouse_ids'
  to an empty list.

opw-2619142

closes odoo/odoo#74928

X-original-commit: de6b1636
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>

Issue:

  In an action, if we add to the context a key `search_default_x_ids`
  (who is a many2many field) with an array of ids as value, it will
  display/use only the first value in the search bar.

Cause:

  If filter-type is 'field' and it's an array, it will take the first
  value.

Solution:

  Take first value of array only if field-type is a `many2one`.

Inspired by Odoo v13.0

opw-2596345

closes odoo/odoo#74839

Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>

Issue: When creating a Meeting with quick_create (click and slide), the creator was not invited but is attending, since he was not invited, he cannot change his status to Accept, Decline, or Uncertain

Steps to reproduce :

 1) Go to Calendar (On the main view : Calendar view)
 2) Click to create a meeting, enter a Summary and press create
 3) Click on the meeting you just created
  3a) Optional: Edit the meeting and go to Invitations tab, you are not invited.
 4) Click on "Needs Action" to change your attendee state to Accept
 5) Refresh the page
 6) Click on the same meeting
  6a) Optional: Edit the meeting and go to Invitations tab, you are still not invited.
 7) Bug, your attendee state is still "Needs Action"

Why is that a bug:
With quick_create, there is no partner_ids given to the vals_list of create(), therefore _default_partners the default is triggered on the creation of the event that adds self.env.user.partner_id to the partner_ids.
However, for attendee_ids, there was no default, so if the key attendee_ids isn't present, nothing is done, which is what happens on quick_create since no attendee is added since we add them via the partner_ids (line 714) that isn't present
Not an attendee means no attendee_status

Side Note: The business flow was already that way, since the self.env.user.partner_id was added by the default of partner_ids in quick_create or in normal create. The problem was that the attendees_id of val_list on line 714 was taken from the partner_ids before the default of partner_ids was triggered.
On the normal create, it wasn't a problem since the meeting creator partner_id is filled when loading the normal create view, but on quick_create that view is never loaded up, so the default of partner_ids is created on line 721 when the event is created, adding the current user in the partner_ids of the event, but without modifying the attendee_ids

opw-2538295

closes odoo/odoo#74829

Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>

 the data dom:autoMoreMenu:adapt was added, so that the external
 code can update the menu directly when needed

closes odoo/odoo#74677

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

Issue: When changing a settings and saving, all the operation types (stock_picking.type) that had a code different than incoming had their Show Detailed Operations (show_operations) forced to be True, even when the change in settings was totally unrelated

Steps to reproduce :
 1) Go to Inventory (stock) / Configuration / Warehouse Management / Operations Types
 2) Find or create an Operation Type with Type of Operation set to something else than Receipt (incoming)
 3) Ensures that the checkbox Show Detailed Operations (show_operations) is **unchecked**
 4) Go to Settings and check or uncheck any setting, for example Permissions > Default Access Rights
 5) Save
 6) Go back to the Operation Type seen before
 7) Show Detailed Operation is now **checked**

Why is that a bug:
 The intended behaviour was to check that Show Detailed Operations box every time we change group_stock_multi_locations, group_stock_production_lot, or group_stock_tracking_lot from **unchecked to checked**, but the actual behaviour was to check that SDO box every time one of the **3 was checked when changing settings**

opw-2604730

closes odoo/odoo#74786

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

Steps to reproduce

- On a DB with german localization and SKR04 chart
- Accounting > Configuration > taxes
- Select Steuerfreie Ausfuhr (§4 Nr. 1a UStG) or
  Steuerfreie innergem. Lieferung (§4 Abs. 1b UStG)

Issue

The tag l10n_de.tag_de_intracom_community_delivery doesn't appear

opw-2545462

closes odoo/odoo#74815

X-original-commit: 21d02671
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: guva-odoo <guva-odoo@users.noreply.github.com>

Before this commit, It was setting first available account as default regardless
of it is deprecated or not.

With this commit, we are excluding deprecated account as default.

Fixes #74280

closes odoo/odoo#74386

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

If you use firefox and have set cookie to be deleted when you close
firefox, server worker are nuked which cause an error to be shown in
website_event_track:

https://bugzilla.mozilla.org/show_bug.cgi?id=1429714



With this fix, the error is handler and shown in the console instead of
as a traceback to the user.

opw-2556734

closes odoo/odoo#74885

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

Steps to reproduce the bug:

- With Studio add fields: Prorated revenue, Followers (Partners) in the view crm.lead view form
- With Studio add field: Created on on res.partner view form
- Try to edit an existing opportunity by changing Expected revenue

Bug:

A traceback was raised because NewId was in self

opw:2613125

closes odoo/odoo#74854

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

When an option notifies that it was used, its ancestor SnippetEditor
instances were in charge of asking for an UI update of all their options
(see [1] where this was already fixed). This was inconsistent with the
logic of our UI where the value of one option might affect the value and
visibility of another option which comes *after* it, e.g.:
- the user sets a badge type to 'info'
     -> the badge background option (below) is shown as blue
- the user adds a shadow
     -> more options are shown afterwards to control it (not above)

After this commit, we now update the whole editor panel (parent and
child options) wherever the updates come from. The only important thing
is to first update the options UI then their visibility as their
visibility may depend on their UI status.

This allows at the same time to fix the source of a race condition, as
enabling a snippet also triggers an UI update whose async parts were not
properly awaited (which thus may lead to inconsistencies if the user
clicked everywhere in the DOM too quickly).

Note: this commit has been made as stable as possible. In master, it
will further be improved (check the forward-ported version).

[1]: https://github.com/odoo/odoo/commit/7623a0c771495cd41bf40af37c0d2b6e4beb7cdc

Part of https://github.com/odoo/odoo/pull/74861



closes odoo/odoo#74861

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

The editor panel keeps tracks of the SnippetEditor instances which are
enabled at the current time. When previewing one (by hovering its UI),
that tracking was messed up making onFocus and onBlur calls inconsitent.

Part of https://github.com/odoo/odoo/pull/74861

How to reproduce the problem:
- Install the repair App
- Repairs -> Create (a Repair Order) (and activate the debug mode)
- Change the Location Field to something else (than the usual default WH/Stock)
- Open Developer Tools -> Set Defaults
- For Defaults, choose "Location = [the changed Location]", "All Users" -> Save Default
- Create a new Repair Order: the Location is not set to the default we set earlier through the Developer Tools

Cause of the problem : an Onchange method was overriding the default Location

Solution : it will now check, in the onchange, if the change is necessary, before overriding the default.

opw-2545876

closes odoo/odoo#74847

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

When getting the remaining days before the deadline of an activity, the
module applies the TZ offset on the deadline date. This leads to
incorrect data.

To reproduce the error:
(Need crm)
1. Configure your computer:
    - TZ: America/Anchorage (UTC-8)
2. Log in DB
3. Ensure user's profile has the correct TZ
4. Create a lead
5. Schedule an activity A:
    - To Do
    - Due Date: tomorrow
6. CRM > Sales > My Activities

Error: The deadline of A is "Today" instead of "Tomorrow"

To get the days difference, the module computes the current date in
user's TZ. Then, it takes the deadline value and applies the offset
between UTC and user's TZ to this deadline value. Eventually, it
compares the two dates.

Here is the problem: the deadline is a date, not a datetime. As a
result, when applying the offset, if the user's TZ is a "negative" one
(UTC-...), it will change the date to the previous day.

For instance, suppose current date is 2021/08/06. In above use case, the
deadline is 2021/08/07. When comparing the dates, the deadline
(2021/08/07 00:00:00) becomes 2021/08/06 16:00:00 (because we are
UTC-8), thus the module will display "Today".

We shouldn't add any offset on a date field.

OPW-2448835

closes odoo/odoo#74820

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

If we have a reconciliation model having a rule using a regex, we are extracting
the balance from the label, but we should not raise an error in case the regex
is matching an incorrect float value, and just set a zero balance instead.

closes odoo/odoo#74835

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

Fine tuning of 02d9b51e

Steps:
- Install l10n_fr_pos_cert
- Open POS session with French company
- Add product
- Hit backspace: set new quantity to 0
- Hit backspace again

Error will be shown. This occur because `event.detail.buffer` might be null

closes odoo/odoo#74711

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

Previous fix commit 5e34a02c was too aggressive in when it would delete
the move_finished_ids. In certain use cases it would result in no
move_finished_ids and a corrupted MO:

Steps to reproduce:
1. Create a new MO
2. Save the MO (do NOT confirm)
3. Update the qty to product_qty (qty to produce)
4. Confirm + Mark As Done

End result: "qty to produce must be positive" error whenever MO was
attempted to be completed and MO can never be completed.

To fix this, we split out when the move_finish_ids. They should all
be deleted ONLY when the product to produce is changed. Unfortunately to
cover all cases, we must always wipe the moves whenever the product is
changed (e.g. when changing the product twice with the original product
being the final saved value, we have no way of knowing to keep the
original move_finished_ids due to onchange only being able to check
against the last saved value, not last selected value).

Additional test + test update done to support preventing this
catastrophe in the future.

Part of Task: 2618962

closes odoo/odoo#74831

Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

That ID was removed with c8c8eb3d, but the JS code is expecting to find
this ID inside the DOM to increment the flag counter.

Courtesy of @dwa-odoo
Spotted while working on task-2167561

closes odoo/odoo#74810

X-original-commit: 2e3f7856
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>

No need to keep it, it's useless and can confuse translators

closes odoo/odoo#74782

closes odoo/odoo#74812

X-original-commit: 257fc296
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

We need quantity in tax line and we added from this PR https://github.com/odoo/odoo/pull/73402


but after it creates a problem in tax amount
because in tax line, the unit price is set base on quantity and by default is 1 but after PR 73402 it's the same as invoice line so rounding issue is there and this rounded amount is multiplay by quantity so this creates a big difference

before PR 73402:

 Name      | unit price | quantity | taxable amount |
=====================================================
 Product A | 5.55       | 8000     | 44400          | (invoice line)
 Tax 5.0%  | 1          | 8000     | 2220           |
```

After PR 73402:

 Name      | unit price | quantity | taxable amount |
=====================================================
 Product A | 5.55       | 8000     | 44400          | (invoice line)
 Tax 5.0%  | 0.27       | 8000     | 2160           |

So in this PR we remove quantity from grouping key

closes odoo/odoo#74801

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