In a POS session, when using the scanner, if the seller changes the
customer, the prices may become incorrect

To reproduce the issue
1. Create a product P:
    - Sales Price: 38
    - Barcode: 2312345000002
    - Available in POS: True
2. Start a POS session (with debug Window)
3. Scan 2312345010001
    - This is product P with price $10
4. Set a Customer

Error: The price is now $38

Because the price has not been set manually, when changing the customer,
the pricelist is updated and so does the price.

When scanning a barcode that includes a price, the latter should be
considered as manually set.

OPW-2618934

closes odoo/odoo#76076

X-original-commit: e6672427
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>

Steps to reproduce the bug:
- Install inventory, purchase and product_expiry
- Create a new storable product that is tracked by lots or serial numbers and expiration date
- Go to inventory > configuration > Warehouse Management > Operations Types
- In “San Francisco: Receipts” > Enable "Create New Lots/Serial Numbers", “Pre-fill Detailed Operations”, and "Show Detailed Operations"
- Create a new RFQ > select the created product > Confirm the order
- Click on “Receipt”

Problem:
In the created “stock_move_line” the expiration date field is not set

Solution:
When we add a new "stock_move_line" and choose a product, an onchange is triggered in order to set
the expiration_date field even if we do not choose a "lot /serial number name".
So we can replace the onchange with a compute function to do the same thing in the creation.

opw-2634583

closes odoo/odoo#75806

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

- create a second warehouse, resupply from the first
- create a product, replenish W2 from W1
- Goto Inventory Forecast

--> Issue value are wrong.

An OUT is when WH source is Set and WH dest is not set.
An IN is when WH dest is Set and WH source is not set.

closes odoo/odoo#67598

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

Also, remove the duplicated 'edi_document_ids' field inside the view.
'edi_document_ids' is now in debug mode for payments.

closes odoo/odoo#75529

Signed-off-by: Florian Gilbert <FlorianGilbert@users.noreply.github.com>

options="{'no_open': '1'}" is managed for many2one fields.
This commit aims to do the same for x2many fields.

Note: A test will be added later
Part-of: odoo/odoo#75529

closes odoo/odoo#75508

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

closes odoo/odoo#75349

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

Because the "Replenishment" can unlink a lot (thousand of
`stock.warehouse.orderpoint`).
and psql needs to check every Many2one `orderpoint_id` constraint
and without index it takes too much time.

opw-2637321

closes odoo/odoo#76030

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

Issue: When creating a manufacturing order and setting a scheduled date
when no workcenter is set, a traceback shows up

Steps to reproduce :
 1) Install Manufacturing
 2) Enable work centers
 3) Create a manufacturing order, in the work order tab, add a new line
 and set a Scheduled Start Date, confirm the date
 -> Traceback

opw-2633940

closes odoo/odoo#75992

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

closes odoo/odoo#75595

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

closes odoo/odoo#75409

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

Reverts 62bf009 as that is causing that no message is posted in the chatter upon creation.
Althought this might have been an issue before, #56631 removed the addition of the "Application created" message in the message body, so now there was nothing adding it, making the message invisible in the chatter.

TT30413

closes odoo/odoo#75978

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

In case a production order loses its procurement group. The backorder
generation process do not have access to the last backorder sequence
used. This commit set a default value to avoid any traceback.

The new backorder  name will not be guaranteed exact related to the
production sequence but will be unique in any cases.

closes odoo/odoo#76060

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

Considering the field declaration:
https://github.com/odoo/odoo/blob/fe5deb4ee4c8e07aed2f2cff6210271bfaa61476/addons/point_of_sale/models/pos_order.py#L1121


`discount` is a rate, not an amount. Therefore, suppose a discount of
10%, when opening a POS-generated SO, the discount shouldn't be "$10".

OPW-2629493

closes odoo/odoo#75991

X-original-commit: 225fb81c
Related: odoo/enterprise#20621
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>

Bad debt accounts should be of expenses type like the ones in the l10n_de_skr03 addon

opw-2512526

closes odoo/odoo#76019

X-original-commit: 5780e50c
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Hubert Van De Walle <hubvd@users.noreply.github.com>

