When a color combination was used as "color" (base case) for the menu,
the menu background in the boxed template, the footer or the copyright
section, it was not properly marked as selected in the color palette
widget of the editor panel.

Related to task-2599770

closes odoo/odoo#75132

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

Issue: When closing a PoS session, the user can Cash In/Out of the
register but it requires Accounting/Billing group or Purchase/User
group. However with Purchase/User group, there was an access right
error (not allowed to create account.move.line

Steps to reproduce :
 1) Install PoS Module
 2) PoS > Your Shop > Settings and enable Advanced Cash Control
 3) As administrator and in debug mode go to
  Settings > Users & Companies > Users
 4) Remove Accounting, Inventory and Purchase group of [User A]
 5) Log in with [User A], open a PoS Session, close it, and in Cash
 Control form, click Cash In/Out
 6) Remove or add money
 -> Access right error, you need to be Accounting/Billing or
 Purchase/User
 7) As administrator, add the User group to Purchase for [User A]
 8) As [User A], click Cash In/Out, removed or add money
 -> Still access right error

Why is that a bug:
 The first warning asks us to give the Purchase/User group to the user
 if we want to Cash In/Out but even when doing that, the access rights
 are still not enough to allow the creation of the entry

opw-2611298

closes odoo/odoo#75029

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

Got an older version without 2692dab7

closes odoo/odoo#75122

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

All accross Odoo, when a document is assigned to a salesperson, that person is notified via email.

However, the `account.move` model is inconsistent with that behavior, because the salesperson field name is `invoice_user_id` instead of just `user_id`.

With this fix:

- When creating an invoice from a sales order, the salesperson will get the assignment notification.
- When modifying the salesperson in the invoice form, the new salesperson will get the assignment notification.
- In both cases, the salesperson will get subscribed to the invoice.

This restores the behavior that `account.invoice` had in v12. For master, a better fix should be considered (a.k.a. simply removing the `invoice_user_id` field and using only `user_id` to avoid these kind of inconsistencies).

@Tecnativa TT29909

closes odoo/odoo#74074

X-original-commit: 22645694
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>

How to reproduce the problem:
- Install the sale_coupon module
- Sales -> Products -> Promotion Programs
- Create a promotion with "Fixed Amount" discount, "Apply on current
order", with Based on Products as "Name = Large Cabinet"
- Create a SO with 3 Large Cabinet.
- Modify the quantity on the new reward line: the price unit became 0.

A client should be able to manually change the discount quantity.
That was not possible before due to the fact that the reward products of
a promotion are saved in the DB with a list price of 0.
As the reward generation handles the job of computing the correct
unit price on a reward SOL, that unit price is simply re-used when
the quantity is changed.

Also corrects the case where a Free Product is different from the
Rule Product(s): with the promotion
"Buy 1 Product A, get 1 free Product B", if the Sale Order has
3 Product A, for example, the promotion will offer only 1 Product B,
while it should offer 3.

opw-2522604

closes odoo/odoo#75003

X-original-commit: 609abfa3
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Signed-off-by: prro-odoo <proose@users.noreply.github.com>

To reproduce the error:
1. In Settings, enable "Multi-Step Routes"
2. Create a storable product P
    - Available in POS
3. Update P's quantity:
    - Location: WH/Stock/Shelf 1
    - On Hand Quantity: 1
4. In a POS session, process an order with one P
5. Close the session
6. Consult P's moves

Error: The location used to sell P is Stock instead of Stock/Shelf 1

At some point, the step 5 triggers `_create_move_from_pos_order_lines`.
Because "Consignment" isn't checked in the settings, the if-blocked is
skipped and therefore the move isn't assigned:
https://github.com/odoo/odoo/blob/4bcc63cf49a8c3ab73812de3d171024aa8059b8f/addons/point_of_sale/models/stock_picking.py#L152-L161
Then, on L161, when setting `quantity_done`, it triggers the inverse
method `_quantity_done_set` which will create a SML (because there isn't
one yet):
https://github.com/odoo/odoo/blob/2841525a3a2f1273783874947884b57494def849/addons/stock/models/stock_move.py#L355-L359


but using the location of the move (i.e. Stock)

The if-condition was introduced with d59fc6c9
to fix another issue. In the meantime, another fix has been deployed for
a second issue fe4323b5 However, this
second commit also fixes the first issue, therefore the if-condition is
no longer required. As a result, `_action_assign` will be called and a
SML with the correct location will be created.

OPW-2607748

closes odoo/odoo#75090

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

closes odoo/odoo#75017

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

Backport of 14.0 PR odoo/odoo#73082 with some slight changes.

Backport of master PR odoo/odoo#62083.

Improve stock.picking._compute_state by computing pickings new state conditions
beforehand. This avoids looping through picking.move_lines for each
condition for each picking.

opw-2613931

closes odoo/odoo#74970

X-original-commit: 591a726f
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>

closes odoo/odoo#69321

Related: odoo/enterprise#17721
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

The term was untranslated
Export missing stock terms

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>