If country is updated on a record inheriting from mail.thread.phone
its sanitized number should be computed again. Indeed without this
trigger it is not computed and may lead to inconsistencies between
phone numbers and sanitized number.

Task ID-2528169

closes odoo/odoo#70684

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

Currently phone_sanitized computation on lead model works only if crm_sms
is installed. Indeed an override of ``_phone_get_number_fields`` is missing.
However ``_sms_get_number_fields`` coming with ``crm_sms`` and its ``sms``
dependency hides the issue as those modules are auto-install. However if
``crm_sms`` is uninstalled phone_sanitized is not correctly computed anymore.

Task ID-2528169
Oversight of odoo/odoo#45315

In database with front end, there are lot of bad query like this:
bad query: UPDATE "website_visitor" SET "timezone"='Europe/Paris',"write_uid"=116,"write_date"=(now() at time zone 'UTC') WHERE id IN (15414)

closes odoo/odoo#70507

Error: Could not serialize access due to concurrent update
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

You can, in a production order, change the quantity done of a stock move
raw and change its initial demand ('To Consume' field) in the same
transaction. This can lead to some issue as changing the quantity done
will update the stock move line and changing the initial demand will
unreserve the stock move thus impacting the stock move lines too.

This commit will split the values to update of a stock in move in case
the two fields have to be updated. First the stock move lines, then the
initial demand.

This commit also remove the default_product_uom_qty in the move_raw_ids
fields. This ensure the onchanges do not create/edit any stock move lines
with some reserved quantity.

opw : 2451298

closes odoo/odoo#69377

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

[FIX] account: Partial revert of https://github.com/odoo/odoo/commit/39fb6b2990e5d6fda0d5f12dbd64d26ef77b9d0c



It seems some ppl are sharing the same bank account accross multiple journals.

issues:
2527148
2527994
2527894
...

closes odoo/odoo#70676

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

During closing a livechat session an error occur :
_get_visitor_leave_message() got an unexpected keyword argument 'speaking_with'
Because argument 'speaking_with' is pass in this method https://github.com/odoo/odoo/blob/14.0/addons/im_livechat/models/mail_channel.py#L182

, it should be operator.

closes odoo/odoo#70630

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

This commit makes few changes in the event tour as
listed below:

 * Remove the step asking user to save the event, as the next step is
   redirecting to the website which already triggers a save
 * Make the tip for website redirection appeaer in edit mode also
 * Fix a typo ("registering" instead of "registrating")
 * Instead of having to go to a specific stage, moving to any stage is
   now enough for going to next step

taskID-2446215

closes odoo/odoo#68235

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

What are the steps to reproduce your issue ?

    1. From the product form, go to the website version, edit it to add tabs
    2. Using studio, add the field "Description for website" to a tab of the notebook
    3. Save, click Edit, go to the tab that has the field

What is currently happening ?

    Traceback:
    form_renderer.js:258 Uncaught (in promise) TypeError: Cannot read property 'querySelector' of undefined
        at Class.setLocalState (form_renderer.js:258)
        at Class.setLocalState (form_editor.js:131)
        at Class.prototype.<computed> [as setLocalState] (class.js:90)
        at view_editor_manager.js:184

What are you expecting to happen ?

    Correctly add product description without tracebacks

Why is this happening ?

    Because the number of tab is not equal to the number of pages

How to fix the bug ?

    Before accessing the element, check if it exists

opw-2378743

closes odoo/odoo#70513

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

The num2words Debian package exists in Debian Buster [0] and Ubuntu
Focal [1].

[0]: https://packages.debian.org/buster/python3-num2words
[1]: https://packages.ubuntu.com/focal/python3-num2words



closes odoo/odoo#70637

Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

closes odoo/odoo#70079

Related: odoo/enterprise#18034
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>

Currently, none of the classes derived from Interface use `super`. If
it's added, for example by adding this to `SocketInterface`:

```
def __init__(self):
    super().__init__()
```

, a deprecation warning will appear in Python 3.6 and 3.7:

```
2021-04-30 13:14:25,000 24736 WARNING ? py.warnings: /home/pi/odoo/addons/hw_drivers/iot_handlers/interfaces/SocketInterface.py:11: DeprecationWarning: class not set defining 'SocketInterface' as <class 'SocketInterface.py.SocketInterface'>. Was classcell propagated to type.new?
  class SocketInterface(Interface):
```

In Python 3.8 this is no longer a warning and becomes a `RuntimeError`.

