The discount_amount didn't consider the quantity on Sales Order Line.

e.g:

100€ | 10% discount | 8 products

--> discount_amount was 10 € instead of 80€

Fixes #43242

closes odoo/odoo#43587

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

PostgresSQL TRIM function does not trim line return and other space characters
that are not white space.

For references having a non trimmed character regexp_split_to_array would create an array
with an empty element. Such element could be matched to a counterpart with no numerics in
the reference.

TRIM(' \n001') => '\n001'
regexp_split_to_array('\n001') => {"", "001"}

By replacing the TRIM function by a substring using a regexp we
also remove the other space characters such as tab and line return.

closes odoo/odoo#43425

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

We optimize the search on domains like `[('line_ids', 'in', ids)]`.
The condition is rewritten `('id', 'in', ids1)` where `ids1` is the
result of

    SELECT <many2one_field> FROM <comodel_table> WHERE id IN <ids>

The issue is that the latter potentially returns many duplicate values.
The fix consists in having as few duplicates as possible in `ids1`.

Note that domains like `[('line_ids.foo', '=', 42)]` implicitly benefit
from the optimization, as they are rewritten as the one above with

    ids = comodel.search([('foo', '=', 42)]).ids

closes odoo/odoo#43560

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

Partial backport of d930a78f

closes odoo/odoo#43528

Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>

* website_event

Commit https://github.com/odoo/odoo/commit/a153ed42a09f8b7f5e0865112eb7d5affc22a353


solved a big problem which was that when an undo/redo is performed, the
whole DOM was reconstructed breaking all the JS relying on the old one.
For example, the latest blog posts which are dynamically loaded in JS
were not removed before saving since the JS relied on the old DOM... and
this broke the page because that dynamic content contained non-valid
XML markup. The solution was to destroy all JS widgets before applying
an undo/redo and rebuilding them all afterwards. Ideally this operation
should be done on the undo recording action but this would have a huge
flickering impact since many DOM would be destroyed each time the user
types text (flickering which is also bad on undo/redo but it is more
acceptable).

The problem now is the following: if a widget, like many, is declared
like this:

```
start: function () {
    this.$el.append(/* Some dynamic content on page loading */);
},
destroy: function () {
    this.$el.find(/* Dynamic content to remove */).remove();
},
```

Then it works in all standard cases: dynamic content is loaded on page
load and is removed when saving the editor. But this happens with the
undo/redo system:

1. The users types text, we record an undo, which is the whole page
   current DOM, containing all the dynamic contents.

2. The users hits CTRL-Z:

    a. We destroy all JS widgets, calling destroy, the dynamic content
       is removed from the page.

    b. We replace the whole DOM with the one that was saved. That one
       contains the dynamic content DOM.

    c. The JS widgets are recreated, calling start... creating the
       dynamic content again.

Result: the dynamic content appears duplicated. On save, depending on
how the destroy was implemented only the last generated content may be
removed or both... but in any case it appears duplicated during edition.

Hopefully, our current stable version do not contain that many dynamic
content so a perfect amelioration of all of this can be found in master.
As a fix, this commit introduces an extra step between (a) and (b):
we remove the dynamic content of the DOM-to-re-apply before applying it.
For this to work, widgets have to mark their dynamic content with the
class 'o_temp_auto_element' when creating it. They also must add the
content they replace on the 'data-temp-auto-element-original-content'
attribute.

closes odoo/odoo#43512

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

The filter for Purchase orders in the Purchase report did not filter out Sent RFQ,
despite the fact that they were not really ordered yet.

opw:2158248

closes odoo/odoo#43526

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

partial backport of 88681f8f

opw-2171237

closes odoo/odoo#43497

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

As Mitchell Admin:
- Install Leaves
- General Settings > Multi Company
- Create companies A (YourCompany) and B
- Mitchell Admin should be an employee of A, not B
- Switch to company B
- Go to Leaves > Managers > All > Allocations

An AccessError is raised in `_compute_number_of_hours_display` because
we try to access `employee_id.resource_calendar_id.hours_per_day`.

After this AccessError is solved, several others are raised when
accessing a record. They are solved in this commit.

opw-2160542

closes odoo/odoo#43485

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Apparently some solutions (e.g. bitnami) deploy odoo using async
workers, and not all pg/psycopg2 features are supported in that mode,
notably COPY FROM (bulk-copying data from a stream to postgres). Work
around this issue by disabling "async mode" as we do the copy (by
resetting the wait callback) then re-enabling it.

While this is not an officially supported run mode, it should Do No
Harm™ for normal operations and could help users and clients.

