Closes odoo/odoo#69217

closes odoo/odoo#73829

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

How to reproduce the problem:
- Install the Fleet app.
- Create a user that has access to 2 or more companies (e.g. Mitchell Admin).
- Log in as this user. Go to fleet -> Vehicles -> Vehicles Costs/Contracts/Fuel Logs/Services Logs
- Uncheck one of your companies.
- The user still has access to the fleet of the other companies, even if they are unchecked.

Cause of the problem : missing record rules

Solution : added multi-companies rules

opw-2518188

closes odoo/odoo#73654

X-original-commit: ad62f877
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: prro-odoo <proose@users.noreply.github.com>

closes odoo/odoo#72762

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

closes odoo/odoo#73842

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

Set the warehouse with manufacturing 3 steps
Create a BoM with a Components that use a Sub BoM
Set Both product MTO + Manufacture
Create a MO
You have only 2 picking for the first MO with the SFP
that contains both the finished product and the intermediate
component. However they are created and moved at two different times
since you could not create the finished product withtout the
component, so there is no meaning to put them both in the same picking.

It happens because the _assign_picking will merge moves with the same
procurement group. In our case, it's the wanted behavior to have the
2 differents SFP linked to the same MO.

The idea between the fix is:
- We want to have the pick components picking merged.
- We want to have the store components split since they come from
different MO
So we create the different procurement groups during the _run_pull with
the picking type of store finished product. This way the pickings won't
be merged during _assign_picking

We will also propagate those groups to the newly created MO in order to
keep the picking type sequence and correct name.

FW PORT of
https://github.com/odoo/odoo/commit/bcfa03821b92bf52675db0e3b54d3cb19dfe3087



opw-2585525

closes odoo/odoo#73248

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

If you use electronic terminal, electronic ticket is not save in database.
I you want reprint the ticket, electronic ticket is not present in the reprint ticket.

closes odoo/odoo#72777

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

Before this commit UserError, ValidationError are not correctly show.
Get the same behaviour of V12.

closes odoo/odoo#73649

Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Co-authored-by: Joseph Caburnay (jcb) <caburnay.joseph@gmail.com>

Fetching all the groups from the DB causes MemoryError on some DBs
Example Accounting > Accounting > Journals > Miscellaneous menu:
```
 Traceback (most recent call last):
   File "/tmp/tmpbnah9jtp/migrations/base/tests/test_mock_crawl.py", line 176, in crawl_menu
    self.mock_action(action_vals)
   File "/tmp/tmpbnah9jtp/migrations/base/tests/test_mock_crawl.py", line 267, in mock_action
    mock_method(model, view, fields_list, domain, group_by)
   File "/tmp/tmpbnah9jtp/migrations/base/tests/test_mock_crawl.py", line 380, in mock_view_tree
    self.mock_web_read_group(model, view, domain, group_by, fields_list, limit_group=5)
   File "/tmp/tmpbnah9jtp/migrations/base/tests/test_mock_crawl.py", line 425, in mock_web_read_group
    data = model.web_read_group(domain, fields_list, group_by, limit=limit)["groups"]
   File "/home/odoo/src/odoo/14.0/addons/web/models/models.py", line 96, in web_read_group
    all_groups = self.read_group(domain, ['display_name'], groupby, lazy=True)
   File "/home/odoo/src/odoo/14.0/odoo/models.py", line 2248, in read_group
    result = self._read_group_raw(domain, fields, groupby, offset=offset, limit=limit, orderby=orderby, lazy=lazy)
   File "/home/odoo/src/odoo/14.0/odoo/models.py", line 2387, in _read_group_raw
    result = [self._read_group_format_result(d, annotated_groupbys, groupby, domain) for d in data]
   File "/home/odoo/src/odoo/14.0/odoo/models.py", line 2387, in <listcomp>
    result = [self._read_group_format_result(d, annotated_groupbys, groupby, domain) for d in data]
 MemoryError
```

This issue was observed during the upgrade requests upg-18830, target
14.0; and upg-61934 (legacy), target 13.0

The issue can be reproduced on a clean DB with just account_accountant
installed and ~2 millions account moves on a Misc journal.

closes odoo/odoo#73823

X-original-commit: a9b3d9cf
Signed-off-by: Christophe Simonis <chs@odoo.com>

