Before this commit, it was possible to drag and drop a popup inside an
oe_structure which was itself inside an other oe_structure (e.g. snippet
parallax). It didn't make sense and moreover created bugs.

After this commit, it is no longer possible to drag and drop the popup
snippet or the newsletter popup snippet in a substructure.

task-2491976

closes odoo/odoo#80836

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

When a kit is exploded to `stock.move` the quantity is rounded half-up
for every move. But during the invoice. The quantity to invoice on
kit is rounded up so it could result in differences between the
inventory valuation and the cost of the product

closes odoo/odoo#81355

Signed-off-by: Arnold Moyaux <arm@odoo.com>

Fix for task 2620026.

_get_bom_component_qty function is only referred to once in the whole odoo app,
which is on addons/sale_mrp/models/account_move.py#22.

The result returned from this function is used as a multiplier to quantity
to convert into the expected UoM. However, the quantity being referred to on
_stock_account_get_anglo_saxon_price_unit (qty_invoiced, qty_to_invoice), are
already converted into the SO Line's product's default UoM. In this function,
it however tries to convert 1 from SO Line's UoM to BoM's UOM.

With this, if Product UoM=x, SO Line UoM=y, BOM UoM=x, in the function _stock_account_get_anglo_saxon_price_unit,
the quantities will be multiplied by the same factor twice, resulting to the incorrect computation of price_unit to follow.

Part-of: odoo/odoo#81355

- Set up a POP account
- On the POP account, receive emails addressed to various recipients,
  e.g. `my_alias_1` and `my_alias_2`. Receive more than 50 emails to
  `my_alias_2`.
- In Odoo, create a mail alias for `my_alias_1`
- Run the fetchmail cron

The cron runs endlessly until it is killed. In the logs, inconsistent
messages are shown:

```
...
Fetched 3507 email(s) on pop server xxx; -16493 succeeded, 20000 failed.
Fetched 3507 email(s) on pop server xxx; -16543 succeeded, 20050 failed.
...
```

First the message count is incorrect in the log. We fetched at most 50
emails, not the total number of emails. Then, the endless loop is due
to the fact that
- we do not delete failed messages (= messages addressed to
  `my_alias_2`)
- we always fetch messages from `num=1`

If the first 50 messages fail, we fetch them endlessly until the cron is
killed.

To avoid this, we compare the number of failed messages with the number
of messages retrieved. If all messages retrieved have failed, we stop
the loop.

After the fix, consistent messages are show in the logs and the process
stops after the first complete failure:

```
start checking for new emails on pop server xxx
Fetched 50 email(s) on pop server xxx; 0 succeeded, 50 failed.
```

Note that it doesn't solve the core of the issue; we just fail faster. A
proper way would probably be to use an offset so we don't always start
at `num=1`. On the other hand, it is just a matter of time before the
cron times out: if the mailbox is full of messages which canot be
treated, we will just spend more and more time trying to find the ones
which can be treated.

closes odoo/odoo#81115

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

Goal:
The aim of this commit is to make the cogs generation multi-company
safe.

Context:

Considering the situation in which company A has set a product P with
a real time valuation and company B didn't set the real time valuation
or has set it to manual;
Considering the user has selected both company in the switcher;
The user post an invoice for the product P.

Before this commit:
There isn't any cogs created for the invoice which is wrong.

After this commit:
Whatever the selected companies are, the cost selected will always be from
the company that created the invoice.

closes odoo/odoo#81348

Task: #2713607
Signed-off-by: Laurent Smet <las@odoo.com>

Problem 1: The context was not passed when calling the resequence function.
Problem 2: Also, the subsequent read operation did not pass the full
context, but only the context of the user, not the context of the action.
A test has been added for the basic model to check that the context is properly
given after a resequence.

closes odoo/odoo#81393

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

It should be allowed to pay amount that are not rounded if the value is less than the rounding value.
Ex:
Rounding value: 0.05
Amount to pay: 0.04
The amount to pay should remain 0.04 and not be rounded to 0.05.