Of important note: while this fixes an error running in async mode, it
will also prevent the worker from yielding while copy_from is
executing. Hopefully that doesn't take too long (as the entire point
of the copy_from is to be fast) but there you are.

Fixes odoo/odoo#24145

closes odoo/odoo#43465

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

Have more than 160 records in a model (i.e. Contacts).
Create a sale order, search for customers clicking on Search More,
do a search that will target records over the 160th.
Save the search as favorite and put as default.
Close and reopen the search widget.

No records will display even if there should be, because after the
search widget applied the domain specified by the favorite filter
it will apply also the initial ids, fetched whitin the first 160
records, thus making the resulting set void.

Avoid applying the initial ids when the favorite is specified mitigate
the issue

opw-2167573

closes odoo/odoo#43482

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

Before this fix, if the communication method was set on neither partner
neither invoice number, the communication was considered as based on
partner.
After this fix, if we didn't choose a communication method, the
communication stays empty.

closes #29735

closes odoo/odoo#29736

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

Keep the same UOM than the MO.

opw-2169377

closes odoo/odoo#43398

X-original-commit: 942154b3
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Steps to reproduce the bug:

- Let's consider a product template P with an internal reference = I
- Archive P
- In the list view of product template select the Archived filter and
search for I with the Product filter

Bug:

P was not found.

opw:2169441

closes odoo/odoo#43395

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

Do not crash if the commercial partner doesn't have a name.

opw-2158809

closes odoo/odoo#43387

X-original-commit: c70122e673579cd5f7338b6e54dae1d1445945e7
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

If we are:

- not in sudo
- computing a compute field
- using a related_sudo field

we want to keep the env._protected dictionary when we `sudo` to get the
related value, because if we don't we lost the protection of field we
were currently computing.

Original description:

> When a "computed value A" relies on "computed value B" and
> "computed value B" needs a related value (e.g. product.product from
> product.template), then "_compute_related" in api.py will copy the
> cache if the user is not superuser.
>
> The cache is not copying the values in "_protected", causing
> "modified_draft" in fields.py to incorrectly invalidate the cache for
> already computed values which should be protected by their inclusion
> in "_protected".

note: the added test does not fail without this change, it is just a
partial backport of 12.0 to ensure what worked still worked.

opw-2146097
closes #40916
closes #42714

closes odoo/odoo#43376

X-original-commit: 97bdb7a668b5c4c9ad759fc795e859207b6ed28d
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Co-authored-by: Nicolas Lempereur <nle@odoo.com>

When saving the content of an oe_structure, the starting text nodes
were lost because only the internal *elements* were considered. Ending
text nodes were kept since they are considered as the last element's
tail by the etree library.

task-2040764

closes odoo/odoo#43016

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

We added min-height for `o_form_sheet` in form view with a commit[1] restoring
the views design (after views refactoring).

However, the min-height isn't very useful when form view is opened witin a
modal (FormViewDialog). Especially, when the form view is having only few
fields, the `o_form_sheet` container occupies unnecessary height and looks
a bit ugly.

This commit fixes the issues by setting the min-height to `0` for
`o_form_sheet` container in such cases.

[1] - https://github.com/odoo/odoo/commit/250e716c3a12#diff-01e46b3171a7282967199e5d45fca0e6R15



TaskID: 2150471
PR #41619

closes odoo/odoo#43336

X-original-commit: 8b030ede
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Description of the issue:

Transfer between Bank1 (550001) and Bank 2 (550002) of the same company via the intercompany bank account (580000) :

Bank 1: minus 1000 EUR, we create the following accounting entry via the reconcile widget

account 550001 credit 1000
account 580000 debit 1000

Bank 2 : Plus 1000 EUR

When we select the counterparty 580000 entry of the Bank 1 statement via the reconcile widget
than the statement_line_id of the entry from Bank 1 statement is replaced by the one of the Bank 2 statement.
Hence this account.move.line is linked to the wrong statement line.

closes odoo/odoo#42339

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

