This commit adds "Next Activities" on kanban card of partners,
like on the app Contact.

Task-Id 2152180

closes odoo/odoo#41793

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

This removes the measure_type field which has become unused and
causes issues when users try to add new uom categories.

Task-2043927

closes odoo/odoo#41056

Related: odoo/enterprise#6945
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Before this commit:
If neither Invoicing nor Accounting are installed, users are stuck with menus
items to create bank-related informations (Banks and Bank accounts). They won't
be able to set these information directly on their contacts.

After this commit:
The Bank Accounts part of the Invoicing tab has been moved from the `account`
module to `base`, so it's now visible in the partner form even when only
`contacts` is installed

Task ID: 2126832

closes odoo/odoo#40563

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

If a user changes the company of a product, we should make sure that the
product was not sold in another company in the past; otherwise it could
make some orders un-invoiceable.

closes odoo/odoo#43187

X-original-commit: 069f0493
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>

This is important so that trigger-value works
(see https://github.com/odoo/odoo/commit/e590609ebb429c6254766aa1fd8cab3ce3fd4c74

)

closes odoo/odoo#43182

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.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#43180

Task: 2119471
X-original-commit: f2a4f701
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

When switching a invoice to a refund, the bank account to which the move
should be paid should be removed: while it (might) contain the partner's
bank account before, when becoming a refund it makes no sense to keep
the partner's bank account as the recipient.

closes odoo/odoo#43176

X-original-commit: e94234f4
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>

Before this commit, the invoice creation flow of a sales order checked
if the amount of the generated invoice was positive or negative - if it
was negative, then the invoice would be converted to a refund instead.

Unfortunately, this check was done before the move was actually created
\- meaning that the only way to compute the total of the move was to
multiply the quantities and unit prices of what was about to be included
in the move - ignoring taxes altogether. Since taxes would then be
applied during the move's creation, you could in fact have a refund that
ended up being negative because some products would end up with
different taxes.

A simple (although weird) example would happen if you registered a
down payment that was actually greater than the subtotal of your
quote (but lower than the total with taxes included).
Example:
Create a quote for a 100$ product with 15% tax
Register a downpayment of 105$ and validate that invoice
Invoice the rest:
 => you end up with a refund of -10$, while you should have a 10$
invoice instead.

Since the downpayment did not have taxes, the second invoice was
computed as being negative (100$ for the product - 105$ to deduce the
down payment), even though after the 15% tax gets applied on the product
(but not on the downpayment), the invoice is actually positive.

This commits moves the switch from invoice to refund to *after* the move
actually gets created, ensuring taxes are taken into account.

X-original-commit: eefe27b1

Before this commit: all dialogs would go through the static method (OwlDialog.hide)
when destroyed, regardless of wether they had been opened or not.

Now, only dialogs having an 'el' property set (= having been opened) will use
the 'hide' method.

Task 2170705

closes odoo/odoo#43124

Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>

Before this commit, the test 'all messages in "Inbox" in "History"
after marked all as read' had non-deterministic failures.

More precisely, it crashed on either assertion "there should be 30
messages in History" or "there should be 40 messages in History",
both resulting to 0 messages in History instead.

Unfortunately, as of the date of this commit, we still do not
understand why it rarely fails. In the meantime, we have decided to
make these errors less likely to happen, by waiting much longer
before the assertions. We are aware that this is a poor solution,
but this is much better than skipping the test, until we find and fix
this issue at a later moment.

Closes #43072

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

The test may fail non-deterministically from intercepting an
heartbeat in the local storage. Only a document thread window fold
state change from the local storage should be intercepted.

Closes #43072

Revision on https://github.com/odoo/odoo/commit/141b34f152f36d970d4ff78abe53f563555a8e69

Having async/await as a new promise constructor is an antipattern.

The reason is that it may lead to unnoticed errors: if an inner
promise is rejected, it won't propagate the error to another promise
that will handle the error. As a result, this error becomes unnoticed
and the initial promise is pending indefinitely, which also may lead
to more bugs [1].

[1] https://stackoverflow.com/a/25569299

Closes #43072

