When a submodule overrides an old UNIQUE constraint with a new one,
records in that module may respect the new one and not the old one.
As the old module is updated, it would fail giving an ERROR message,
and therefore blocking the Odoo.sh deployment pipeline.

i.e. website_sale (old): res_users_login_key -> ['login', 'website_id']
             base (new): res_users_login_key -> ['login']

With this patch, the error level is changed from ERROR to WARNING,
leaving Odoo.sh free to continue the build deployment, as the error
was not a blocking one.

closes odoo/odoo#79042

Signed-off-by: Olivier Dony (odo) <odo@openerp.com>

Stock.location is ordered by "complete_name" which is possible to be the
same (i.e. default production locations for different companies). This
may result non-deterministic order. Add "id" to avoid it.

closes odoo/odoo#79135

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

- The batch version of get_metadata won't work correctly for the xmlid
returns due to the limit=1 (cause by
718b0f8b ). Fix the
previous issue by reversing the order and without limit.
- The read should be read with the correct user.

closes odoo/odoo#78770

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

Steps to follow

  Edit the account.move view (with studio for example)
  Set the lines readonly property to [["partner_id","=",False]]
  Create a new move
  Add a partner
  Add a product
  Remove the partner
  -> A traceback appears: widget.$el is undefined

Cause of the issue

  widget.$el is used after the widget has been destroyed

This commit corrects it, by waiting for new widgets to be "mounted" before destroying
old ones. The code already exists in 14.0 (3fd7b200).

opw-2557142

closes odoo/odoo#78625

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

Issue: When test sending a mail in Marketing Automation Mailings, there
is a traceback because we try to set the state of the mail to done,
even though there is no done in mail_mail.state

Steps to reproduce :
 1) Install Marketing Automation
 2) Create/select a campaign
 3) Access the templates of that campaign
 4) Create/select a template
 5) Click Test
 6) Send Sample Email
 -> Traceback

opw-2568210

closes odoo/odoo#77299

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

[FIX] l10n_es: fixup of https://github.com/odoo/odoo/commit/f5b21797b54e2dadd8c5940a0cb2e4b26ca47364



An oversight.

closes odoo/odoo#79027

Signed-off-by: Florian Gilbert <flg@odoo.com>

When importing bank statements, we are filling in automatically the bank account
id if an existing record matching the number is found. However, we should restrict
the search to retrieve only bank accounts belonging to the current company,
otherwise it will create a multi-company inconsistency.

closes odoo/odoo#78979

X-original-commit: f22eb970
Signed-off-by: Olivier Colson <oco@odoo.com>

In last added migration script in https://github.com/odoo/odoo/commit/b40216a8ae8fefd03311b2884e7b83644baac0a1

, the code assumes the chart of account of l10n_es is installed. But happens that you may have installed several l10n_* modules, including l10n_es, but not having the chart of l10n_es installed (you have installed the chart of another module).

In this case, then the update crashes because tax_ids is None and tuple(tax_ids) crashes!

closes odoo/odoo#78958

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

Fix https://github.com/odoo/odoo/commit/b40216a8ae8fefd03311b2884e7b83644baac0a1

 was merged though partially ready.

closes odoo/odoo#78987

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

Steps to reproduce:

  - Install eLearning module
  - Go to eLearning, open course Basics of Gardening and edit it
  - Click on `How to Grow and Harvest The Best Strawberries | Basics`
  - Upload an encrypted PDF as Attachement

Issue:

  Traceback is raised :
  utils.PdfReadError("File has not been decrypted")

Cause:

  When trying to calculate `completion_time` to read pages, we try to
  get the number of pages of the pdf but an error will be raised if the
  pdf is encrypted.

Solution:

  If not possible to get number of pages, we dont set/update the
  completion_time.

opw-2612529

closes odoo/odoo#76745

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

A related field copies the attributes from its target field, except for
the attributes defined on the related field itself.  The implementation
of this feature was not working properly for attributes with a truthy
default value.

This commit fixes the issue, but in an incomplete way.  If an attribute
on a related field has its default value, it will be overridden by the
attribute from its target field.  So one cannot "force" an attribute on
a related field to its default value.

closes odoo/odoo#78740

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

Issue:
Our functionality for merging PDFs from multiple vendor bills relies on PyPDF2. It is well-known that PyPDF2 is sometimes unable to manipulate even perfectly normal PDFs. To provide a helpful error message to the user when this happens (i.e. give them the names of the vendor bills corresponding to the offending pdfs), the `_get_unreadeable_pdfs()` function is called right before we try to merge the PDFs in `_merge_pdfs`. This function is meant to identify the offending PDFs and provide them to the user.
However, _get_unreadable_pdfs did not notice the problem with 3 of my customer's pdfs, because the error was only triggered once the PdfFileWriter.write function was called in _merge_pdfs. This function, however, is not called in _get_unreadable_pdfs, therefore, it did not notice that anything was wrong.