If the buyer is Italian, it must have a zip code of length 5.
If the buyer is not Italian, the zip code is optional

closes odoo/odoo#73817

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

closes odoo/odoo#73330

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

closes odoo/odoo#72671

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

closes odoo/odoo#71767

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

closes odoo/odoo#73788

X-original-commit: 092c9263
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>

When using another language than English, the UID of a POS order may be
incorrect

To reproduce the error:
1. Open a POS's configuration and enable "Manage Orders"
2. In Settings > Languages, add ans switch to:
    - French (BE) / Français (BE)
3. Start a POS session
4. Process an order
5. Open the orders managers

Error: the processed order is named "Commande de 00001-001-0001", the
"de" in the middle shouldn't be present

This is the combination of "Commande" and the UID of the order. The
latter is extract from the POS reference, which looks like "Commande
00001-001-0001" by removing the first 6 characters. It's ok in English:
from "Order 00001-001-0001", we have "00001-001-0001". But this won't
work in all other languages (specially for RTL languages)

The unique identifier of an order is a sequence of 12 digits:
https://github.com/odoo/odoo/blob/3e8d921318e86631b73c8c92c2e462fd0d761582/addons/point_of_sale/static/src/js/models.js#L2865-L2868


Knowing this, we can easily extract the UID from a POS reference

OPW-2538645
closes #71181
closes #71182

closes odoo/odoo#73777

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

[ADD] l10n_cl: add method to invoice report to format the vat dotted

closes odoo/odoo#72231

Related: odoo/enterprise#18432
Signed-off-by: Josse Colpaert <jco@openerp.com>

When the user is not in en_US language, unit_name is always different of Unit

opw:2581462

closes odoo/odoo#73075

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

When you use /lead in the livechat the created lead have no user, no team and no stage_id.

closes odoo/odoo#72883

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

Linked to commit https://github.com/odoo/odoo/commit/3e6b7dfd4854069724dde2df43ab2eb7d850e9b5



Resequence wizard will not show if "other" lines are generated to reduce the set
to display in preview, because those lines don't have "id" to be used as t-key in
the resequence template.

opw-2590273
opw-2581306

closes odoo/odoo#73784

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

At the closing of the POS, we try to reconcile
all lines involved in the closing.
If for any reason, a line is already reconciled
(I.E. Debit=0 and Credit=0 is considered as reconciled),
the closing fails because we cannot reconcile an already
reconciled line.

OPW-2602410

closes odoo/odoo#73766

X-original-commit: 4fd374b3
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

Fix the demo data installed with the module.
We create a new website and associate a pricelist with currency ARS and
the tax IVA 21% associated with the RI company.

closes odoo/odoo#69206

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

closes odoo/odoo#73663

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

The terms 'Set Customer' and 'Deselect Customer' was missing
in point_of_sale.pot

opw-2596436

closes odoo/odoo#73770

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