Avoid double definition of the same field with different string or
help parameters. These parameters are translatable. If one has a
different value depending of the installed module, it is not possible
to properly translate it.
This problem is similar as the menu renaming debate at
odoo/enterprise@cfd4da43ee974

closes odoo/odoo#42777

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

closes odoo/odoo#43146

X-original-commit: 4d3d934c
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

"The ordered quantity has been updated." was not translated

closes odoo/odoo#43171

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

- Set the company currency in USD
- Create a pricelist in EUR
- Create a SO with the EUR pricelist
- Add a stockable product
- Click on 'Add Shipping'
- Select 'Normal Delivery Charges' which has a fixed price

The price is not updated according to the USD - EUR exchange rate.

This happens because no company is set on the delivery method, so no
conversion is performed.

We fall back on the order company, then the current environement
company.

opw-2159838

closes odoo/odoo#43167

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

Issue

    - Install CRM for example
    - Add 41 leads
    - Create an activity on each of them

    Everything ok, load more shows up

    - Add another activity on one of them

    Load more doesn't shows up

Cause

    The uniquify method:
    https://github.com/odoo/odoo/blob/saas-12.3/odoo/models.py#L4187:#L4191



    Consider the second activity as a duplicate and removes it.
    So, in `web_search_read`:
    `len(records) <= limit` is `True` and we ignore all
    the others records

Solution

    Add `force_search_count` in the context when using this action
    to avoid uniquify to falsify the records length.

    I added the tree view for this action too. It improves UX.

OPW-2165455

closes odoo/odoo#43149

X-original-commit: 13ec3503fbfb5d3d2b1e824059737bd866a3a9f4
Signed-off-by: Jason Van Malder <jvm-odoo@users.noreply.github.com>

closes odoo/odoo#43079

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

Try to understand a bit this code with comments. Some unnecessary code is
removed, and some parameters are added to try to understand the various flows,
but main purpose is to understand that mighty spaghetti, not destroy it.

LINKS

Side effect of Task ID 2056759 (remove crm.partner.binding mixin)
Side effect of Task ID 2088565 (crm onchange -> compute)
Community PR #43127
Enterprise PR odoo/enterpreise#7656

Related: odoo/enterprise#7656
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Lead 2 opportunity wizard file actually holds 2 wizards. Let us split files
especially that naming is quite obfuscated.

LINKS

Side effect of Task ID 2056759 (remove crm.partner.binding mixin)
Side effect of Task ID 2088565 (crm onchange -> compute)
Community PR #43127
Enterprise PR odoo/enterprise#7656

PURPOSE

As crm will soon evolve (onchange -> compute, code improvements, addition of
new features) cleaning and improving tests is necessary to help avoid issues.

SPECIFICATIONS

In this commit we add tests for the lead 2 opportunity converters. Indeed
it is strange that such a critical wizard has so few tests. Notably the
use of single-lead / multi-lead mode is more tested, allowing to see that
code is somewhat oldish.

LINKS

Side effect of Task ID 2056759 (remove crm.partner.binding mixin)
Side effect of Task ID 2088565 (crm onchange -> compute)
Community PR #43127
Enterprise PR odoo/enterprise#7656

PURPOSE

As event will soon evolve (onchange -> compute, code improvements, addition of
new features) cleaning and improving tests is necessary to help avoid issues.

SPECIFICATIONS

Use _tz_get for tz-based selection fields from partner as it smartly order
available timezones.

Remove a strange "event.confirm" wizard that calls an unexisting method,
is not reachable and is actually completely unnecessary.

Reorganize ticket fields to ease future improvements and perform some
public -> private method cleaning.

Remove duplicated code in event_sale.

LINKS

Side effect of Task ID 2089156 (event onchange to compute)
Community PR odoo/odoo#43127
Enterprise PR odoo/enterprise#7656

prout

PURPOSE

As event will soon evolve (onchange -> compute, code improvements, addition of
new features) cleaning and improving tests is necessary to help avoid issues.

SPECIFICATIONS

As event model grow in complexity and features, it is easier to find its
way through the application with having registration model lying in its
own file to separate it from event-specific models (event.type, event.event).

Ticket (event_sale) and sponsor (website_event_track) models are also extracted
in their own file.

LINKS