Fix:
- Change _get_unreadable_pdfs so that it also makes a call to PdfFileWriter.write
- As soon as PdfFileWriter.write fails once, it will continue failing when we append more PDF streams to the PdfFileWriter. I therefore suggest initialising a different PdfFileWriter at each iteration of the for loop in order for an offending PDF to not cause a false positive on subsequent PDFs.

closes odoo/odoo#78905

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

If for some reason we cannot compute lead probability, we should simply
continue to the next value without causing a division by zero.

This commit is a backport of part of https://github.com/odoo/odoo/pull/76110

.

Task-2674586

closes odoo/odoo#78765

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

It may happen that there is a property defined on some field that is not
the default property, but rather the property associated to a record.
For example
```
=> select id,name,company_id,fields_id,value_reference,res_id from ir_property where name like '%property_stock_inventory%'
+------+--------------------------+--------------+-------------+-------------------+----------------------+
| id   | name                     | company_id   | fields_id   | value_reference   | res_id               |
|------+--------------------------+--------------+-------------+-------------------+----------------------|
| 528  | property_stock_inventory | 1            | 4665        | <null>            | product.template,752 |
| 6    | property_stock_inventory | <null>       | 4665        | stock.location,5  | <null>               |
+------+--------------------------+--------------+-------------+-------------------+----------------------+
```
In this case the property with id=528 is not a default property since
res_id is not NULL. Alternatively the property id=6 is a default one.

The issue here is that when searching for the missing locations we do
not filter out the properties with res_id not NULL, thus we may get that
a company has the location define while in fact it doesn't. Following
the example above, this means that we incorrectly get property id=528 as
the one defining the location for the company id=1 here:
https://github.com/odoo/odoo/blob/c5c47da2e96fd5e37030c70d6bb1bae4c4047fa8/addons/stock/models/res_company.py#L107
This not only prevents the creation of the correct default property but
also the default locations
https://github.com/odoo/odoo/blob/c5c47da2e96fd5e37030c70d6bb1bae4c4047fa8/addons/stock/models/res_company.py#L36-L51



On this patch we fix the domain search for default property. This allows
for the correct creation of the default locations and associated
properties.

This issue was observed during upgrade 40921, where it prevents the
upgrade to 15.0

closes odoo/odoo#78835

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

Most uses (correct ones) of the `partner` context key content expect a `res.partner` recordset as `partner` context value.
This value is extracted during the pricelist price computation (but not used anyway...).

But in one case, fixed by the current commit, a `res.partner` id is placed in the context, as `partner` value.  In some cases, this may trigger "Comparing Apple and Oranges" errors, since `with_context` calls returns a new or existing environment, verifying whether an environment with the same values (user, context, ...) exists.
During this comparison, the new context, with an id (int) as `partner` value, is compared with existing contexts, potentially including some with a recordset on the same key.  Such a comparison fails on the lowest `__eq__` level, raising "Comparing apples with oranges" error.

This commit fixes this case, by making sure the value put in the `partner` context value is always a recordset, and not an id.

closes odoo/odoo#78276

Note: In the future, this context key should be dropped because it's still a bad practice to put recordsets in the context.
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

Some of the support scripts use xml-rpc calls to work
on pos.session on Saas or SH databases
(especially when needed to upload lot of offline orders
in smaller batches)
These scripts should be allowed to close any rescue session
created during this process programmatically via xml-rpc.

Our xml-rpc protocol does not allow to call function that
return nothing

closes odoo/odoo#78893

X-original-commit: b12f1c1b
Signed-off-by: Masereel Pierre <pim@odoo.com>

closes odoo/odoo#78846

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

Mod 303's grid 61 is now divided in 4 new lines: 120, 122, 123 and 124. Grid 61 isn't used anymore. This takes effect starting July 1st 2021; previous periods are unaffected.

Doc:

https://www.agenciatributaria.es/AEAT.internet/Inicio/Ayuda/Disenos_de_registro/Modelos_300_al_399/Modelos_300_al_399.shtml

https://iranon.es/modelo-303-cambios-a-partir-del-3t-y-mensual-de-julio-de-2021/



OPW 2662476

closes odoo/odoo#78650

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

Purpose
=======
Center confirmation text after sending track idea.

Task-2657588

closes odoo/odoo#77477

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

Purpose
=======
Fix guest users receiving confirmation emails for events by "Public User" in 13.0.

Specifications
==============
Confirmation emails for events are sent by:

- Organizer (if set)
- Company email (if set)
- The users's email
- Odoo bot otherwise

Task-2657588

Part-of: odoo/odoo#77477

Issue: When returning a product sold that is only made of kits and
validating the return, the delivered quantities of the sales order was
set back to the full amount delivered

Steps to reproduce :
  1) Install MRP and Sales
  2) Create a BoM Kit for a new product [Nested Kit] that has one or
    more consumable or storable product as component
  3) Create a BoM Kit for a new product [Main Kit] that has
    [Nested Kit] as component
  4) Create a SO for [Main Kit], confirm, validate delivery
  5) Check SO, 1 product is delivered (correct)
  6) Go back to the Delivery, create a return for the delivery
    (don't validate)
  7) Check SO, 0 product is delivered (correct)
  8) Now validate the return for the delivery
  -> Check SO, 1 product is delivered (bug)

Why is that a bug:
 Since the Main Kit was returned, the delivered should be 0 and not
 the full amount initially delivered. It was set back to 1 because we
 didn't look at the type of picking, when computing the quantity
 delivered, the fall back considered that if all the moves were done,
 everything was delivered, but it is the opposite when returning

opw-2542337

closes odoo/odoo#75256

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

Expected behavior : The order button should go green and active when you 'unskipped' an orderline

Current behavior : The order button doesn't go green and can't be clicked when an orderline is 'unskipped'

Steps to reproduce the error :
First of all, you need to setup a PoS Restaurant with these options :
~ Bar/Restaurant
~ Enable `Table Management`
~ Enable and setup `Order Printer` with IP Address and choose Categories to be printed on.

1. Open a restaurant session
2. Pick a table
3. Select a product and put it on hold
4. Select the **same** product and order it
5. 'Unskipped' the product from step 3

Order button should be green and active but is unactive so the order can't be sent

Previously, the condition was only based on the product_id so error occurs when multiline of the same product are handled

opw-2557518

closes odoo/odoo#78608

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

quotation_description on the sale order is copied from the
product template, where it already is sanitize_attributes=False,
and it has to stay like that because otherwise widgets like
"tab" or "accordion" cannot be rendered correctly.

This is also linked to a bug in the ORM where the _related_attrs
weren't copied correctly.

Related ORM PR: https://github.com/odoo/odoo/pull/78687
Ticket link: https://www.odoo.com/web#id=2487749&model=project.task



opw-2487749

closes odoo/odoo#78723

Signed-off-by: Paolo Gatti <lordkrandel@users.noreply.github.com>

before this commit: applying readonly attribute on toggle_button doesn't work,
toggle_button still clickable and value is still changed even though widget is
readonly, there is no effect of readonly attribute on toggle_button widget.

after this commit: if toggle_button widget has readonly attribute then it will
not be clickable, button of toggle_button will be disabled so that user can
easily understand that element is not clickable.

task-2339995

closes odoo/odoo#76426

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

Expected behaviour

A time-off responsible should be able to see the leave-request to validate, even if he is only reponsible and not leave-manager, at least as long as the leave validation is set on 'both' or 'time-off responsible'

Observed behaviour

If the leave validation is set on 'both' (and not on 'time-off responsible' only), the time-off responsible cannot see these leave request in the "To Approve" view, and only the leave-manager can see them.

Problem Root Cause

The issue is coming from a wrong domain definition (cf commit diff).

opw-2595054

closes odoo/odoo#78633

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

This commit ensure the pricelists are properly configured before launching a pos session.

Steps to reproduce:
- Have a V13 with point_of_sale
- Have minimum 2 companies A & B
- Select both companies in the company selector
- Go to Settings / General Settings
  - Point of Sale
    - Check Pricelists
- Go to Point of Sale
  - Open a pos.config PC
    - Set a Pricelist PL as Default Pricelist
- Go to Point of Sale / Products / Pricelists
  - Open PL
    - Set a company (must be different than PC)
- Go to Point of Sale
  - Click "New session" on PC
--> Traceback

In V13, the traceback shows as "Traceback not available"
As from V14, the traceback is shown properly

A variant would be to start the session before changing
the pricelist company then click on "Resume" on PC

closes odoo/odoo#78713

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

Steps to reproduce:

  - Install website_sale module
  - Enable discount and advanced pricelist in settings
  - Create product with sale price 0$ and set a website in
    eCommerce + publish the product
  - Create pricelist PPP with Discount Policy as
    "Show public price & discount to the customer" and selectable in the website
  - Go to the product and set an extra price of 10$ for the new pricelist
  - Go to the product in the eshop and select the pricelist PPP
  - Add the product to the shop cart

Issue:

  The price displayed is 0$ instead of 10$.