Reproduce :
- Create an invoice with a sepa QR-code.

Result :
  When reading the QR-code, German banks assume the fisrt 3 characters are the currency name/code, so the first 3 digits of the amount are cut from this amount.

Solution :
  The amount now starts with the currency name/code (3 letters), as prescribed by EPC norms.

opw-2591454

closes odoo/odoo#75816

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

In case there is a `product_qty` column added by a custom module,
`product_qty`, without specifying from which table to take it from
in the view definition, can lead to an ambiguous definition.

```
2021-08-25 12:25:31,624 1145 ERROR db_23001 odoo.modules.registry: Failed to load registry
Traceback (most recent call last):
  File "/home/odoo/src/odoo/13.0/odoo/modules/registry.py", line 86, in new
    odoo.modules.load_modules(registry._db, force_demo, status, update_module)
  File "/home/odoo/src/odoo/13.0/odoo/modules/loading.py", line 424, in load_modules
    force, status, report, loaded_modules, update_module, models_to_check)
  File "/home/odoo/src/odoo/13.0/odoo/modules/loading.py", line 315, in load_marked_modules
    perform_checks=perform_checks, models_to_check=models_to_check
  File "/home/odoo/src/odoo/13.0/odoo/modules/loading.py", line 202, in load_module_graph
    registry.init_models(cr, model_names, {'module': package.name}, new_install)
  File "/home/odoo/src/odoo/13.0/odoo/modules/registry.py", line 370, in init_models
    model.init()
  File "/home/odoo/src/odoo/13.0/addons/stock/report/report_stock_quantity.py", line 126, in init
    self.env.cr.execute(query)
  File "/home/odoo/src/odoo/13.0/odoo/sql_db.py", line 173, in wrapper
    return f(self, *args, **kwargs)
  File "/home/odoo/src/odoo/13.0/odoo/sql_db.py", line 250, in execute
    res = self._obj.execute(query, params)
psycopg2.errors.AmbiguousColumn: column reference "product_qty" is ambiguous
LINE 21: ...AND whd.id IS NULL) OR ls.usage = 'transit' THEN -product_qt...
```

upg-23001

closes odoo/odoo#76020

X-original-commit: 07f0ffad
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>

Steps to reproduce the bug:
- Install sale and inventory
- Create a SO with Qty 10 and confirm it
- Go to the delivery
- Make partial delivery of 5 units and create back-order of remaining 5 units.
- the status of backorder is “waitting”
- Get back to the sale order and cancel it
- the wizard “sale_order_cancel” is displayed, which gives a reminder of some partial deliveries are already done and asks to confirm the cancellation of SO
- Do not confirm the cancellation of SO and click on the cancel button
- Go to the delivery
- The pending deliveries are cancelled

Problem:
The `"action_cancel"` function in the `"sale_order"` model is first called to cancel pending deliveries,
then the `"action_cancel"` function of the `"sale"` model is called, but in that we check if whether one of the deliveries
is already completed in order to display the wizard.

But if the customer clicks the cancel button in the wizard, the SO will not be canceled, but the pending deliveries will already be.

Solution:
Check in the `"action_cancel"` function of the `"sale.order"` model if whether one of the deliveries is already been completed,
if so, do not cancel the pending deliveries and wait for user confirmation in the wizard.

opw-2623404

closes odoo/odoo#75949

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

Steps to reproduce the issue:

- Let's log in Odoo with a user U1
- Create a lead with user U2 as salesperson
- Click on New quotation

Bug:

A SO was suggested with U1 as salesperson instead of U2

opw:2520827

closes odoo/odoo#76009

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