Since this field is not required on res.partner.bank (which is fine: we want it to be synchronized with the journal's currency, which is None if the journal uses company currency), the parameter received by validate_swiss_code_arguments ended out being an empty recordset in case the company was directly in CHF. This caused the QR code to never be displayed in this situation.

closes odoo/odoo#43282

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

- Create 3 products: A, A1 and A2
- Create a BOM kit: A is a kit containing A1 and A2
- Purchase 1 unit of A
- Receive the quantities

The Received Quantity is set to 2 instead of 1.

This happens because `_update_received_qty` is not called as expected.
Indeed, `purchase_mrp` must depend on `purchase_stock` since it
overrides `_update_received_qty`.

opw-2166749

closes odoo/odoo#43097

Related: odoo/enterprise#7712
Signed-off-by: Christophe Simonis <chs@odoo.com>

Previous versions of this action had a context. It was removed at odoo/odoo@2d3e6d7383aaa3c1589f22
Set explicitly an empty context to force the removal when upgrading the module. Fine tunning of odoo/odoo@93465630090e2c42

closes odoo/odoo#36007

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

The `unsubscribe` feature of mass mailings repose on having a link with
HREF attribute `/unsubscribe_from_list` inside the mail message.

When the mass mailing is sent:

- relative URL are replaced by absolute URL (`/unsubscribe_from_list` is
  replaced by `{system parameter web.base.url}/unsubscribe_from_list`)

- `{system parameter web.base.url}/unsubscribe_from_list` is replaced by
  the real mass mailing link containing info that will be used to
  unsubscribe the user.

But there was an issue in the case of multiple domain, if this scenario
happened:

- system parameter web.base.url is http://domain1
- a user use "Test" button on a mass mailing
- system parameter web.base.url becomes http://domain2


- the mass mailing is sent

The unsubscribe link is broken, this is because the implementation of
"Test Mailing" feature would update the mass mailing with absolute
links, so if the domain change, we the `unsubscribe` link will no longer
be found and replaced into the source.

opw-2124890
closes #42373

closes odoo/odoo#43277

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

Fixes https://github.com/odoo/odoo/issues/43122


Before this commit, Creating Journal without Bank account number will be failed as, It tries to update Related field 'l10n_ch_postal' while bank_account_id is not set.

In this commit, we update 'l10n_ch_postal' if 'bank_account_id' is present on Journal

closes odoo/odoo#43158

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

- Create the FIFO & Automated products:
  Kit ABC: 2 variants, e.g. Black and White, invoice on delivered qty
  Kit A
  Kit B
  Kit C
- Create the BOM for the variants of Kit ABC, in this order:
  Black: 1 unit of Kit A and 1 unit of Kit B
  White: 1 unit of Kit A and 1 unit of Kit C
- Receive the components
  Kit A: 10 USD
  Kit B: 12 USD
  Kit C: 13 USD
- Create a SO for Kit ABC (Black)
- Validate the picking, create and validate invoice

The COGS is incorrect: the amount is 23 instead of 22.

This happens because the BOM selected is always the first BOM of the
product template instead of the product-specific BOM.

We select the BOM the same way it is done when it is exploded in:

https://github.com/odoo/odoo/blob/95348a5e1dc4e69ce0edaf89de1124fe55ce4ec8/addons/mrp/models/stock_move.py#L161



Note that if the BOM changed between picking creation and invoice
validation, it will fail.

opw-2153629

closes odoo/odoo#43266

X-original-commit: 7714f7ca
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Nicolas Martinelli <nim@odoo.com>

The option is supposed to be supported:
https://github.com/odoo/odoo/blob/3316fd49247d14dd2ab39c1267ed940feafdc664/addons/web/static/src/js/views/pivot/pivot_model.js#L363



Closes #39692
opw-2169539

closes odoo/odoo#43255

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Steps to reproduce the bug:

- Install Sales
- Configure Paypal payment acquier
- Add extra fees such as 10€ of domestic fee
- Create a customer C with an email E and with no country
- Create a quotation Q of 100€ for C and send it by email to C
- Go in the email box of E and click on the link
- Click on 'Sign and Pay' button
- Sign Q and click on 'Pay'
- Choose Paypal as payment acquier
- Process the payment with Paypal

Bug:

An error log was displayed saying:

Paypal incorrect data:
mc_gross received 100 instead of 110

PS: the domestic fee was not counted because the partner_country_id
was not set in function render defined in model payment.acquirer

Inspired from function create defined in model payment.transaction
(addons/payment/models/payment_acquirer.py +961) where the domestic fee
is counted.

opw:2167104

closes odoo/odoo#43197

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

Before this commit, if the records had to be sorted according a
many2one field, and there was a sequence field on the many2one
comodel, the sequence was ignored. Now, the sequence is taken into
account like the actual server does.

Linked to odoo/enterprise/pull/7407

closes odoo/odoo#42595

Related: odoo/enterprise#7407
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

https://github.com/odoo/enterprise/pull/7407#discussion_r362451701

opw-2128922

`purchase_stock` is a required dependencies because the `stock.rule`
`stock_rule_drop_shipping` use `buy` as `action` [1].
However, it is added to the selection by the module `purchase_stock` [2].

[1] https://github.com/odoo/odoo/blob/c4b6273c9df5d8e3f3a5ee3cf52541741526280e/addons/stock_dropshipping/data/stock_data.xml#L32
[2] https://github.com/odoo/odoo/blob/c4b6273c9df5d8e3f3a5ee3cf52541741526280e/addons/purchase_stock/models/stock_rule.py#L14



closes odoo/odoo#43218

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

[FIX] mail: fix issue when posting a message on a document whose first message / parent is not readable

How to reproduce
================

Have a portal user commenting a task on the customer portal. He may experience
a crash if previous message / first message is not available, for example
if it is internal or not published.

This is due to reference computation used in outgoing emails as it is based
on parent messageID. Accessing it crashes although it should not as it is
used only for technical purpose.

Fix
===

In this comme we fix that issue by browsing the reference message as sudo
to access its messageID. A test is added to avoid regressions.

Task ID 2061760
PR #36845

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

Steps to reproduce the bug:

- Create an analytic account AA
- Create a journal entry with a debit(L1) and a credit(L2)
- Set an analytic account on L1
- Validate the journal entry and an account analytic line AAL has benn created
- Go on the journal item  L1 by the menu Journal Items
- Remove the analytic account of L1

Bug:

The account analytic of AAL was still AA

The AA of a journal item cannot be changed when the entry is posted.

opw:2158057

closes odoo/odoo#43214

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

Steps to reproduce:
- install sales
- go into debug mode
- dev tools > start tour > sale_tour

Previous behavior:
tour would fail after creating the "Agrolait" partner.
the test would not wait for the return value of the
customer selection.

Current behavior:
the test waits for the customer to be fully selected and does not fail.

closes #40569
opw-2091797

closes odoo/odoo#43172

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Steps to reproduce the bug:

- Create a Sale Tax T and the field account_id set and let the field refund_account_id empty
- Create a customer invoice CI with a line with T
- Validate CI
- Add a credit note and fill the reason
- Click on 'Add credit note'

Bug:

An error was raised.

opw:2154932

closes odoo/odoo#42488

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

Followup to odoo/odoo#43117 (backporting from something which breaks
in 12.3): if the o2m somehow has an id field, this field should be
ignored when extracting values to save, for the purpose of both
actually saving and extracting values for e.g. default_get.