Cause:

  Since price_unit equal 0$, not possible to calculate the discount and
  therefore using the 0$ value.

Solution:

  Use price of pricelist in case 'discount_policy' is 'without_discount'
  and price_unit equal 0$.

opw-2652192

closes odoo/odoo#78570

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

When combining two pricelists, the unit price might be incorrect

To reproduce the error:
1. In Settings, enable:
    - Pricelists (Advanced)
    - Discounts
2. Create a product P:
    - Sales Price: $100
    - Available on website
3. Edit the Public Pricelist:
    - Add a price rule:
        - Apply On product P
        - Min. Quantity: SuperProduct
        - Compute Price: Percentage
        - Percentage Price: 63%
    - Discount Policy: Included in the price
4. Create a second pricelist:
    - Add a price rule:
        - Apply on product P
        - Compute Price: Formula
        - Based on: Other Pricelist
        - Other Pricelist: Public Pricelist
        - Price Discount: 25%
    - E-commerce Promotional Code: PROMO
    - Discount Policy: Show public price & discount
5. On the website, add P to the cart
6. Edit the cart:
    - P's quantity: 500
    - Apply PROMO code

Error: The new price is $75 instead of $27.75

`_website_product_id_change` already returns the correct price value, so
the latter shouldn't be computed again (moreover,
`_fix_tax_included_price_company` should use the price with the pricelists
applied instead of the default product price)

OPW-2605804

closes odoo/odoo#75371

Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Part-of: odoo/odoo#78570

Steps to reproduce the bug:
- Go to purchase > Configuration > Vendor Pricelists
- Filters > select the “Active” filter

Problem:
Currently, the filter does not include records that do not have a specified `”date_end”`, even though they are considered active.

Opw-2659829

closes odoo/odoo#78515

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

When invoicing a product with multiple variants and with anglo_saxon_accounting, the COGS would be the wrong amount.
The function _stock_account_get_anglo_saxon_price_unit() was selecting the first BOM among all variant BOMs.
Using the variant_bom_ids when existing prevent this situation.

OPW-2662863

closes odoo/odoo#78428

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

Steps to follow

- Enable group_show_line_subtotals_tax_included
- Create a repair order and add a tax to a line
-> The subtotal doesn't contain the tax amount

opw-2513287

closes odoo/odoo#76427

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

We create the document types data with a csv file, but the active field
should be not updatable so the users could active or inactive records.

closes odoo/odoo#78484

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

Current behaviour:
Unbuilding order use the last BOM created for the product

Expected behaviour:
Unbuilding order should use the BOM that has been used for the MO

Steps to reproduce:
Create a product with a BOM
Create a MO and mark it as done
Create another BOM for the same product
Create unbuild order for the MO
The wrong BOM is selected by default

opw-2636632

closes odoo/odoo#78467

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

closes odoo/odoo#78387

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

There was a missing translation for apply/cancel button in
daterangepicker widget. With this change, we provide the odoo
translation to the library when initializing the picker.

opw-2628117

closes odoo/odoo#78518

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

Since changes made in currency rate default value made in this PR
https://github.com/odoo/odoo/pull/76513

 the date is stored based on user
timezone, and so doesn't work if the test runs around midnight with the
belgian timezone on the servers.

closes odoo/odoo#78452

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

This commit fixes issues with downpayment and credit notes in project
profitability report.

Steps to reproduce opw-2596224:
- Go to sale
- Make a RFQ for a service product with service_policy set at
delivered_timesheet (Timesheets on tasks), set quantity as 10
- Confirm order and create two invoices for 15%, confirm the two
invoices
- Create a credit note for one of the invoice and confirm it
- Go back to the Sale Order and click on Project Overview
=> Inconsistencies (Downpayment reported twice)
- Add an expense
=> Inconsistencies in expense amount untaxed invoiced

This issue is fixed by :
- Excluding downpayments which are linked to a reversed invoice line
- Use expense amount to invoice and expense amount invoiced separetely
in the project overview.
- Do not report not invoiced SOLs in the expense amount invoiced.
- Exclude negative amounts in analytic account which are linked to
credit notes.

opw-2596224

closes odoo/odoo#78310

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

This commit makes the picking search by product more consistent with
the general product search as the following case could happen:

  - Have a product with two variants;
  - Each variant has the following internal reference:
    - Variant 1: 'SoMething'
    - Variant 2: 'SomethingElse'
  - Create two pickings, each one containing one of the variant;
  - Then filter pickings by product and the result will vary:
    - Searching for 'SoMething' -> Found one picking
    - Searching for 'Something' -> Found two pickings

The expected behavior is to find the two pickings in both cases.

opw-2646214

closes odoo/odoo#78085

Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>