This fix allows the user to pay for values under the rounding value without applying the rounding.

closes odoo/odoo#81302

Signed-off-by: Masereel Pierre <pim@odoo.com>

Expected behaviour

When having multiple promotions with, for example, a promotion of X% for the
first order and a promotion of Y% (Y<X), we should apply the first promotion
on the first order and then don't get this promotion into account to choose
the best promotion for a future order, so that we have:
1. A promotion of X% on the first order
2. A promotion of Y% on every other order

Observed behaviour

When trying to apply promotion on other order, nothing seems to happen, as
Odoo take the already-used X% promotion into account, being the most
interesting promotion, select it as the best promotion to apply and then
apply it to finally get a result of a 0% discount as the promotion has
already been used.

Problem Root Cause

As it can be seen in the commit, the error comes from the fact we filtered
the available promotion with a non-strict inequality.

Validation

A test has been added in test_program_numbers.py to validate our fix

Related issue

- opw-2674681

closes odoo/odoo#80192

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Bug
===
Since 85053a8b we limited the access
of the registration to the event users. But now we want to limit the
access to the internal users.

So only the portal users and the public users will be concerned by this
restriction.

Task-2666823

closes odoo/odoo#78235

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

After paying the expense report, the lines are reconciled right away but
with this old code I can't inherit the custom reconciliation lines. So I
provide a hook method to be able to inherit and customize the lines that
want to be reconciled.

closes odoo/odoo#81267

Signed-off-by: Kevin Baptiste <kba@odoo.com>

The aim of this commit is to make the cogs generation multi-company
safe.

Before this commit:
When posting an invoice from company B with both company A and B
selected and A being selected as "main", the cost from company A could
be selected instead of cost from company A to create the anglosaxon
lines.

After this commit:
Whatever the selected companies are, the cost selected will always be from
the company that created the invoice.

closes odoo/odoo#79674

Task: #2686104
Signed-off-by: Laurent Smet <las@odoo.com>

If you create an individual contact that has a company contact as the
parent, it will inherit certain fields from that parent, which are
defined by `_address_fields` in `res.partner`.

`base_address_city` allows enforcing picking a city from a pre-defined
list, which gets stored in `city_id` instead of the standard free-text
`city` field on `res.partner`. If you change `city_id`, an `onchange`
will update `city`.

`city_id` was not being inherited from the parent, which means the
contact ends up in an inconsistent state: `city` will be set, but
`city_id` will not.

In the Colombian accounting localization, which uses the enforced city
feature, a municipality code which is part of the record behind
`city_id` is mandatory in certain electronic invoice XML fields that get
sent to Carvajal. This value will incorrectly be 0 if `city_id` is not
set on the contact due to the above issue, causing the invoice to be
rejected.

This fix lets a contact inherit the `city_id` from its parent if
`base_address_city` is installed.

opw-2638687

closes odoo/odoo#81230

Signed-off-by: Quentin De Paoli <qdp@odoo.com>

closes odoo/odoo#81194

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

This fixes inconsistencies when dealing with fields that are computed
and inversed by the same methods.

Consider two fields F1, F2 with the same compute and inverse methods.
Consider a record where we wrote on a dependency of the common compute
method.  At this point, both fields F1 and F2 are marked to be computed.

Now let us write on F1 only.  Here is what happens:
 - the write discards the computation of F1, but not F2
 - the inverse method of F1 is called:
    - the method accesses F2
       -> this calls the compute method, which assigns both F1 and F2
    - the method accesses F1
       -> the value of F1 has been replaced by the computation above

The issue comes from a combination of factors:
 - the value of F2 must be determined by the computation;
 - the computation assigns both F1 and F2;
 - the computation is done while inversing F1 (and F2).