When confirming a SO, if the costing method of a product's category is
not `Standard' and if the SO's currency is different from the company's
currency, the cost of the product won't be converted to the SO's
currency

To reproduce the error:
1. In Settings, enable:
    - Margins
    - Multi-Currencies
2. Create a product category PC:
    - Costing Method: FIFO
3. Create a product P:
    - Product Type: Storable
    - Product Category: PC
    - Sales Price: 200
    - Cost: 100
4. Update P's quantity to 1
5. Create a pricelist PL:
    - Currency: EUR
6. Create a SO:
    - Pricelist: PL
    - Order Lines:
        - 1 x P
7. Add field "Cost" to the tree view of the order lines
    - The value is correctly converted
8. Confirm the SO

Error: The cost of the order line is now 100€. This is actually the USD
cost, it should be converted

This code applies the same conversion as when the cost method is
standard:
https://github.com/odoo/odoo/blob/8a8ff03f6111f377bcd9c2b0f584c450b82a4182/addons/sale_margin/models/sale_order.py#L42-L48



OPW-2563442

closes odoo/odoo#73545

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

Codice Fiscale can be 16 length (letters + digits) for physical people.
Codice Fiscale can be 11 digits prefixed or not with 'IT' for companies.

An error is raised if the codice fiscale is not saved in the correct format. When registering to l10n_it_edi_proxy, we try to normalize the Codice Fiscale if possible.

Also, when entering the vat in the partner, the Codice Fiscale is automatically set normalized.

closes odoo/odoo#73682

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

Steps to reproduce the bug:
- Install eCommerce and l10n_pe
- Go as website visitor
- Add anything to your cart
- Continue with checkout to go to the address page
- Select country Peru and fill in all the required fields
- Validate
- You will get an error message telling you that you forgot to fill in a required field.

Problem:
You cannot validate the address because zip code is not displayed, but required.
This field is based on the country format address to be displayed before or after the `" City "` field
and is not displayed if `" zip "` is not present in the country format address.

https://github.com/odoo/odoo/blob/b1107cba38e296f17d03d9919be67e6789a407be/addons/website_sale/views/templates.xml#L1208-L1223

https://github.com/odoo/odoo/blob/15fe3d43b4b925a32b42eb46048a33987e10336b/openerp/addons/base/res/res_country.py#L77



Solution:
"zip" is required for the Peru country, so it must be added in the address format

opw-2600526

closes odoo/odoo#73717

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

The view is broken because read_progress_bar() calls read_group() with
two groupbys in eager mode.  The method read_group() is overridden for
model `note.note` and does not handle that case: the returned result is
incorrect.  We modify the override to call the default read_group() in
that case, which eventually fails and makes read_progress_bar() fall
back on its naive implementation.

closes odoo/odoo#73597

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

This commit fixes the performance issue in getting statistics for
``activity_state`` (colored clock icon for overdue/today/planned) in
CRM.  The query has been tested for several years on a large database
(Odoo's own production database).

Performance test on 29 K crm.lead records (activity_state):

With a filter for 10 records:

```
| measurement        | before | after |
|--------------------+--------+-------|
| number of queries  |     25 |     5 |
| query time, ms     |     12 |    95 | (*)
| remaining time, ms |     32 |     7 |
```

All records:

```
| measurement        | before | after |
|--------------------+--------+-------|
| number of queries  |   1326 |     5 |
| query time, ms     |   1739 |   129 |
| remaining time, ms |  47934 |    17 |
```

As we can see in the last results, the time went from almost 50 seconds
(not responsive at all) to 150 milliseconds (responsive).  The time
increase in (*) may be caused by imperfect measurements, which are raw
and not averaged measures.

Co-authored-by: Nicolas Seinlet <nse@odoo.com>

---

opw-2346901
task-1915411

The method is used to get progress per column in kanban view
(green-yellow-red-red lines in Project, CRM etc).  There are two main
usages:

1. get statistics for ``kanban_state`` (red/green circles)
2. get statistics for ``activity_state`` (colored clock icon for overdue/today/planned)

Before this commit all cases were handled by calling search_read and then
counting records per group in a python script.  This is very inefficient,
especially for ``activity_state``.

This new implementation relies on ``read_group`` when possible, i.e.,
when both grouping fields (kanban column and progressbar field) are
stored (case 1).  It then falls back on a naive implementation inside
``_read_progress_bar``.  Cases like 2 above can be addressed by
overriding ``_read_progress_bar``.

We also added some minimal test to ensure that we don't break anything.

1. Performance test on 60 K project.task records (kanban_state):

With a filter for 6 records:

```
| measurement        | before | after |
|--------------------+--------+-------|
| number of queries  |      8 |     5 |
| query time, ms     |     11 |     7 |
| remaining time, ms |     21 |     9 |
```

All records:
```
| measurement        | before | after |
|--------------------+--------+-------|
| number of queries  |     67 |     5 |
| query time, ms     |    300 |    55 |
| remaining time, ms |   1780 |    12 |
```

Co-authored-by: Raphael Collet <rco@odoo.com>

---

opw-2346901
task-1915411

Currently the replenishment report look for forecasted quantity of
product today. It means that for a product if the delivery is planned
for today the forecast will be -1, at j-1 it will be 0. However for the
majority of use case, products take days to order and arrive.

Example:
- Product A, purchase delivery time 5 days.
- You are the 01-01-2021 and create a SO for 10-01-2021
Currently:
- Product will appear in the replenishment report the 10-01-2021 and
you will receive it the 15-01-2021. So you are late to deliver your
customer.
Desired behavior:
- Product appear in the replenishment report the 05-01-2021 and if you
order it directly you will receive it the 10-01-2021.

If you want to have more time to deliver than one day, security lead
time are there for it.

However the usecase like:
Product arrive in 2 months and you receive it in 3 days, the product won't
appear in the replenish report anymore since the forecast in 3months is
0

It could happens that more product are missing in 3 months than today,
so the system could have more delivery lead times and forecast at date
to compute -> be slower. In that case a parameter could be
added to skip the delivery times computation for each product/warehouse
and just display the forecast in 3 months and let user compute their
schedule themself.

closes odoo/odoo#73652

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

The value of the related field should be cleared:
- If the other record no longer exists.
- If the target value is undefined.

This might fix hard to understand bugs, such as task-2410314

closes odoo/odoo#73696

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

By luck the situation never happened before, but it is legitimate to handle it.
A future commit will actually introduce the possibility of the issue happening.

closes odoo/odoo#73688

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

The default value for `rating_active` on the `project.project` model
wasn't set properly to the settings value.

Closes odoo/odoo#73683

Task ID: 2602636

Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>

- Create 2 invoices (or 2 bills) but let them in draft
- In invoices list view, select all invoices
- Execute Action > Resequence
Resequence wizard will not show.

It comes from a template in resequence renderer using account move name as t-key
that silently crashes because both draft invoices have the same name ("/").

opw-2590273

closes odoo/odoo#73603

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

Steps to reproduce the bug:

- Let's consider an expense E paid by the company
- Validate E and post journal entries

Bug:

Two journal entries were created:

1. Outstanding payments (debit) / Account Payable (credit) as draft
2. Expense (debit) / Outstanding payments (credit) as posted

With the this fix:

Only the second entry is created and posted

This reverts commit 25ac51e0.

opw:2510663

closes odoo/odoo#73677

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

When creating the l10n_fr chart of accounts, the tax payable and tax
receivable accounts of the tax groups were missing, and this had other
effects like a missing tax report entry.

This commit fixes the issue by setting the property on the template,
like in others modules (e.g. l10n_be).

closes odoo/odoo#73634

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

Previously, the button Sale Order in a Project form could only be seen when the sale_timesheet module (installed automatically with the Timesheet, Sales and Project apps) is installed.
Now, only the Sales and Project apps are needed to be able to display the Sale Order button.

opw-2530161

closes odoo/odoo#73239

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

This commit adds a sanity check to the part of the ORM that uninstalls
module data, as a recap, here's how module uninstallation works:

- We fetch all data (ir.model.data) that corresponds to the module being
uninstalled (`WHERE module='my_module'`)
- We divide this data according to its type (ir.model, ir.model.field,
constraints, etc.)
- We fetch the corresponding records to each type, we delete them in a
certain order (e.g. ir.model.field before ir.model) and then finally we
delete the ir.model.data as a last step

The data is deleted in batch for maximum performance, if one of the data
cannot be deleted however, we perform a binary search until we find the
culprit(s) and we store these culprits in a list of undeletable_ids.

At the end of the process, we delete all ir.model.data **except** for
the ones that are undeletable, however, it is possible that because of
the multiple-step procedure, an undeletable ir.model.data could have
become deletable.

Imagine that an ir.model.field cannot be deleted, its module data id is
added to the list of undeletable_ids, however if later on its ir.model
is deleted successfully, the ir.model.field is dropped because its table
is dropped, in this case the ir.model.data becomes deletable, but since
we simply ignore it at the end of the process, we potentially end up
with orphaned xmlids.

This can be problematic when we reinstall the module and uninstall it
again, as the system does not expect an orphaned xmlid, will completely
crash and prevent the 2nd uninstallation of the module.

This is the case with CRM and its
crm.lead.scoring.frequency.field.field_id field, its ir.model.field
cannot be deleted because the name field (and display_name) of the same
model depend on it, so it is left as is, then further down the process
the entire model is deleted and as a result so is all of its remaining
fields, however the ir.module.data for the field that could not be
deleted remains.

opw-2575592

closes odoo/odoo#73523

X-original-commit: 6d37a46d
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>

Currently, pricelists can be deleted even if a pricelist rule uses this pricelist as base.
This leads to an error when the rule is used because it tries to access a deleted record.

This commit restricts the deletion of such pricelists, avoiding later tracebacks.

closes odoo/odoo#72890

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: vfe-odoo <Feyensv@users.noreply.github.com>