Currently, when we try to shorten the links from content with help of
`_shorten_links_text` method, it throws traceback if the body(content)
we pass is `False`(might happen when we directly pass a model field of
textual type but the field doesn't have a value yet). It's because
the `re` expects the content to be string / bytestring.

This commit fixes the issue by adding a check in this method, which
will simply return `False` if there's no body.

Task-2628586

closes odoo/odoo#75987

X-original-commit: 41f59a61
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

When using module `account_invoice_extract`, it would happen that a
bank account of another company was set on the `account.move`.
This happened when the extract update was done in background via the
cron.
A check on the company of the bank account fixes the issue.

opw-2631833

closes odoo/odoo#75989

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

Steps to reproduce:

  - Install "Field Service" module
  - Go to settings and activate "Recurring Tasks"
  - Go to Field Service -> All tasks and create new one
  - Set for Planned Date : 10/01/2021 14:00 -> 10/02/2021 14:30
  - Check Recurrent and go to Recurrence tab
  - Select repeat every 1 weeks
  - Select Monday

Issue:

  Wrong date for next occurrences (first occurrence is 09/06 instead
  of 10/04).

Cause:

  Calculation based on today date.

Solution:

  Calculate next occurrences based on planned_start_date if set.

opw-2628777

closes odoo/odoo#75793

Related: odoo/enterprise#20529
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>

Steps to reproduce the bug:
- Go to Accounting
- Create an invoice:
    - select a `invoice_payment_term_id`
    - Add product on “account.move.live”
- Save and duplicate it.

Problem:
The `invoice_payment_term_id` field will be duplicated on the second invoice, but not the `invoice_date_due` field

Solution:
The `invoice_date_due` field is set in the `_recompute_payment_terms_lines()` function when adding an `account.move.line`.
As in the duplicate invoice we also have an `account.move.line` we can therefore call this function so that the field is set
https://github.com/odoo/odoo/blob/14.0/addons/account/models/account_move.py#L1043



opw- 2628333

closes odoo/odoo#75476

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

Steps to reproduce:
- create a carrier with a fixed price (1) in the backend
- go to website
- add a product (2) in cart, process checkout and arrive in the payment page
- select the carrier
- the total price is now (1) + (2) which is correct
- in a separate browser tab, add another product (3) in cart, then click on
  continue shopping
- go back to previous browser tab and click on Pay Now
- the total price is now (2) + (3) which is not correct, the delivery cost is
  missing (it was removed due to second tab operations)

closes odoo/odoo#65474

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

Rounding in purchase order is 'UP' which is causing issue when doing
receipt in a different uom than the purchase. Rounding should be
'HALF-UP'

Added test in purchase and sales to ensure this issue is detected in the
 future.

closes odoo/odoo#75975

X-original-commit: 3f6f5868
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

_retrieve_{partner,product,tax} methods were not taking into account a
scope of a company, and methods like _import_ubl or _import_facturx
could end up on creating an invoice with a company mismatch between the
company of the journal and the company of the partner, product or tax.

With this commit, these methods will consider the allowed_company_ids
context value, and calling code should set it to an acceptable value.

OPW-2560795

closes odoo/odoo#75738

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

a9a46cf0 introduced methods _retrieve_{partner,product,tax} but they
were not used in 14.0, whereas they are used from saas-14.1.

This commit changes the account_edi_facturx and _ubl modules so that
they make use of these methods.

Part-of: odoo/odoo#75738

Steps to follow

- Install web_dashboard,website_sale
- Go to the eCommerce Dashboard
- Click on Favorites
- Click on Add to my dashboard
- Go to the Dashboard app
- Click on orders
-> A traceback occurs

Cause of the issue

`this.subscriptions.update` is undefined

opw-2630849

closes odoo/odoo#75719

Signed-off-by: Hubert Van De Walle <hubvd@users.noreply.github.com>

This should avoid disrupting layouts.

closes odoo/odoo#75959

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

The XML-RPC interface has a compatibility shim for binaries as
historically Odoo has returned "binary" data as base64 strings. To
avoid breakages during the Python 3 transition, the shim was
introduced to decode the output binary data (under the assumption that
it'd be ASCII-compatible).

In the case where the data is *not* ascii-compatible, however, it can
generate invalid XML documents: "C0" control codes (with the exception
of tab, LF, and CR) are not valid in XML 1.0 (which XML-RPC is an
application of), however they're perfectly valid string characters and
the standard library's marshaller does not check for them, embedding
them directly in the output document and breaking the client's
decoding.

Work around the issue by replacing such binary data with an empty
string.

While at it, move the bytes shim to the customized marshaller, this
way everything's at the same place and it's not necessary to waste
time trying to understand why the marshaller is just not calling what
it's supposed to call.

Fixes #61919

closes odoo/odoo#74699

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

Currently, if a test fails there's very high chances the DOM will not
be clean, because qunit doesn't have good cleanup APIs. This means a
test failure will always be prefixed by a dump of the page DOM which
is just confusing and makes it hard to find the actual error.

This change updates the OdooAfterTestHook handler to:

* Receive the `Test` itself, instead of adding more information to the
  synthetic object it currently receives.
* Only show the leftover DOM if the test otherwise succeeded.
* Do the entire reporting via `pushFailure`, rather than having
  duplication between an explicit `console.error` and a test failure.
* Update the QUnit.log handler to
  - not show `undefined`
  - try to improve readability by removing the bracketing and quoting

closes odoo/odoo#75939

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

On my system in chrome 92 there are issues of chrome's hitboxes (and
rounding) being off leading to tests failures, something which given
the adjustment in `triggerMouseEvent` had been an issue in the past.

The first test failure was / is in the "correctly display year view"
calendar test, where the very first event dialog would fail to open
when clicking on the `2016-11-16`.

After tracing through fullcalendar, it turned out fullcalendar was
told to hit `2016-11-*09*`, suspiciously 7 days before the cell we
were looking for in a monthly calendar, hinting to an incorrect
vertical offset / hitbox.

Fix by offsetting the top coordinate in `triggerMouseEvent`, but
rather than just increment by one update the entire thing by trigger
the event right in the middle of the element being targeted, that
seems more reliable long-term, though it could be slightly confusing
for events like mouseenter/mouseover/...

The second issue was with a list test, where two cells are supposed to
be sized equally. Apparently the offset sizes are supposed to be the
rounded version of the actual size (which can be fractional), but
dumping the information of `foo` and `text` I'd get real widths (via
getBoundingClientRect) of respectively 480.46875 and 480.5, and
offsetWidths of 481 and 480 (the smaller of the two in "real size"
is rounded higher than the other one).

