At 795c7b0a the external dependencies was changed from trying
to import 'ldap' to checking than 'pyldap' package was installed.
The problem is that pyldap is a unmaintained library that should no
longer be used, as explained on the package page:
https://pypi.org/project/pyldap/


"The pyldap fork was merged back into python-ldap, and released as
 python-ldap 3.0.0."

Having pyldap version >= 3.0 installs python-ldap automatically and
will not cause any issue.

The Debian control file package name is adapted to use the latest.

The "ldap" externalm dependency defined in __manifest__.py will cause
pkg_resources.get_distribution() to fail in both case ("python-lap" or
"pyldap"), but the "import" fallback will succeed. For that reason, the
log warning is turned into a log info.

closes odoo/odoo#40249

Note: This library should be replaced by the pure python "ldap3" library.
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

Display the `display_name` rathe rthan the `name` in order to include
the variant specification.

opw-2170400

closes odoo/odoo#43725

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

This commit will fixed the error when product has some stock quants
and product category with 'Automated' valuation method, is set to that product.

==============================

Steps to product the above mentioned error:
1. Create product with any category which has 'Manual' valuation method.
2. Update 'On Hand' quantity for the same product.
3. Create product category with valuation method set to 'Automated'.
4. Now set the above product category to the same product which you created in step 1.
5. And Click on the save button.

==============================

Also edit the test case.

closes odoo/odoo#43721

Task: 2155804
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>

closes odoo/odoo#35437

Task: 2042430
Closes: 35437
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>

Closes odoo/odoo#37814

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

Closes odoo/odoo#37814

- Create a FIFO product, Automated
- Make some stock
- Create a SO, add the product
- On the SO, add an analytic account
- Validate the picking, create the invoice
  => the analytic info are propagated to the invoice, as expected
- Validate the invoice

The analytic info is propagated on the COGS entries, in particular the
the output account, which is incorrect.

opw-2008567

closes odoo/odoo#43684

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

`AttributeError: 'tuple' object has no attribute 'startswith'`

When given headers that are tuples. They are expected to be string, as per [1].
The issue was introduced with [2], indeed the code was moved from inside a dict
where `,` was the usual dict separator to outside of a dict where `,` at the end
made them tuples.

To reproduce the issue, run the `test_mail` suite after having
`website_mail_channel` installed.

Issue highlighted as part of task-2178641

[1] https://docs.python.org/3/library/email.policy.html#email.policy.Policy.header_store_parse


[2] cae1c397

closes odoo/odoo#43688

X-original-commit: 3bda53a7
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

Issue

    - Install Employees & Studio
    - Configuration > Check Skills Management
    - Go on an employee form
    - Remove all data in Experience, Education & Skills
    - Open Studio
    - Click in the blank space before Skills
    - Edit Form View

    Traceback

Cause

    The ORM tries to get the parent fields because the generated
    datapoint includes them. (45bc7c92)

    Normally the parent model is the same than the child model
    but not in studio.

Solution

    Merging the fields in the datapoint only if the models are the same.

OPW-2125214

closes odoo/odoo#41317

Related: odoo/enterprise#7179
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Because of the law of the 1st december 2019, we can't pay with 1 or 2 cents anymore.
We have to round the total price to the 0.05 unit.
If the customer pay without rounding values, it triggers an error.
Before the order is finalized, we add a line with a product rounding to round the total amount.

task-id: 2035010

Backport of PR: https://github.com/odoo/odoo/pull/40958
Backport of PR: https://github.com/odoo/odoo/pull/39488



closes odoo/odoo#41327

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

Steps to reproduce:
- Install website_sale_wishlist,stock,sale_management,contacts
- General Settings>Sales>Multiple Sales Prices per Product
- Create or edit a product, assign 2 different prices in pricelists A and B
- Publish it to the website
- If your user is Mitchell Admin, go to its related res.partner, Sales &
Purchases tab/Pricelist, choose pricelist B
- Create a public user and assign it pricelist A
- Go to the website/shop
- Reach out the product and add to the wishlist

When the current user is internal the product page will display price of B,
but if you add the product to the wishlist, whishlist displays public price
Same for the portal user.
This happend because to avoid returning 500 when the product is
unpublished c93f371d the product is
filtered using sudo() but the recordset is also returned with the sudo
environment. Using it just to filter solve the issue

opw-2166484

closes odoo/odoo#43642

X-original-commit: 4335f9db
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

The `ref` field on `account.move` is not required and can yield a falsy
value. This produces a TypeError while doing the comparison in sorted().

closes #42434

closes odoo/odoo#42708

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

closes odoo/odoo#39218

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

- Create some stock in WH/Stock for product A
- Create some stock in WH/Stock/Shelf 1 for product B
- Create a Repair Order for Product A in WH/Stock
- Add a line in Parts with B, leave the location to WH/Stock
- Process the order until the end

Negative quant is created in WH/Stock for B instead of using the
quantity in WH/Stock/Shelf 1.

We do a best effort in order to reserve the quantity in the
sub-locations.

opw-2177352

closes odoo/odoo#43631

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

1- create a group payment (10 ~ 15 invoices);
2- Open the created journal entry.