LINKS

Side effect of Task ID 2089156 (event onchange to compute)
Community PR odoo/odoo#43127
Enterprise PR odoo/enterprise#7656

Currently event_count is a computed field with a shortcut in computation for
non event user. It is better to directly limit this field to the event_user
group instead.

LINKS

Side effect of Task ID 2089156 (event onchange to compute)
Community PR odoo/odoo#43127
Enterprise PR odoo/enterprise#7656

PURPOSE

As event will soon evolve (onchange -> compute, code improvements, addition of
new features) cleaning and improving tests is necessary to help avoid issues.

SPECIFICATIONS

Clean existing tests: lessen data / variables, try to remove unnecessary
tests or merge duplicates.

Add new tests, notably event type configuration copy onto event records
is not well tested. Event computed fields are also more tested.

Some access tests are added, more a base for future addition as only a few
use cases are covered.

LINKS

Side effect of Task ID 2089156 (event onchange to compute)
Community PR odoo/odoo#43127
Enterprise PR odoo/enterprise#7656

Before the merge of account.invoice with account.move, a group of taxes was
expanded on journal items and not on invoice lines. Since both are now the
same thing, we only get the group of taxes when using the 'tax_ids' field.
To correctly handle this new behavior, we need to call 'flatten_taxes_hierarchy'
every time we use the 'tax_ids' field to get the children taxes instead of the
group of taxes itself.

[FIX] account: Wrong unit price with included tax and fiscal position

Steps to reproduce the bug:

Let's consider a sale included tax T1 of 10% and a sale excluded tax T2 of 0%
Let's consider a product P with T1 and a sale price of 110€
Let's consider a fiscal position FP that mappes T1 to T2
Let's consider a customer C with FP as fiscal position
Create a customer invoice for C
Add P on the first line and T1 is replaced by T2
Bug:

The unit price of P was still 110€ instead of 100€ because the included tax was not removed from the base
price of P.

Same behavior as in 11.0 and 12.0

opw:2150564

closes odoo/odoo#43100

Co-author: simongoffin (sig@odoo.com)
Forward-port-of: #42926
Forward-port-of: #42188
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>

The method 'test_timesheet_delivery' tests the following use case:

Test timesheet invoicing with 'invoice on delivery' timetracked products
1. Create SO and confirm it
2. log timesheet
3. create invoice
4. log other timesheet
5. create a second invoice
6. add new SO line (delivered service)
7. And finally check the AMOUNTS

But it could happen, according to the installed modules, that the class
TestSaleTimesheet, which is directly linked to
-> TestCommonSaleTimesheetNoChart (sale_timesheet)
--> TestCommonSaleNoChart (sale)
---> AccountTestNoChartCommon (account)
----> SavepointCaseWithUserDemo (base)
-----> SavepointCase (base)
is influenced by other installed modules, that in our case, introduce
new res.currency.rate values.

In our test, on the sale.order.line 'so_line_ordered_global_project',
we use the product 'product_order_timesheet2', with a price_unit=90.

Then we call manually the onchange method:
``` python3
so_line_ordered_global_project.product_id_change()
```

As the order has a pricelist and a partner, we recompute the price
unit, in case a discount applies:
``` python3
if self.order_id.pricelist_id and self.order_id.partner_id:
    vals['price_unit'] = self.env['account.tax']._fix_tax_included_price_company(self._get_display_price(product), product.taxes_id, self.tax_id, self.company_id)
self.update(vals)
```

And then , the call the _get_display_price returns an different amount
that what we expect, as
``` python3
product.with_context(pricelist=self.order_id.pricelist_id.id).price
```

will return the price converted using the related res.currency.rate
at the current date.

As we don't wish to test the conversion into another currency in this
test, we simply unlink all the currency rates, to avoid any external
influence.

closes odoo/odoo#42606

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

If the opening entry is balanced, the auto-balance line is unlinked.
However, before unlinking we test if it is balanced, which it is not. A
solution is removing the line from the move and it will be unlinked
automatically.

closes odoo/odoo#43045

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

Revision on https://github.com/odoo/odoo/commit/a55c78836f172dba1cfa6db3df0e927a9c7e6471