In Python we might use `assertAlmostEqual` for this, but we've
apparently not introduced this in JS take the real width and round up
by hand, this fixes the issue as both end up at 481.

Aside 1:

Before finding out the actual root cause I landed in
`_onYearDateClick` with missing data in the events so looked at the
API to figure what I was looking at, and turns out fullcalendar's
event object has documented properties to get the date-converted start
and end bounds of the event, so use that directly instead of doing the
same thing by hand.

Aside 2:

The attributes passed to `triggerEvent` in `triggerMouseEvent` are
pretty much nonsensical, we're getting the element's location using
`getBoundingClientRect` which is based off of the viewport, but
setting the keys

* `screen(X|Y)`, which should be the location of the hit relative to
  *the physical screen*
* `page(X|Y)`, which should be the location of the hit relative to the
  page / document (so takes in account the content scrolled off-screen)
* `layer(X|Y)`, which is the position of the hit relative to the
  nearest positioned (non-static) element, falling back to page if
  there isn't one

The one attribute which matches the semantics / reference of
`getBoundingClientRect` we didn't even set, instead it would be
automatically copied from `pageX`/`pageY` by the events mapping.

Fix that by just providing `clientX`/`clientY` and updating the
mapping functions to not overwrite it.

If the others are needed they should be computed properly based on the
document's bounding client rect and scroll information, as well as the
window's screenX/screenY (and offsetParent for layerX/layerY though
that seems unlikely to be necessary).

closes odoo/odoo#75900

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

Problem 1 steps to reproduce the bug:
- Install `l10n_cl`
- Create a new company
    - Choose for example Algeria in country.
    - Enter this VAT number: CL220604497
- Save
- edit
- Change the country to Chile

problem:
VAT number is not formatted according to the Chilean VAT formatting,
Because in the write function we do not trigger the VAT formatting when the country changes

Bug introduced in this commit: https://github.com/odoo/odoo/commit/11ec94df926db98265d26af1072a0c8bf1843083

Problem 2, steps to reproduce the bug:
When you install `l10n_cl`, a Chilean company is created with these demo data: https://github.com/odoo/odoo/blob/7cc252908b33b7d77d45d0630464e203b25b09dc/addons/l10n_cl/demo/demo_company.x15ml#L