The first issue we see is that the breadcrumb is too big to the size of
the screen.

3- Open the 'Reconciled Entries'.

Before this commit, the screen was completely shifted and not visible.
This occurs also because the breadcrumb is too big.

Now, the references added to the name of the entry is limited to 50
characters.

opw-2166551

closes odoo/odoo#43614

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

The discount_amount didn't consider the quantity on Sales Order Line.

e.g:

100€ | 10% discount | 8 products

--> discount_amount was 10 € instead of 80€

Fixes #43242

closes odoo/odoo#43613

X-original-commit: b8a1370c
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

Before this commit, when clicking into the 'Payment Matching' button
from a payment, sometimes an error is raised. This occurs because the
active_id is the one of the payment, and not the one of the journal, and
when performing the research with the id of the payment in the table of
the journals, sometimes the id is out of scope.

Now, we check before performing the research that the model of which the
id belongs is the journal.

opw-2166551

closes odoo/odoo#43563

Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>

Bug in 13.0 regarding company_id field of partners when creating them from
their parent contact or when setting their parent.
The field 'company_id' of res.partner is set by an onchange on 'parent_id'
to that of it's parent; unfortunately the field is readonly if parent_id
is set and not set to force_save.
Furthermore, creating a child partner from the main one (in the 'Contact'
tab of the main partner form view) does not follow the same behaviour
(company_id is unset in that case, meaning that children don't have
the same company as their parent).
Since the company_id is already set by an onchange when we change 'parent_id'
and set to readonly in that case, I assume the expected behaviour is actually
that children partners should have the same company as their parent by default.

Fine tuning of 7b49f583

opw:2176384,2167106

closes odoo/odoo#43539

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

- Create a new Product
- Add a BOM to this product
- Set the BOM to be a kit
- Add components to the BOM
- Create a PO for the components for a qty of 5
- Confirm the PO but don't transfer the products
- Check the phantom kits outgoing_qty and incoming_qty they will match

A Phantom Kit Products outgoing_qty and incoming_qty are identical

Closes #43447

closes odoo/odoo#43570

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

Currently when you open, for example, 5 chat windows on the desktop,
each of those windows will be opened on mobile as well.
The big issue with that is that I have to shut down all windows before
starting to work on the application.

To make things simple, you have to explicitly open chat window to
make it appears on mobile. Synchronization is blocked in both direction.
We don't update the chat window state on the server and we no longer
consider notifications (bus) about it.

Tests were added in enterprise.

Task ID: 1891952

Backport of https://github.com/odoo/odoo/pull/41052



closes odoo/odoo#43546

Related: odoo/enterprise#7795
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>

Create multiple tax and assign them to the same tax group.
Create an invoice, with two lines, each one with one tax of the group.
Save and click on "Preview" or print invoice.

The tax group will be reported applied on just the first line
This append because of 4d62a94a.
Reverting commit to restore the former behavior in which the tax base
amount is added for every line in which the tax group component is
found. While this other behavior could be an issue for some user the
behavior is more consistent accounting-wise and the template could easily
be changed to adapt to user needs.

opw-2170069

closes odoo/odoo#43254

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

Fix various tours which either have transient failures due to logging
the entire browser lifecycle or don't deal well with the last step
being suppressed if no explicit `run` is provided.

* test_website: add a warning final step for the page reset as there's
  no way to actually run a tour step in the recovery page (because
  it's asset-less)
* website: remove final step's action in reset password tour, it's
  relatively low-value and adding a proper followup is probably not
  worth the effort
* website: add final check step in dashboard tour, as we want to check
  that the dashboard gets loaded, but we don't want that to be dangling

Unfortunately caught in a really wide try/except clause where it was
completely silenced, causing a lot of stuff to be archived instead of
deleted.

closes odoo/odoo#43531

Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>

A number of steps have a last step which may trigger some async
operation (e.g. reopen a menu, close a modal, ...).

This async operation can span over the cleanup of the browser, in
which case its callback will try running in a seriously broken state.

It's simpler to just assume that the last step's side-effects should
not matter to the test's success and interpret it as a "wait" (used
only for its trigger to wait until a proper end-state).

There was a question of whether we should ignore all final actions,
all non-function actions, or all implicit (default) actions. The
latter seems the least disruptive as hopefully developers having
provided a `run` in the final action have a good use case for it.

Log that note columns have been created for new users as debug rather than info

Several XHR error handlers expect a data.arguments member which holds
the args tuple from the Python exception.

Some have alternate codepaths for "xhr errors" but several
don't (e.g. addons/payment/static/src/js/payment_form.js:142,
addons/web/static/src/js/services/crash_manager.js:229,
addons/website/static/src/js/content/website_root.js:167) and will
thus blow up on synthetic client-side xhr errors.

Modify the synthetic errors so they provide that member as an array.

Commonly happens during teardown of POS tests and we really don't
care, so avoid blowing up the runbot build.

not sure it does anything useful but you never know