The solution is to force the computation before actually writing on the
fields and calling their inverse methods.  Note that this is necessary
only when part of the fields computed by a common method are updated.
When all fields computed by a common method are updated, the computation
will automatically be cancelled.

closes odoo/odoo#81105

Signed-off-by: Raphael Collet <rco@odoo.com>

How to reproduce:
1: create two employees (A B)  and two departments (C D)
2: Assign A as manager of C and B as manager of D
3: Assign C as A's department and A as A's manager
4: Change A's department to D -> A is deleted

This is due to `parent_id` being both a computed field and the source
field for a One2many. By changing the `department_id` the `parent_id`
also changed which results in it being report in the `onchange` method.
For some reason however the command sent by the orm is not `UNLINK` but
`DELETE` which results in the `active_id` being deleted.

TaskId-2711428

closes odoo/odoo#81122

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

It happens that the `stock.quant.reserved_quantity` and `stock.move.line.product_qty`
for the same parameters are not equals (due to some bugs in the past)

It could implies that it doesn't exist enough reserved quantity on the
quant when a user try to unreserve a stock.move.line resulting in the
UserError 'It is not possible to unreserve more products of %s than you
have in stock'

However on current stable version (13.0 and 14.0) a lot of PR already
fixed a lot of issue as:
odoo/odoo#69377
odoo/odoo#66347
odoo/odoo#61758
odoo/odoo#54355
odoo/odoo#43180
odoo/odoo#70975
for example (there is more than that)

So the idea is to provide a way to unlock the database manually for
stable but not in the new version to be able to analyse them and find
possible bugs responssible for the desynchronization.

The server action check all the quants and their relative move line
to check if match correctly. If not it will remove the reservation
from both. It could remove the reservation from some `pickings` and
`stock.move`

related to odoo/odoo#62139

closes odoo/odoo#79180

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Due to floating point representation, some floats may have some
insignificant decimals. Therefore, `float_compare` should be used when
comparing such numbers

OPW-2699576

closes odoo/odoo#80983

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

When editing the billing address of an existing portal partner P,
the salesperson of P was changed by the default website salesperson

BACKPORT of 52442484

opw:2649732

closes odoo/odoo#81043

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

When selling a storable kits, the consumable components should be
ignored in account lines

To reproduce the issue:
(Need account_accountant,sale_management,mrp)
1. Create a product category PC:
    - Costing Method: FIFO
    - Inventory Valuation: Automated
2. Create 3 products P_kit, P_compo01, P_compo02
    - P_kit:
        - Type: Storable
        - Category: PC
    - P_compo01
        - Type: Storable
        - Category: PC
        - Cost: 5
    - P_compo02:
        - Type: Consumable
        - Category: PC
        - Cost: 6
3. Update P_compo02's on hand qty: 1
4. Create a bill of materials:
    - Product: P_kit
    - Type: Kit
    - Components:
        - 1 x P_compo01
        - 1 x P_compo02
5. Create & Confirm a sale order SO with 1 x P_kit
6. Process the related delivery
7. Create & Post the related invoice

Error: The journal items of the invoice are incorrect, the value of
Expenses and Stock Interim (Delivered) are $11 instead of $5. The
consumable components should be excluded from this value

OPW-2604084

closes odoo/odoo#80850

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

closes odoo/odoo#80976

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

When consulting the Purchase Analysis, the measure "Days to Confirm" may
not be easily understandable

To reproduce the issue:
1. Create a purchase order PO:
    - Order Deadline: <today + 10 days>
    - Add 2 products
2. Confirm PO
3. Purchase > Reporting:
    - Measures: Days to Confirm
    - Group By: Order

Error: For PO, the value of "Days to Confirm" is -20, it should be -10

The report computes the sum of the delay (i.e., "Days to Confirm") of
each purchase order line. Computing an average seems more relevant

A similar flow could be reproduce with the measure "Days to Receive"
(i.e., the difference between the Order Deadline and the Receipt Date)

OPW-2678673

closes odoo/odoo#80671

