- 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

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>

Apparently some solutions (e.g. bitnami) deploy odoo using async
workers, and not all pg/psycopg2 features are supported in that mode,
notably COPY FROM (bulk-copying data from a stream to postgres). Work
around this issue by disabling "async mode" as we do the copy (by
resetting the wait callback) then re-enabling it.

While this is not an officially supported run mode, it should Do No
Harm™ for normal operations and could help users and clients.

Of important note: while this fixes an error running in async mode, it
will also prevent the worker from yielding while copy_from is
executing. Hopefully that doesn't take too long (as the entire point
of the copy_from is to be fast) but there you are.

Fixes odoo/odoo#24145

closes odoo/odoo#43472

X-original-commit: c4583cf8
Signed-off-by: Xavier Morel (xmo) <xmo@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>

Originally introduced by https://github.com/odoo/odoo/commit/f3c1e6cfbe70f9dd37cc7c7b3b3464c5b9af280b



closes odoo/odoo#43384

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

Issue

    - Install eCommerce, use Graphene
    - Shop > Any product

    The add to cart button is shifted.

Cause

    Quantity field take full-width & max-width is too large.

Solution

    Remove width: 100% and reduce the max-width.
    Screenshots on OPW

OPW-2166060

closes odoo/odoo#43451

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

The creation of an account with a single character code crashes.

opw-2176764

closes odoo/odoo#43448

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

When a payment line is created, and then the order is reloaded, by the
synchronization feature for example, the name displayed on the payment
line is empty.

This happens because the field name is not saved on the server, so
instead of using it, we are directly taking the name of the payment
method linked to the payment line.

closes odoo/odoo#43385

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

Since new ORM in Odoo, the compute methods should always return values.

In the case of return label in delivery, nothing was returned when there
was no carrier on picking.

So we are now setting the field to False when there are no carrier on
picking.

ISSUE-43270

closes odoo/odoo#43386

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