Before this commit, marking all messages as read from Discuss inbox
did not update the UI correctly, hence requiring a page reload.

This bug comes from a typo in the commit above, which passed a list
of mail_notification instead of message ids, so that messages were
handled as marked as read by the web client.

Task-Id 2158452

closes odoo/odoo#43109

X-original-commit: 3cc03ee3db90c310dc60fe7ea18e0e6abe741ffa
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

Activate Multicurrency
Create a Journal Entry with default currency (USD)
Save

Error will trigger because of the sql constraint
'check_amount_currency_balance_sign'
The currency_id and company_currency_id are the same while they
shouldn't because company_id should be unset if it is the same as the
company_currency.

Fix to update the error message to let the user know that it's best to
keep the field empty so the company_id would not be set

opw-2169523

closes odoo/odoo#43082

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

Steps to reproduce:
- install contacts and vat number validation
- setup your company country to "Netherlands"
- go to contacts > add a company > try to add a dutch vat number
 (NL264077921B03)

Previous behavior:
Proper vat numbers are considered unvalid and raise a ValidationError

Current behavior:
Specific check added for dutch vat numbers

Related:
http://kleineondernemer.nl/index.php/nieuw-btw-identificatienummer-vanaf-1-januari-2020-voor-eenmanszaken
https://business.gov.nl/regulation/using-checking-vat-numbers/
http://www.pruefziffernberechnung.de/U/USt-IdNr.shtml



opw-2166380

closes odoo/odoo#43081

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

opw-2169164

closes odoo/odoo#43073

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

Some library versions are outdated since the release of Debian Buster.

With this commit the required libraries versions will match as close as
possible the versions available in the current Debian stable release
(Buster).

Also, the requirements were tested against a Windows Python 3.7 to
ensure that a "pip install -r" can be used without the need of a CPP
compiler.

As Babel format_time now returns 'HNE' (Heure Normale de l'EST) for Fr
locale instead of the zone offset, the test is adapted.

Finally the babel.dates is explicitely imported, otherwise the proper
import of this submodule is relying on a side effect.

closes odoo/odoo#43106

X-original-commit: 32e455bf
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

Fix a mixup between `bounced_msg_id` that is sometimes tought as a list
of string or directly as a string.

Now `bounced_msg_id` is always a list or `False` if there is no bounce.

opw-2157793
closes #43084

closes odoo/odoo#43091

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

When accessing stock_barcode module to validate pickings, is not
possible to add floating point quantities for any localizaton which uses
',' as decimal separator.
The numeric field is now defined via browser tags <input="numeric"> to
make the numeric keyboard popup automatically on mobile devices
(commit 8f5840369b28962ab2be9edfce7331a836c3df22)
Adding the override to avoid further processing when the input
is already anumber

opw-2154657

closes odoo/odoo#42748

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

This commit reverts a previous fix because we found a better one
in enterprise.
So we don't need this line anymore.

opw-2071605
Task ID: 2152160

closes odoo/odoo#43102

Related: odoo/enterprise#7647
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>

The matrix data structure awaited by the server is the following :
{
    question_id: {
        'row_id_1': ['col_id1', ..., 'col_idn'],
        'row_id_n': ['col_id1', ..., 'col_idn'],
        'comment': 'This is a comment',
    }
}

Before this commit, the comment was encapsulated into a dict, into an array,
with an incorrect key :
    -> 'questionId_comment': [{'comment': 'This is a comment'}]

This was leading to 2 errors :
- A traceback when nothing is selected in the matrix options
- Comment is never saved.

After this commit, the comment is correctly given to and extracted by the
server. So the comment is saved and the traceback is avoided.

Task ID: 2152223

closes odoo/odoo#43086

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Aurélien Warnon <awa@odoo.com>

This commit fixes the "back button" that appears when the user is taking the
survey, allowing to go back to previous pages or questions.

There was a typo in the name of the parameter.

Task 2152223

closes odoo/odoo#43003

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

From the PoV of the customer, there is no difference between an
authorized payment and a captured payment; they should get redirected to
the confirmation page in both cases.

closes odoo/odoo#42780

X-original-commit: 45267673
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>

closes odoo/odoo#42955

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