Sink handling of JS logging, exceptions and websocket timeouts so
calls other than _wait_code_ok handle them somewhat properly: the
issue fixed by odoo/odoo#41231 passed because it occurred during
module loading, which happens during initial page loading (browser_js
> navigate_to > _websocket_wait_event), which ignored logs (and
exceptions though here it's a console.error log), and as a result
reported no failure (and would simply miss that specific test as well
as every test following it).

Also since ChromeBrowser treats console.error as an exception,
important messages should be logged atomically. Merge two consecutive
console.error into a single one at the loading of modules so we don't
just get an exception "error while loading foo.bar" without any of the
useful details.

That ChromeBrowser treats console.error as exception is also why the
new method gets a flag (to suppress this behaviour): in the case of
two console.error, upon encountering the first it's treated as an
error so we try to take a screenshot, which goes through the messages
in order to get the screenshot response, which encounters the second
console.error, which gets treated as an exception, which hides the
first error.

Instead, screenshotting (and more generally _websocket_wait_id) should
treat console.error as a regular logging call, probably.

Also run JS tests in debug=assets for easier debugging (ha!) and
improve formatting of exception object when receiving an exception:
* if we can get a description on an `exception` remote object just
  print that, it's formatted to show the exception type, message &
  traceback
* otherwise format the garbage that is an "ExceptionDetails" object

Install Projects, documents, calendar, website, crm.
Under Settings enable "File Centralization"
Now go to Projects, enter in a Task, click on "schedule activity".
On the activity form under "Activity Type" choose Meeting, click on
"Open Calendar" button.
Choose a slot, edit the event, add a contact type individual, save
Error will popup.

This is caused by the whole flow of creating a new document for the
invitation.ics generated for the meetings which has to be sent via email
but get detected as an attachment to be sent into the document app as
well.

Disabling the document creation since it is not a relevant attachment

opw-2150770

closes odoo/odoo#43341

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

Do not crash if the commercial partner doesn't have a name.

opw-2158809

closes odoo/odoo#43391

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

As Mitchell Admin:
- Install Leaves
- General Settings > Multi Company
- Create companies A (YourCompany) and B
- Mitchell Admin should be an employee of A, not B
- Switch to company B
- Go to Leaves > Managers > All > Allocations

An AccessError is raised in `_compute_number_of_hours_display` because
we try to access `employee_id.resource_calendar_id.hours_per_day`.

After this AccessError is solved, several others are raised when
accessing a record. They are solved in this commit.

opw-2160542

closes odoo/odoo#43504

X-original-commit: 9413222e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

When writting number on the point of sale keypad, if you click on the
"+/-" button, you will get 0 (with buffer "-0"), but then you need to
backspace 2 times to remove "-".

This seems odd since this mean that:

=> "+/-" "backspace" "backspace" "5" will get 5.0 units
=> "+/-" "backspace" "backspace" "backspace" will remove line

instead of what would be expected:

=> "+/-" "backspace" "5" will get 5.0 units
=> "+/-" "backspace" "backspace" will remove the line

opw-2169157
closes #43495

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

Issue

    - Install Accounting
    - Upload XML bill (tried with a MX one)

    No decoder was found.

Cause

    The _create_invoice_from_xml method gets decoders from overrides of
    _get_xml_decoders. There is only 2 overrides: Belgium & Italy.

    All others countries are not handled. So, this error blocks
    the user.

Solution

    Log the error instead raising it. (Reproduce V12 behavior)

OPW-2170516

closes odoo/odoo#43393

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

Issue

    - Install Time Off
    - Marc Demo > Create leave request
    - Admin > Validate the leave request
    - Marc Demo > Add an attachment

    Nothing happens

Cause

    There is a access right issue that is not handled in the
    JS.

Solution

    Handle it by doing a do_warn.

OPW-2171791

closes odoo/odoo#43464

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

Since [1] `computer_hdd_attribute_lines` is archived instead of unlinked in
`TestSaleProductAttributeValueConfig` which leads to indeterminism in tests due
to the missing `flush`.

Indeed `flush` is necessary before `invalidate_cache` since [2] if the data
that are pending being written must be saved to the database before the cache
invalidation.

[1] which highlighted the issue was merged after v13.0, but it still makes sense
to merge the current fix in the earliest version possible.

[1] 5361706e
[2] 9920f20e

closes odoo/odoo#43436

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

When the french certification is installed for the pos, there is an error when we use it in a company that is not french.
The format of the values sent was not identical to the format of the values expected.
Now the order and the server_id are sent separetly to match the parent function.

closes odoo/odoo#43460

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

- Create a 10 % purchase tax with price included
- Create a Purchase Receipt with a price unit of 100 and the 10 % tax

The total is 90.91 + 8.26 = 99.17.

The root cause of the issue is that... actually I have no idea. For some
mysterious reasons, in case of an `in_invoice`, `in_refund` and
`in_receipt`, we go through `_compute_base_line_taxes` when the price is
changed. In case of the `in_receipt`, we compute the tax based on the
`balance` (= 90.91) rather than the price unit, which screws things up.

Note that in case of `out_*` moves, we simply don't go through
`_compute_base_line_taxes` at all, so Sales Receipts are fine.

opw-2170975

closes odoo/odoo#43456

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