closes odoo/odoo#43204

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

In the SSF, o2m updates get initialized with no values (1, id,
{}). The record data is only fetched when the "record" gets updated
explicitly from which updates will hopefully get properly tracked &
saved.

However if the "record" was first initialized through an onchange
values which are updated by the onchange (diverging from the db) those
would not get tracked and thus wouldn't get saved when the record is
saved.

* use more specific placeholder (None) for "o2m records to update but
  we don't have values yet"
* once we have values, always store them as an update-tracking dict
* if we don't have values yet for an o2m and an onchange is trying to
  write to it, initialize with values from database first (might
  eventually be a good idea to initialize upfront though there's the
  question of what happens for default values and recursive views)
* mark anything coming back from the onchange and differing from local
  values as changed (so they get sent out on save)
* properly reify parent values for onchange instead of sending them
  as-is
* the evaluation context for contexts (and domains) needs properly
  formatted values so use `_values_to_save` to get them, however it
  cares about neither required-ing nor filtering out e.g. unmodified
  fields, therefore add an awful toggle to handle this

Task 2150302

Probably todo in the future:

* better UI for change-tracking dict, should have "snapshot"
  support (to freeze / discard previous changes)
* cleanup save, it's unclear that it properly resets the form

closes odoo/odoo#43117

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

Steps to reproduce the bug:

- Let's consider a delivery method DM with fixed price of 10€ and a margin of 20%
- Let's consider a storable product P
- Create a SO for P and get the rate (12€) but don't add it on the SO
- Confirm the SO and process the delivery

Bug:

A SO line was created for the freight cost without the margin. So it was 10€
instead of 12€.

opw:2144894

closes odoo/odoo#43083

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

It happens that people modify the product on done stock.move.line
(it's not possible without customisation, at least allow to import or
to modify product and lot_id in the same view).

During the write on stock.move.line only the lot,locations,package and
owner are update on the quant. Not the product since it's not suppose to
be modify. It leads to a stock.move.line with a correct information but
a total mess on the quants with a lot updated and the previous product.
Since the product is not modified, the product on the quant and the
product on the lot linked to the same quant are different.

closes odoo/odoo#43145

Task: 2119471
X-original-commit: 3ec96c30
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>