Signed-off-by: Arnold Moyaux <arm@odoo.com>

The requirement of having real_time valuation in product categories to use LC is not needed
at all, as the information is taken from stock.valuation.layer, but it was previously
enforced due to the leftovers of the previous algorithm.

We remove such requirement in this commit, and also not creating the LC journal entry in
such cases.

TT32954

closes odoo/odoo#80200

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

This is a bunch of fixes (65 corner cases) for the search on
company-dependent fields:

Without a default value:
- `char` fields:
    - operators `not like`/`not ilike` don't return records with unset value
    - `(..., '=', False)` doesn't return records with unset value
    - `(..., '!=', '<string>')` doesn't return records with unset value
    - `(..., 'in', [..., False])` doesn't return records with unset value
    - `(..., 'not in', value)` without `False` inside `value` doesn't return records with unset value
- `date` and `datetime` fields:
    - `(..., '!=', <Date/datetime>)` doesn't return records with unset value
    - `(..., '=', False)` doesn't return records with unset value
- `many2one` fields:
    - operators `not like`/`not ilike` don't return records with unset value
    - `(..., 'in', [..., False])` doesn't return records with unset value
    - `(..., 'not in', value)` without `False` inside `value` doesn't return records with unset value
- `boolean` fields:
    - `(..., '=', False)` and `(..., '!=', True)` don't return records with unset and `False` values
- `integer`/`float` fields:
    - `(..., '!=', <number>)` doesn't return records with unset value

