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>

In Argentinean localization, we are making inactive some document types in a
no-updatable xml view to keep the user configuration when the module is
updated. This fix is to avoid the possibility of inactivating doc types
from other localizations with the same code.

closes odoo/odoo#80031

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

Steps to reproduce the issue:

- Install the module eCommerce
- Activate PayU Latam payment acquire in test mode and
  set it to Website 2
- Set a domain for each website
- Go to Website 2
- Add any product to cart and go to checkout
- Select PayU Latam as payment acquire and click on pay
- Select any payment method, finish the payment and click
  on the "Back to the store" button

Issue:

  Redirect to the first website (instead of Website 2),
  therefore the user has not the receipt of the payment.

Cause:

  The domain of the response url is set to the ir.config_parameter
  'web.base.url'.

Solution:

  Use the function `self.get_base_url()` to get the right domain
  (already what is done in other payments acquires).

opw-2652582

closes odoo/odoo#80538

Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

Steps to reproduce the bug:
- Create a storable product > add a BOM
- Create a MO> add the product > confirm > Mark as done
- Go to the product form > click on product moves
- The move linked to the MO is displayed
- Add the "Manufacturing" filter
- No move is displayed

Solution:
Display all "stock.move.line" which are linked to a "stock.move" with a "mrp.production"

Bug2:
The "Manufacturing" filter should be defined in the MRP module instead of the stock
otherwise, users who do not have MRP installed will have access to this filter as well

opw-2697254

closes odoo/odoo#80383

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

Steps to reproduce the bug:
 - Create a BOM:
    - Set the quantity of the finished product and component as more than 1
- Save > Go to BOM Structure & Cost > the quantity in the input is set on 3
- Print

Problem:
The report generated shows the qty and cost for production of 1 unit of product, regardless of the BOM quantity set in the input

The "_onClickPrint" function tries to get the quantity of the bom in the context,
but since the value of "this.given_context.searchQty" is null, the function will use the default value of 1.
The "searchQty" is only set in the "onchange", so we can manually trigger it when initiating the page so that the "searchQty" is set correctly

opw-2691632

closes odoo/odoo#80435

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

Renames "DHL", "DHL USA" and "DHL Express" into "DHL Express Connector".

task-2581265

closes odoo/odoo#80471

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

Steps to reproduce:

- Install Argentinian Accounting
- Enable multi-currency
- Create a customer invoice in USD
- Product X, quantity 10, price 17.82, VAT 21%
- Save and click on preview

Issue:

On tax line, "VAT 21% on $178.20" is displaid instead of just "VAT 21%"

Cause

This is the result of a rounding issue inherent to python, when passing in Currency.round method, 178.20 became 178.20xxx001.

Solution

Overwritte the _get_rendering_context method in order to be able to use the float_compare method instead of a strict comparison in xml report.

opw-2677160

closes odoo/odoo#79740

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

When using a mobile, scanning a product to manage a delivery won't work

To reproduce the error:
(Need stock_barcode. Use demo data)
1. In Operations Types, edit "Delivery Orders":
    - Enable "Show Detailed Operations"
3. Create a planned delivery order DO:
    - 1 x [FURN_1118] Corner Desk Black
4. Mark a Todo
5. Switch to a mobile view
6. Edit DO and scan 601647855640 (i.e., the barcode of FURN_1118)
7. Save DO

Error: An error is displayed "The operation cannot be completed [...]
Model: Product Moves (Stock Move Line) (stock.move.line), Field: From
(location_id)"

The kanban view does not include both `location_id` and
`location_dest_id` although they are required

OPW-2688915

closes odoo/odoo#80162

Signed-off-by: Adrien Widart <awt@odoo.com>

Improve the factur-x export in two ways: make the exported PDF
PDF/A-3B compliant, and add the factur-x XMP metadata inside the file.

The added .ICC profile comes from https://www.color.org/srgbprofiles.xalter
License terms can be found here: https://www.color.org/profiles2.xalter#license



Task id # 2668919

closes odoo/odoo#78974

Signed-off-by: Laurent Smet <las@openerp.com>

According to the Argentinean law N° 27440, it is required for MiPyMEs
document types to show in the report the total amount in letters.

closes odoo/odoo#78314

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

Before this commit, when the user made an error in the HTML/SCSS editor
(most of the time due to user pasting HTML code while our code excepts
*XML*), the user was stuck most of the time because the error indicator
did not always appear. And even if it did, it disappeared on scroll and
the user had to guess where to click to show the error message.

Now, the UI for the error is way clearer, with the error message opening
itself directly and pointing at the line where the error occurs. The
UI of that error message is now more robust (even though suffering
because of the ace editor which likes to re-render itself at unknown
times). The error message is also still not super clear (default error
message given by the browser) although some parsing is now done on it to
try and display it better.

task-2698641

closes odoo/odoo#80286

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

By default show the user_custom_rules.scss one as some people would
write rules in user_custom_bootstrap_overridden.scss otherwise, not
reading the comment inside explaining how that file should be used.

task-2698641

Part-of: odoo/odoo#80286

When switching to files that can only appear in debug mode in the HTML /
SCSS editor and editing them, the page reloads... and crash for no
reason. This was because the filter that allows those files to appear
is lost after reloading, now we simply ignore the file switch if not
present in the default filter.

task-2698641

Part-of: odoo/odoo#80286

Bug introduced by:
https://github.com/odoo/odoo/commit/bc131c0cfb51c953de8ec41fb820c8c7831eefb5



closes odoo/odoo#80370

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

closes odoo/odoo#78914

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

Commit [1] and its forward-ports introduced a test tour (properly added
in assets_tests) but was not declared as a test one. Meaning that if you
were in debug=tests, you were able to follow a strange tour not meant
for user testing.

[1]: https://github.com/odoo/odoo/commit/3c194faa930b0d3a537ca8b893b2c0442b5464e7



closes odoo/odoo#80354

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

Before this commit, when the user creates a quotation and add a SOL with
product contained a project in `project_id` field, the
'Project Overview' stat button is shown even if the quotation is not
confirmed.

This commit changes the visibility condition of this button to display
it only if at least a project is contained in `project_ids` field of
`sale.order` model and if the quotation is confirmed that is when the
quotation becomes a sales order.

Step to reproduce:
=================
1) Go to the Sales app
2) Click on 'Create' button to create a quotation.
3) Add a SOL with 'Customer Care (Prepaid Hours)' product

Actual Behavior:
===============
The 'Project Overview' stat button is displayed.

Expected Behavior:
=================
This stat button should not be displayed while the quotation is not
confirmed to become a sales order.

task-2697063

closes odoo/odoo#80305

Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>

Steps to reproduce the bug:
- install `”purchase_product_matrix”`
- Go to the purchase settings and enable “Warnings” option
- Create a product with variants
- Add purchase warning
- Create a PO and add the product

Problem:
The warning message is not appearing

Solution:
the `”_product_id_change()”` function has no return.
To trigger the warning message, we have to call the `”onchange_product_id_warning”` manually because it is not triggered automatically in the grid case

opw-2696007

closes odoo/odoo#80275

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