The reason this happens is that `InterfaceMetaClass` caches the results
of the `__new__` calls it does in `interfaces`. CPython's data model
specifies that when calling `__new__`, the cell for `__class__` needs to
be passed along to the parent class: https://docs.python.org/3/reference/datamodel.html#creating-the-class-object .

See https://docs.python.org/3/c-api/cell.html for a definition of what
a cell is.

Because of the caching, this doesn't happen when `__new__` is called
multiple times for the same class. In the case of the `SocketInterface`
example, `__new__` is called twice: first when it's imported directly by
`load_iot_handlers` (https://github.com/odoo/odoo/blob/841c016913a87133bf7257c62ae5f6bf7d99e06d/addons/hw_drivers/main.py#L81)
and second when `IngenicoDriver` imports it. The `__class__` cell is
different each time in that case. With the caching present, this means
the second cell isn't propagated correctly, resulting in the warning /
error.

After `load_iot_handlers` has finished, the `Manager`'s `run` method
iterates over `interfaces`, instantiating and starting the loaded
classes. Because of this, simply removing the caching appears to be
sufficient to avoid the issue while keeping the end result the same.

This issue was encountered while forward-porting a V13 PR, which adds a
`super` use to `SocketInterface`. The issue didn't occur in V13, because
the metaclass doesn't have a cache there.

I found a second problem resulting from the caching. I had noticed that
the `socket_devices` dict the `IngenicoDriver` had access to did not
have the same contents as the one the `SocketInterface` was operating
on. This means that whenever you called the `disconnect` function on the
`IngenicoDriver`, which deletes its entry from `socket_devices`, it will
always fail. The bluetooth driver seems to be impacted by the same.

It turns out the reason for that is how downloaded modules get loaded in
`load_iot_handlers`. That logic (using `exec_module`) doesn't actually
import the module, it just executes the code (registering the interfaces
and drivers as a side-effect). This means the module doesn't get cached
in sys.modules. That means that when another module (`IngenicoDriver`)
imports that same module (`SocketInterface`), Python will execute the
entire contents again, in this case effectively replacing socket_devices
with a new dict, which `IngenicoDriver` gets a reference to, while the
`SocketInterface` thread that runs is still using the old reference to
the original dict. Meaning the two are out of sync. See
https://docs.python.org/3/reference/import.html#the-module-cache for
details on how the import caching works.

The reason the classes get out of sync is because the metaclass doesn't
update interfaces when the second actual import happens, so the
`SocketInterface` class that gets instantiated holds a reference to the
old `socket_devices` dict. Removing the caching removes that problem as
well. If there's no caching, both the `SocketInterface` class and
`IngenicoDriver` will hold a reference to the same instance of
`socket_devices`.

This commit was originally part of a larger commit related to an
Ingenico double connection deadlock bugfix in V13, but in V14 most of
the related code has moved to enterprise. When a driver thread is
running, calling `disconnect` on it will delete it from iot_devices. If
the driver thread gets added to iot_devices in the Interface thread
after starting it, this means there is a tiny window of time where
`disconnect` could be called and the thread wouldn't be in iot_devices
yet, resulting in an exception. This change puts the driver thread in
iot_devices before starting it, avoiding that scenario and the need to
check in `disconnect` for that happening.

When we get the values to embed to pdf, these values can be False if
there is no edi attachment on the account_move so try to assign something
to 'values' will fail.

Now there is a check before assignment.

opw-2526280

closes odoo/odoo#70613

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

Create a draft payment with payment type and 0 amount.
Save.

The payment type will be overwritten

opw-2495461

closes odoo/odoo#70603

Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>

Acronyms:

SRL : receivable lines in the session's account move that balances
the receivable lines in the session's invoices
IRL : receivable lines of the invoices in the pos session

When closing a pos session, a single account move is created to capture
all the transactions, but, invoices are kept (each is an account move).
During the construction of this single account move, SRLs are
reconciled with IRLs.

Prior to this commit, when closing a pos session, SRLs are grouped
by `property_account_receivable_id` of the partners in the invoices.
Because of this, SRLs are blind of the partners that they are linked
to. This causes issues on tracking the 'due' in the partners that are
invoiced using the pos application.

To fix the issue, we now group the SRLs by partner before reconciling
them the the IRLs.

Same concept is employed for receivable lines generated from split
cash payments, we also assigned partner to them if applicable.

closes odoo/odoo#70580

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

Bug
===
1. Create an event which allows track proposal
2. Follow it and subscribe to "New Track"
3. Log in in incognito and submit a proposal

The email is not sent, because it's sent as the public user, which has
no email address set. And so it the 2 system parameters
<mail.catchall.domain> and <mail.default.from> are not set, we can not
know which email address used to send the email.

Note that this bug also occurs if you create a track with a user without
an email address set.

Task 2510181

closes odoo/odoo#69890

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

Create a payment like follow:
- Payment type: receive money
- Partner type: customer
- Destination account: whatever receivable
- Amount: define an amount (i.e. 90.00)
On Save, open the draft jounral entry created.
Lower the liquidity or counterpart amount and add a writeoff
Go back to the payment, change the amount and save.

The journal entry writeoff will swap from debit to credit at every
change made to the amount. This occur also when changing currency on the
payment

opw-2475223

closes odoo/odoo#70303

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

If you modify an archived warehouse, it may happen that the associated operations get unarchived. Operations should be active only if their warehouse is active.

closes odoo/odoo#70553

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

closes odoo/odoo#70534

X-original-commit: 44e05cd8
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

[REF] models: use stock to implement location_out_id into the Putway Rules Menu

Description of the issue/feature this PR addresses:

On the Location/Location-ID/PutwayRule we have the fields:

location_in_id = When Product Arrives

locatio_out_id = Store To

As the products arrives in the WH/STOCK location and due the putaway rules goes to other location then we have the fields populated like:

location_in_id = WH/Stock

location_out_id = location opened in the view.

Due this domain setup the list is returning empty, and then the solution that I applied is to check if we have the location selected in the location_in_id or location_out_id and show the entries.

Current behavior before PR:

Only looking for the from into the location_in_id

After PR merged :

Looking for the values from the location_in_id or location_out_id.

--

TaskID: N/A
Fixes : PR 67198
Closes : PR 67198

I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

X-original-commit: cd7133f0

A revamp of the scss of 's_share' in '14.0' has caused an issue with the
class '.o_wevent_social_link' of 'website_event', making a wrong
alignment of the social media icons used in this module, especially in
'event_templates_page_registration'.

For this reason, this commit fixes this issue by setting the display of
the '.o_wevent_social_link' class as an 'inline-flex', vertically and
horizontally centered.

--

task-2508497

closes odoo/odoo#70335

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

Using a fiscal position to map a tax to a price-included tax doesn't work.

closes odoo/odoo#70382

X-original-commit: 48ea669e
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

- Share outstanding accounts between multiple journals
- Create payment for each of them
- Go to dashboard
=> "Outstanding Payments/Receipts" amounts are wrong

closes odoo/odoo#70262

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

Use Case
--------
Have two (or more) rules with mutually exclusive domain for that can be
apply on the same event with lead_creation_basis = order

Create a registration that match one of the rule

Problem
-------
The lead for this rule is created properly but there is also
another lead with the name False - False that is created for the second
rule for which the registration does not match the filter

Solution
--------

Create a lead only when there is a non empty record set in the
registration group

closes odoo/odoo#69853

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

Translation "Let's go"
Makes a Transifex search text:'Let\'s go'
That should be converted to q=text%3A'Let%5C%27s+go' in the URL

Removing the ' works from time to time but not always

closes odoo/odoo#68651

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

The _get_lead_days() method does two things:
1. Compute the lead day depending on the product to replenish
2. Build a string explaining what are the parts of this day number

This second part is optional at the Replenishment report opening.
As the string is translatable, this impact quite significantly the
performance of this opening.

closes odoo/odoo#70351

Opw: 2519528
Related: odoo/enterprise#18202
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

Make `seller_ids` `depends_context` of company to
avoid shared cache with different company. The purpose
is to avoid making a SQL search for each `_prepare_seller` and use
the ORM cache (which depends of the company in env).
Also change the `_order` of `product.supplierinfo` to be
determinist and consistent with the `_prepare_seller`.

task-2439019

The loop on `to_refill()` call `browse()` on the product one by one.
This doesn't make use of the cache when accessing product attributes
like route_ids or categ_id.

opw: 2519528

Performance improvement for missing products computation.
- Call _prepare_sellers only once
- _compute_quantities works in batch for product with the same
context. Use this advantage to speedup the computation of virtual
available for each warehouse and delivery date.

What are the steps to reproduce your issue ?

    1. Go to Account/Journal Items
    2. Open a posted item
    3. Change product

What is currently happening ?

    The product is changed in the account move

What are you expecting to happen ?

    The account move lines cannot be changed when the status is posted

How to fix the bug ?

    Make the field read-only when the status is posted

opw-2517325

closes odoo/odoo#70514

X-original-commit: 0b0cd8fa
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>

BEFORE this commit query "invoices is not set" was tranformed to
query "order_line.invoice_lines.invoice_id is False", which doesn't make sense,
because invoice_id is required fields and hence always set. Hence, result of
the query was always empty.

AFTER: just check that there is no invoice_lines. Strictly speacking, is not the
same as checking result of compute method, but because invoice_lines are
supposed to be lines for invoices of out_* type, the result should be the same.

---

opw-2516124

closes odoo/odoo#70493

X-original-commit: 540b45cc
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>

Base: seems related fields take only 1 extra query instead of 3

Crm: assignment seems to have been slightly improved. Some randomness still
happens.

Hr Holidays: seems it was further improved beyond space frontier

Test mail: those tests were a bit random, seems random is gone (hopefully)

Test mail full: updated local counters

Test mass mailing: seems we gained one query, updated local counters

closes odoo/odoo#70486

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

Steps to reproduce the bug:

- Let's consider a delivery carrier DC with invoice policy = 'real'
- Let's consider a consumable product P with a weight = 1kg and sales price = 10€
- Create a sale order SO with 2 P and add DC as shipping cost
- Process the shipment for 1 P and create a backorder
- Process the second shipment with the last P

Bug:

Two lines L1, L2 with DC were created on SO but only L1 as a price unit and a description.
L2 had a price unit = 0€ and no description.

opw:2520135

closes odoo/odoo#70454

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

- use real join
- skip useless join on res_users and gamification_challenge
- skip null end_date criteria to compute less reached goal

closes odoo/odoo#69668

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

Before this commit there would be trackback (TypeError: unsupported operand type(s) for -: 'datetime.datetime' and 'NoneType') when you will try to remove field Start date as we are using the field to compute duration.

With this commit, we compute duration when Both fields are present.

closes odoo/odoo#70466

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

Disable the link on the forecasted inventory report  graph view, as it leads us to a undesired list view with traceback on opening it.

closes odoo/odoo#59448

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

* IMPACTED VERSIONS

  12.0+

* HOW TO REPRODUCE

locale :  Locale is en_US (or other SUNDAY based)
view:     CRM - My Pipeline - Kanban view
groupBy:  date_deadline:week (Expected closing)
records:  one record with a planned activity, on date_deadline = 2021-05-02 (SUNDAY)
          one record with no planned activity, on date_deadline = 2021-05-09 (SUNDAY)
remark:   don't keep any other record in MAY for better visibility

* PROBLEM

The progressbar of the week containing 2021-05-09 displays information about the record
from the week containing 2021-05-02

* CAUSE

1. PostgreSQL `date_trunc` function follows ISO8601 which essentially means that
  the start of a WEEK is always MONDAY. There is no argument to change this.

2. _read_group_format_result
  https://github.com/odoo/odoo/blob/27da86a138089c1838e4b94f8a6976995b9c1fff/odoo/models.py#L2210-L2219

  - Computes a label for a group of records.
  - Follows the locale for the label of the week, based on a date which is
    always a MONDAY because of `date_trunc`.

3. read_progress_bar
  https://github.com/odoo/odoo/blob/88957afca09662af7eaa19df1e40b3699e45e79e/addons/web/models/models.py#L167-L175



  - Associates a group label to a record.
  - Follows the locale for the label of the week, based on the date of a record
    which can be any day of the week. If the record is related to a SUNDAY and
    SUNDAY is the first day of the week, it would have been in a group with a
    different label in (2.) than in (3.) prior to this change.

* FIX

In 3., before associating a label to a record, we truncate the date to the
ISO start of the period, so that the label is determined for a record in the
same conditions than in 2. The locale is still used to get language-dependent
outputs with babel, but the grouping will always follows ISO8601 (date_trunc).

* TEST

Added a test for this problem case

TASK-ID : 2517848

closes odoo/odoo#70453

X-original-commit: c08f6e3e
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Remove the optimization of the `product_tmpl_id` related fields which
needs a upgrade to work without any issues.

This reverts partially the commit
4c627651.

Find a other for the stable to optimise the forecasted report of product
template:
When the `product_tmpl_id` is in the domain of a read_group, it will
be replace by a equivalent clause with `product_id` instead to avoid
any sub-query which didn't help the postgreSQL planner.
The performance decrease but it still acceptable compared that before
the revert fix (test with one template with 256 variants in
a DB with 40K products and 100K moves, 1K locations, etc)
- Revert fix (which need a upgrade): 75 ms
- new fix (no need a upgrade): 130 ms
- without any fixes (before the revert fix): 500 ms (also have a bigger
scale penalty)

closes odoo/odoo#70381

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