With a truthy default value:
- `many2one` fields:
    - operators `not like`/`not ilike` don't return records with unset value
    - `(..., '=', False)` returns the record with the default value (which isn't `False`)
- `boolean` fields:
    - `(..., '=', False)` doesn't return records with unset and `False` value
    - `(..., '!=', False)` returns records with unset and `False` value
- `integer`/`float` fields:
    - all `(..., operator, value)` which include value 0, return all records with unset value, even if the default value does not satisfy the domain

closes odoo/odoo#80082

Signed-off-by: Raphael Collet <rco@odoo.com>

Steps to reproduce the bug:
- Go to settings and enable “External Email Servers” option
- Go to accounting > Configuration > journals
- Create a new journal, Choose "purchase" type
- save
- Go to advanced settings tab > click on email alias
- Note that default value = `in_invoice`
- Create another journal, choose "Miscellaneous" type > save
- Change the type to "purchase"

Problem:
the default value = "out_invoice", because it is not updated in the write function after changing the journal type
In the case of type == 'purchase', the default value should be 'in_invoice', and in any other case, it should be 'out_invoice'.

opw-2618357

closes odoo/odoo#75358

X-original-commit: 3da57964aeee99c8314195c763fe521c28fbc734
Signed-off-by: William André (wan) <wan@odoo.com>

Backport branch odoo/odoo#79587 to v13.

In _get_inventory_lines_values, remove quants recordset
as it has been unused since commit cc9324f7.

Browse product.product in _get_inventory_lines_values
outside of for loop to speedup getting the uom_id.

closes odoo/odoo#80106

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

The `uom_id` field from the product is used, but the field is missed from the dependency decorator. Because the `product_qty` field is stored, than it will never recalculated when i modify the uom on the product.

closes odoo/odoo#80911

Signed-off-by: Arnold Moyaux <arm@odoo.com>

The query below
https://github.com/odoo/odoo/blob/81497125d8100c6bdd2dc30434232a88a419a3e3/addons/hr_work_entry/models/hr_work_entry.py#L92-L115


has bad performance without the bespoken indices on `date_start` and
`date_stop`. We can speed it up more with an index on `employee_id`.

This is not enough for DBs with many work entries (500K+), specially
during upgrades.

Here we optimize the query to take into account only the work entries
being modified.

This issue was observed during an upgrade saas~12.3->13.0 where the
payslip recomputation never ends due to the increased amount of hr work
entries created. Note how the first 1K payslips are processed in 1 hour
(~16 payslips per minute), while the latest 3 (before the upgrade
was killed) took 1 min.
```
2021-11-02 21:05:44,403 2229 INFO db_42897 odoo.modules.migration: module hr_payroll: Running migration [$saas~12.4.1.0] end-compute-amount
2021-11-02 21:06:44,577 2229 INFO db_42897 odoo.upgrade: [1.61%] 1120/69635 payslip processed in 0:01:00.036716 (total estimated time: 1:02:12.729213)
2021-11-02 21:07:44,602 2229 INFO db_42897 odoo.upgrade: [2.66%] 1853/69635 payslip processed in 0:02:00.062972 (total estimated time: 1:15:11.918540)
...
2021-11-05 09:59:46,565 2229 INFO db_42897 odoo.upgrade: [47.95%] 33390/69635 payslip processed in 2 days, 12:54:02.025479 (total estimated time: 5 days, 7:00:30.261882)
2021-11-05 10:01:04,990 2229 INFO db_42897 odoo.upgrade: [47.95%] 33393/69635 payslip processed in 2 days, 12:55:20.450549 (total estimated time: 5 days, 7:02:32.725840)
```

opw-2672031

closes odoo/odoo#80202

Signed-off-by: Nicolas Seinlet (nse) <nse@odoo.com>

TLDR: if we have a term in python and js code, then js translation may not work

STEPS:

* install point_of_sale
* activate and switch to French translation
* go to "Point of sale >> Reporting >> Orders"
* Click "Time Ranges >> Range"

BEFORE: "This Week" is not translated

AFTER: All terms are translated

WHY:

* Translation imports merges translation if they have same src

  https://github.com/odoo/odoo/blob/1e39a2d3b8060963073a39d99ba3a14b07d03333/odoo/addons/base/models/ir_translation.py#L196
  https://github.com/odoo/odoo/blob/1e39a2d3b8060963073a39d99ba3a14b07d03333/odoo/addons/base/models/ir_translation.py#L111

  So, we get either js term for "This Week" or py term, but not both

* web/webclient/translations loads only translation with comments==openerp-web

  https://github.com/odoo/odoo/blob/1e39a2d3b8060963073a39d99ba3a14b07d03333/odoo/addons/base/models/ir_translation.py#L900



  So, if we don't have js term, then the translation is not loaded to UI

* This only fix problem of no translation, but doesn't fix overriden
translation (i.e. when same english term, e.g. Free, has different translation
in frontend and backend). This part can be fixed by changing english term to
something more unambiguous.
---

opw-2357399

closes odoo/odoo#61641

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

Partial backport of 61b4b677
Running the scheduler is similar to running a cron, the user executing
the action is not relevant and may introduce access rights issues

closes odoo/odoo#80827

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

Before this fix there is no real way to influence the VAT validation.
This can be problematic though as in some cases external platforms push data to you
on which you don't really have control. If an external software pushes an invalid VAT
and your database has the option 'Verify VAT Numbers' checked on there is no way
for you to bypass this though.
This means that before this commit you have to always run VAT number checks on all data,
no matter if they come through the frontend or backend.

After this commit you can supply a context key 'no_vat_validation' though.
This way you could skip doing VAT number validations on (some) records while still
enforcing this in the UI.
This allows you to have crons/external API's push any VAT number while enforcing full
validation through the UI.

This opens up the best of both worlds.

closes odoo/odoo#80503

Signed-off-by: Olivier Colson <oco@odoo.com>

>>> u1 = self.sudo(False).browse(1)
>>> u2 = self.sudo().browse(2)
>>> (u1 + u2).env.su
False
>>> (u2 + u1).env.su
True

Ensure all attachments are always in sudo

Before this commit, a portal user could not go in debug asset

Introduced at 3a98996e

closes odoo/odoo#80754

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

1. disable document types that are not available https://www.afip.gob.ar/libro-iva-digital/documentos/Libro-IVA-Digital-Tablas-del-Sistema.pdf

 (remove "internal_type" value)
2. Add prefix and purchase_aliquots for every document type that usable (has an internal_type value)
3. Enable liquidacion primaria/secundaria de granos

closes odoo/odoo#79878

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

In some situations, the user can't redefine the quantity to produce of a
MO

To reproduce the issue:
(Use demo data. Enable debug mode)
1. In Decimal Accuracy, edit Product Unit of Measure:
    - Digits: 5
2. Create a MO:
    - Product: [FURN_7023] Wood Panel
    - Quantity To Produce: 1000
3. Produce 800
4. Update the Quantity To Produce: 800

Error: An error message is displayed: "You have already processed
800.00000. Please input a quantity higher than 800.00000"

Due to a floating point issue, the produced quantity is actually
800.0000000000001 which is greater than 800. This is the reason why the
`UserError` is raised

Some similar issues might be found with the other float comparisons in
`change_prod_qty`.

OPW-2689831

closes odoo/odoo#80388

Signed-off-by: Arnold Moyaux <arm@odoo.com>

When using AVCO and subcontracting without any additional cost, the
valuation of the finished product is incorrect

To reproduce the issue:
1. Create a Product Category PC:
    - Costing Method: AVCO
2. Create two products P_compo and P_finished:
    - Both:
        - Type: Storable
        - Category: PC
    - P_compo:
        - Cost: 10
        - Routes: Resupply Subcontractor
3. Update P_compo's quantity: 2
4. Create a Bill of Materials BO:
    - Product: P_finished
    - Type: Subcontracting
    - Subcontractor: a partner P
    - Component: 1 x P_compo
5. In Inventory, create a planned Receipt R:
    - From: P
    - Operations: 1 x P_finished
6. Mark R as To Do
7. Process the delivery of P_compo
8. Validate R
9. Repeat steps 5-8
10. Open the Inventory Valuation

Error: There are two valuation lines for P_finished: one line has a
value of $10, which is correct (this is the cost of the component).
However, the value of the second line is $20, it should be $10 too.

Here are a part of the values used to generate the related MO:
https://github.com/odoo/odoo/blob/2d12fb8fb94c0f2acade7222cfedbec34114a8e9/addons/mrp_subcontracting_account/models/stock_picking.py#L21-L25
In the above case, an extra cost is defined on the MO and is based on
the unit price of the subcontracted SM. However, `_get_price_unit` will
return an incorrect value:
https://github.com/odoo/odoo/blob/251be6b943ea8c3f274bb0863d0af3f7c6b8d10d/addons/stock_account/models/stock_move.py#L39
After step 8, the standard price of P_finished is $10. Also, in the
above case, there isn't any subcontracting cost, so there isn't any unit
price defined on the SM. Therefore, `_get_price_unit` returns the
standard price of P_finished ($10). As a result, when computing the
value of the finished stock move:
https://github.com/odoo/odoo/blob/4fc2ec31861d4602357f130066ec3507b96d8dc8/addons/mrp_account/models/mrp_production.py#L39-L42


It uses the extra cost of the MO + the component cost. This explains
where the $20 come from.

OPW-2641339

closes odoo/odoo#80373

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

It was painful to add an inline snippets, or move elements inside mega
menus. The dropdowns are now behaving as such: if they are shown, the
user can only add or move snippets inside them, but not outside.

task-2668908

closes odoo/odoo#80603

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

In 0cc30bf0 confirmation_date was
replaced by date_order. But this cause the "last 30 days" range to not
work on sale.report because for the model the field is called date.

opw-2703405

closes odoo/odoo#80685

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

closes odoo/odoo#80629

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

This commit fixes my mistake in this previous commit: ff7a82f0cb31699e6169654b4bd62a895b2f09b3

closes odoo/odoo#80619

Signed-off-by: Arnold Moyaux <arm@odoo.com>