- The VAT is formatted according to the standard formatting instead of the Chilean vat formatting,
Because the field `" l10n_latam_identification_type_id "` is not defined: https://github.com/odoo/odoo/blob/f3a66dd65d041ffc7367d85d5603e9627efb9f2b/addons/l10n_cl/models/res_partner.py#L33-L34

so we will have this result: CL220604497 instead of 22060449-7

- create a vendor bill with this company
- try to print it
- a traceback is triggered, because we call the `_format_dotted_vat_cl` function which divides the vat in two parts
based on the dash and then processes the result without checking that there are two elements in the result.
As in our case here. The vat has no dash in the middle, so we will only have one part
an error is triggered when the function tries to access the 2nd element

https://github.com/odoo/odoo/blob/2b500c12c2540e593f3a243bf80de28bd335b7be/addons/l10n_cl/views/report_invoice.xml#L53



opw-2630877

closes odoo/odoo#75581

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

Github release: https://github.com/odoo/owl/releases/tag/v1.4.4



Release notes:

- fix: overlapping multi-class in t-att-class

closes odoo/odoo#75922

Signed-off-by: Samuel Degueldre <sdegueldre@users.noreply.github.com>

Currently, during the slide tour, while adding 'Section' from the
website, the modal is opened, and the tour/bubble for this step is
added at the bottom of the input which introduces a vertical scrollbar
to this simple modal which looks ugly.

This commit removes this step (and thus bubble for input), and simply
provides a placeholder for this input.

And, for the section modal next step ('Save' button), we simply improve
the wordings of the message, which now asks the user to pick
a name for the section first.

The same issue also happens while uploading new 'Content' from the
website, and so to avoid scrollbar here, this commit also adds little
bottom margin for the anchor (so that there's enough space for tour
bubble).

Task-2616529

closes odoo/odoo#74816

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

On payment creation, when changing twice the payment's journal, if the
first journal already has some lines and the second one doesn't have any
lines, the payment name will be incorrect.

To reproduce the error:
1. (If present, delete all payments)
2. Create and save a payment P01:
    - Journal: Bank
3. Create a second payment P02 (do not save it):
    - Journal: Bank
4. Change P02's payment: Cash
5. Change P02's payment: Bank
6. Save P02

Error: The name of P02 is "CSH1/2021/08/0001", which would be correct if
it was a Cash payment. This error has a consequence: suppose the user
creates a third payment (journal: Bank) and confirms it, its name will
be "CSH1/2021/08/0002" (again, name linked to the incorrect journal)

On step 4, when changing the journal to Cash, since the latter hasn't
any payment, the server returns a new name ("CSH1/2021/08/0001"). Then,
on step 5, when changing back the journal to "Bank", since the latter
already has a payment (P01) and since the current record already has a
name ("CSH1/2021/08/0001"), the server doesn't change it and the
`onchange` response doesn't contain anything. As a result, when saving
the payment from the client side, the wrong name is included in the data
("CSH1/2021/08/0001"). Regarding the consequence: later, when creating
and confirming a third payment, the server will take the name of the
previous one in the same journal and will increment it
("CSH1/2021/08/0002").

OPW-2601668

closes odoo/odoo#75504

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

When a sale.order containing a slide.channel registration product is confirmed
by a person that does not have rights on slide.channel (typically a salesman),
the system will throw an error.

This commit forces the addition of members by using a sudo on the
"_action_add_members" method.

We assume that when confirming a sale.order, we want to add the members and
enable their access to the course even if the person confirming the sale.order
does not have e-learning privileges.

OPW-2580128

closes odoo/odoo#75872

X-original-commit: ecac935d
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>

Without this, the warning isn't very actionable.

closes odoo/odoo#75847

X-original-commit: afe7c989
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: Wolfgang Taferner <wtaferner@users.noreply.github.com>

This fixes a bug about alignment, which shifted the mega menu with the
narrow size by 50%. This bug was triggered in multiple headers:
- sidebar
- hamburger
- magazine

task-2502208

closes odoo/odoo#75597

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