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>

Before this commit the search would search for phone numbers that contained a part of a string. The mobile phone would only look at exact matches so if we'd search for '0492700' the only result would be contacts with this exact match. After this commit every mobile phone that contains '0492700' will match and be shown. This allows for quickly finding customers by a partial mobile, just like the phone number does.

closes odoo/odoo#43629

Signed-off-by: Thibault Delavallee (tde) <tde@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

This is the first move to replace Filipino by Tagalog language

Using Filipino (code fil_PH) is problematic as conflicts with Finnish
(code fi_FI) and users having their browser in Finnish were redirected
to the Filipino version of the website (cf discussion at opw-2172710).

This problem was also raised in other softwares like in the below
discssion in Mozilla L10N groups
https://groups.google.com/forum/#!topic/mozilla.dev.l10n/TW2qYyDDNoE



Quoting the discussion in above thread:

> Filipino is the national language of the Philippines, but it is
> commonly referred to (and registered as) Tagalog, since most of the
> terms therein were derived from it (Tagalog).

This commit targets the 12.0 and adds a new language.
In master (future 14.0 as of today), the Filipino will be dropped.
As fil_PH is only translated on odoo-com project but remains at 0% in
other Transifex project, it is assumed the language switch won't
impact too many people.

closes odoo/odoo#43707

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

Correct the rounding of several currencies which should be 0.001.

opw-2172122

closes odoo/odoo#43683

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

- 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>

Before create_multi, in case of invalid syntax used in an XPath, only
the problematic record was displayed. It was not ideal for long
definition but still usable.
Since the views are created using create_multi, the whole file content
is displayed in the error traceback, making it almost impossible to
locate on files with multiple records.

closes odoo/odoo#43542

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

backport from saas-13.1: numbers (and other non-string items) should
not be quoted. And the property name is always present according to
the CDT documentation.

closes odoo/odoo#43578

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

We optimize the search on domains like `[('line_ids', 'in', ids)]`.
The condition is rewritten `('id', 'in', ids1)` where `ids1` is the
result of

    SELECT <many2one_field> FROM <comodel_table> WHERE id IN <ids>

The issue is that the latter potentially returns many duplicate values.
The fix consists in having as few duplicates as possible in `ids1`.

Note that domains like `[('line_ids.foo', '=', 42)]` implicitly benefit
from the optimization, as they are rewritten as the one above with

    ids = comodel.search([('foo', '=', 42)]).ids

closes odoo/odoo#43566

X-original-commit: a13c05fa
Signed-off-by: Raphael Collet (rco) <rco@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>

Improve handling of JS logging in headless runner in order to avoid losing logs
and errors e.g. 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).

This requires additional modifications as we have a fair amount of silent
failures (exceptions or logging.error calls) at the moment:

- downgrade one error to a warning (which becomes an info at the python level)
- cleanup some synthetic / mock errors to better match what comes over RPC (and avoid transient or setup failures)
- tours which end in an action, leading to JS code executing during browser cleanup (and blowing up)
  - if the last step triggers a default (implicit) run, replace by a no-op
  - fix tours for which that does not work by either modifying the last step or adding an additional check step

closes odoo/odoo#41334

Related: odoo/enterprise#7771
Signed-off-by: Xavier Morel (xmo) <xmo@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.

Allows better formatted and commented log_handler items in
configuration files: configparser allows multiline values and
interspersed comments (stripping out comment lines), but while it
removes indent it leaves the linebreaks, so e.g.

    foo =
      bar,
      # qux
      quux

when parsed and split on "," results in `['\nbar', '\nquux']` which is
obviously an issue for logging (as it assumes the leading `\n` is part
of the logger name proper).

Since log_handler items can be fairly long and are not necessarily
self-descriptive as to *why* they were selected for re-configuration,
allowing one per line & comments is helpful.

The tests are willfully triggering ACL failures, logging the
information is noisy and not useful.

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