When returning a dropshipped and subcontracted product to the supplier
location, the received quantity of the PO line will be incorrect

To reproduce the issue:
1. Create two storable products P_compo, P_Finished
2. Create a BoM:
    - Product: P_finished
    - Type: Subcontracting
    - Subcontractors: a subcontractor S
    - Components: 1 x P_compo
3. Create and confirm a PO:
    - Vendor: S
    - Deliver To: Dropship
    - Drop Ship Address: a partner P
    - Products: 1 x P_finished
4. Validate the receipt
5. Create a return with 1 x P_finished:
    - Update SO/PO quantities: True
    - Return Location: Partner Locations/Vendors
6. Validate the return
7. Go back to the PO

Error: The qty received is 2, it should be 0

There is currently no code to handle the return of a dropshipped product

OPW-3030895

closes odoo/odoo#105793

X-original-commit: 8276a9b5
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>

When returning a dropshipped and subcontracted product to an internal
location, the received quantity of the PO line will be incorrect

To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create two storable products P_compo, P_Finished
3. Create a BoM:
    - Product: P_finished
    - Type: Subcontracting
    - Subcontractors: a subcontractor S
    - Components: 1 x P_compo
4. In Locations, edit WH/Stock:
    - Return location: True
5. Create and confirm a PO:
    - Vendor: S
    - Deliver To: Dropship
    - Drop Ship Address: a partner P
    - Products: 1 x P_finished
6. Validate the receipt
7. Create a return with 1 x P_finished:
    - Update SO/PO quantities: True
    - Return Location: WH/Stock
8. Validate the return
9. Go back to the PO

Error: The qty received is 2, it should be 1 (it should not be 0 since
the product has been returned to an internal location)

In `/purchase_stock._compute_qty_received`, there is already a code to
anticipate such a situation (i.e., a user who returns a dropshipped
product to his stock location):
https://github.com/odoo/odoo/blob/bf3c398f0644f690c64815b2b6e298aed7bedd70/addons/purchase_stock/models/purchase.py#L300-L305
However, the methods `_is_dropshipped` and `_is_dropshipped_returned` do
not include the feature subcontracting + dropshipping. This is the
reason why, in `_compute_qty_received`, the above condition is not
respected and why we add the return stock move to the received qty.

OPW-3030895

X-original-commit: 0486e2e5
Part-of: odoo/odoo#105793

Splitting the method `_get_order_lines` will allow making it
inheritable, this way more order line fields can be added and expand
them easily and avoid having to overwrite it.

closes odoo/odoo#105599

Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>

Before this commit: when `Limited Products Loading` is enabled in
PoS settings, and `Load all remaining products in the background` is
disabled, the search bar only uses `name` to look for products to fetch
from database. This causes problem when for example the user is using
barcodes to identify products.

To fix this, the search domain should be expanded to include all of the
fields which are normally used when searching for products.

opw-3055960

closes odoo/odoo#105748

Signed-off-by: Masereel Pierre <pim@odoo.com>

Pingen does not support localized country names, as such we need to force English locale.

closes odoo/odoo#105176

X-original-commit: 006dcbf8
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>

Some missing aria attributes from 14.0 are reintroduced.

They are required for screen reader users to be able to know if menus
are opened and if menuitems are checked (e.g. if a filter is applied).

closes odoo/odoo#105163

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Luis González <lgonzalez@vauxoo.com>

Dropdown menus/items were refactored and moved to OWL when migrating to
15.0. Now, the focus is always on the dropdown button, which captures
and handles all keyboard events, to be able to move over the menus.
Currently-selected item is highlighted by toggling classes.

However, since the focus is always on the dropdown button, screen
reader users are  no longer able to know what menu item is being
selected, as it's only a visual change (in previous versions, the focus
actually moved to the selected element).

The above is fixed by making the activeElement follow the visual change.

Part-of: odoo/odoo#105163
Co-authored-by: Luis González <lgonzalez@vauxoo.com>

There are specific accounts that should be used for tax groups for
each version of the CoA

t-3059059

closes odoo/odoo#105736

X-original-commit: 453cf0b6
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>

closes odoo/odoo#86322

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

closes odoo/odoo#103409

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

Steps to reproduce:
- install the "Extended Adresses" module;
- in the configuration menu --> countries, edit the street format for Belgium to "  %(street_name)s" (with whitespaces)
- create a new contact;
- select a contact suggested by the auto complete feature (for example Odoo)

Issue:
    Some letters are removed if we add whitespaces in the street format (street_name field has the value "e du Laid Burniat 5" instead of "Rue du Laid Burniat 5").

Cause:
    The function which splits the raw address taking into account heading characters.
    Therefore the function truncates whatever is in front of the first field of the street format which is normally the image of the address (street_raw).

    Example 1: (correct use)
    street_raw = "header Rue du Laid Burniat 5"
    street_format = "header %(street_name)s"

    street_name = "Rue du Laid Burniat 5" --> OK (format address is properly configured to match with street_raw)

    Example 2: (incorrect use but desired behavior)
    street_raw = "Rue du Laid Burniat 5"
    street_format = "header %(street_name)s"

    street_name = "Laid Burniat 5" --> truncation is expected (7 leading characters are removed) (format address is not properly configured to match with street_raw)

    Example 3: (incorrect use and unwanted behavior)
    street_raw = "Rue du Laid Burniat 5"
    street_format = " %(street_name)s"

    street_name = "ue du Laid Burniat 5" --> truncation is not expected (1 leading character is removed) (format address is "properly" configured but with whitespace)

Solution:
    Remove whitespaces before street format when editing this field to prevent truncation of the field value.

opw-2964457

closes odoo/odoo#105568

X-original-commit: a6e8e0f6
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>

Fixes a small but massive typo that prevents snailmail from working on
version 14 to 15

closes odoo/odoo#105720

X-original-commit: dc3ed690
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
Signed-off-by: Solan Delvenne (sode) <sode@odoo.com>

closes odoo/odoo#103215

Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>

The account 81 to 89 were misclassified, this PR fix the issue

closes odoo/odoo#104074

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

Steps :
Go to project > settings.
Check 'timesheet' config and save.
Uncheck it back and save.

Issue :
See errors in the logs, due to on delete restrict.

Cause :
Record 'hr_timesheet.internal_project_default_stage' from data
is deleted when hr_timesheet is uninstalled.
Yet some project task records still use it, so we can't delete it.

Fix :
Delete the corresponding ir.model.data to keep the stage,
but unlink it from the 'hr_timesheet.internal_project_default_stage' ref.

task-2998416

closes odoo/odoo#101633

Related: odoo/enterprise#32022
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>

Steps:
Go to project > settings.
Make sure 'timesheet' option is checked.
Uncheck it and save.

Issue:
After loading, it is set back.

Cause:
In ResCongifSettings.execute()...
First the expected modules are uninstalled.
Then 'industry_fsm_sale' is in to_install (??),
so it is installed back, whiches makes no difference
with the original state.

Fix:
Not that the issue appears before 15.3, because
with https://github.com/odoo/odoo/pull/83104/commits/216aa6f27d9c3b68d334f79c1597c8073cd5adbf
resolves it. This commit backports it to 15.0.

task-2998416

Part-of: odoo/odoo#101633

closes odoo/odoo#105666

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

Model `account.move.line` has extended `_name_search` to clarify `ilike` search.
However, the new domain replaces original domain, instead of making a friendship.

STEPS:
* add custom Many2one field to any form (e.g. SO)
* add domain for the field, e.g. ` [["parent_state", "!=", "draft"]]`
* try quick search for the new field

opw-3037878

closes odoo/odoo#105572

X-original-commit: 8966d802
Signed-off-by: William André (wan) <wan@odoo.com>

Upon updates, the `active` field of `ir.ui.view` behaves differently
depending on whether the view is defined by using the `<template>` tag
or the `<record>` tag.

When using `<record>`, it behaves like any other field and gets updated
with the new value (notice that for qweb view, you should rarely rely
on this as if users customized those views with the website builder,
they are duplicated (COW)... updating the active field without migration
script would then be a source of errors).
When using `<template>`, it is not updated since [1], except for new
records since [2].

This commit adds a comment to the `active` field to help developers find
out about this difference.

See this [discussion].

[1]: https://github.com/odoo/odoo/commit/2d296cb77922d33be2dc45b900191fac34bda429#diff-175c28787c272a219b9275f79262a48af9aa029e718f45077fd609737559e84eR803-R804
[2]: https://github.com/odoo/odoo/commit/f1c70d4cc943ac4eb81a85a9dc005de34cd2060a#diff-175c28787c272a219b9275f79262a48af9aa029e718f45077fd609737559e84eR801-R804
[discussion]: https://github.com/odoo/odoo/pull/104836#discussion_r1013155860



Related to task-2963840

closes odoo/odoo#105591

X-original-commit: 454a47fd
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>

closes odoo/odoo#105640

X-original-commit: 68f29fda
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Backport of 747ac40b

Currently the test in stock_account/tests/test_stockvaluationlayer.py for Anglo-Saxon accounting is slightly wrong as it uses a company that can change depending on which l10n is installed (mainly coming from the company's country_id and account_fiscalcountry_id). This means that the test might be running with different settings from one time to another (= non-deterministic) and fail in some circumstances.

This commit fixes this issue by making this test an AccountTestInvoicingCommon test instead. This allows for the use of a test company, always the same. Of course, a few items have to be re-created since they can't be inherited anymore.

closes odoo/odoo#105205

Signed-off-by: Quentin De Paoli <qdp@odoo.com>

Steps to reproduce:
 - create an event with a single ticket that has a description

Bug:
 The default quantity on the website is set to 0 where it should be 1

Cause:
 On this commit[1] adding description to a single ticket was done by
 applying the multiple tickets layout but this also sets qty to 0

Fix:
 removed the condition and added the description to the single ticket

opw-3018139

[1]:https://github.com/odoo/odoo/commit/9c4c953d004acaf916df348b670182b48b85d165



closes odoo/odoo#104399

Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>

closes odoo/odoo#105526

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

The `lang` value returned by this route was not always
consistent with returned translations: when `lang` is
not activated on the database, the translations defaults
to the session language instead.

To be consistent, return `lang_parameters["code"]`
instead, so that both values match.

closes odoo/odoo#105563

Signed-off-by: Olivier Dony <odo@odoo.com>

Using the "gps picker" (for example with the "Google Map" snippet) was
not flawless. The autocomplete menu which shows up when the user enters
an address is handled by the gmap API. It was actually not working at
all on Firefox for an unknown reason. Not listening to blur events on
the input seems to solve the issue. This commit also prevents triggering
a value change if the same address is reselected which seems to make
address changes a bit more robust too.

opw-2976261

closes odoo/odoo#105485

X-original-commit: 50bf0b7f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Some part of the google map API was deprecated and showed a warning
at each snippet redraw. Probably harmless but since the related API are
really capricious, best satisfy them as much as possible, even in
stable versions.

opw-2976261

X-original-commit: b761c8fe
Part-of: odoo/odoo#105485

Before this commit, when adding a google map snippet in the DOM, the
user was asked for its API key if not already configured, thanks to an
user-friendly dialog. However, in the case it was misconfigured (while
the editor dialog prevents some misconfiguration, configuration via the
backend allow any random key to be given), the UX was terrible: the
google map is simply removed without any notification.

Misconfiguration can be:
- Invalid API key
- "Maps JavaScript API", "Places API" or "Maps Static API" not enabled
- Billing not enabled

Now notifications/messages warn about those things and reopens the key
configuration dialog, which contains links to the gmap API documentation
and now more information.
Hopefully, this can be improved even further later. Indeed, this is
still not perfect as there is no reliable way to understand google
responses. E.g. even with the three mentioned API and billing enabled,
sometimes the google map API still returns errors indicating "not
enabled APIs" but it cannot be reproduced reliably. During my test it
was systematic for 15min at some point but now there is none, ever. Like
if there was a delay after enabling an API on the google console before
it stops sending errors... although the API works immediately.

Notice that in 15.0, this snippet is shown in debug mode only and we
encourage users to use the new "Map" snippet which does not require any
configuration.

opw-2976261

X-original-commit: a5282701
Part-of: odoo/odoo#105485

This commit is to compute correct lot number for serial/lot tracked
products on refund invoices

Reproduction:
1. Install Sale, Accounting, Inventor. In setting of Inventory, enable
Lots & Serial Numbers, Display Lots & Serial Numbers on Invoices,
Display Lots & Serial Numbers on Delivery Slips.
2. Create a product with lot/serial number
3. Create a order of this product, confirm. Click the delivery and
validate it.
4. Back to the SO, create an invoice, confirm and print it, the serial
number shows.
5. At the invoice, click “Add credit note”, choose “Full refund” (2
invoices for the SO) or “Full refund and new draft invoice” (3 invoices
for the SO), the lot number doesn’t show in new draft invoice or the
refund invoice

Reason: the current lot number tracking workflow focused on invoicing
different numbers of products and making sure it gets the correct
lot/serial number. It doesn’t include the refund invoice case.

Fix: since the current working logic works great with invoicing products
which are delivered from the warehouse to the customer, we can reuse
this logic for refund invoices for products which are returned from the
customer to the warehouse. In the refund and return case, we switch the
calculation of warehouse and customer. Thus, a return can be seen as a
delivery from the customer to the warehouse.
In the code, we set a new variable, return_source_usage, to check if the
account move type is a delivery or a return. If it’s an invoice for
return, we take the opposite of the previous invoiced product quantity.
Because in a refund, previous invoiced is now considered as refunded.
In the original workflow, when sml.location_id.usage is “customer”, it’s
a return and we update the returned_qty and the related quantities. In
the new workflow, if the invoice is a refund one, we do the same steps
when sml.location_id.usage is “internal”, e.g. when the stock move line
is a delivery, we consider it a return.

For refund invoices. There are two choices of refunding:
1. refund and a refunding invoice: 2 invoices for the order, one is the
original one, another is the refund
2. refund and create a new draft invoice: 3 invoices for the order,
original one, a new draft one and the refund.

In the second case, we will create a new draft invoice. If we simply
apply the original work logic, the lot number will not be printed on the
draft invoice. This is because the previous amls list includes its
original invoice. We have to filter out the duplication of the same
invoice to print the right lot number for the new draft invoice.

Added the report test for two refund cases, one for cancel (Full refund)
and another for modify (Full refund and new draft invoice)

opw-2879714

closes odoo/odoo#105282

X-original-commit: 012e25f2
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Liu Jinjiu (jili) <jili@odoo.com>

This commit fixes an issue where if a ticket is free, the registration would
still "need to be paid" by the attendee.

This behavior is contradictory for a free ticket, so the attendee now has to
pay the ticket if it is not paid and is not a free ticket.

task-3012928

closes odoo/odoo#105542

X-original-commit: 2b0587fb
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>

It's needed to use "Automatic Risk assessment" feature in Adyen.

Technical docs:
https://docs.adyen.com/risk-management/configure-manual-risk/required-risk-field-reference



opw-3004646

closes odoo/odoo#102094

Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

Using the already existing indexing on the model to slightly improve the perfomance.

closes odoo/odoo#105318

X-original-commit: 4344d399
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>

*: website_mass_mailing (tests)

- Web Editor facts:
Since the refactoring of the editor done at [1], the cookies bar popup
is receiving a `contenteditable=true` attribute, making it receive the
chrome default `height` style for such elements.
The problem is that if this cookies bar's modal is hidden, the bar will
be shown as a thin empty white bar.

- Website Builder / Popup Snippet / Cookies bar facts:
A popup element is composed of a `.s_popup` parent containing the actual
`.modal` BS modal. Our internal logic and events are hiding and showing
this inner `.modal` modal element without considering its `.s_popup`
parent. It means that when the `.modal` is hidden, its `.s_popup` parent
is not touched and kept visible.
It might looks like it's not an issue as it would just be an empty
element (its only child is hidden) but it leads to some issues as
explained just above: an ugly white bar is shown.
Note that the cookies bar is nothing more than a `.s_popup` snippet.

- Web Editor facts 2:
During the mentioned refactoring [1], they actually added some code to
hide this bug once you were playing with the edit mode (mainly for when
you clicked on the invisible panel element or before saving).
But this code was actually not fixing the case when you just entered
edit mode.

This commit simply remove that "edit only" web editor logic and add a
new one in charge of simply synchronizing the `.s_popup` snippet
visibility with its `.modal` BS modal in a public widget (which is
obviously also executed in edit mode).

Finally:
- note that if there is no way through regular flow to arrive to the
  same result with a normal popup snippet, it is still concerned by this
  issue and you can reproduce it by moving it somewhere else in the DOM
  and/or simply adding it the `contenteditable=true` attribute.
- we already fixed that issue a few months/years ago, I couldn't find
  a commit related to that so I don't know if it was due to the same
  root cause
- in case one is wondering why we simply couldn't do that in the already
  existing `_onHideModal` of the `PopupWidget`, it is because that
  `hide.bs.modal` is not called when entering edit mode, because the
  `destroy` is destroying it before hiding the modal. The event is thus
  not fired. And we can't move the hide part before the destroy's super
  because otherwise, it would go through the normal hidden process which
  is creating a "seen" cookie for the popup as if it was closed
  manually.

[1]: https://github.com/odoo/odoo/commit/740168ce8d27da3d6a7156d2d79655a898394923



task-2754108

closes odoo/odoo#103382

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

Before this commit, if you abort an rpc, the ui is never unlocked.

How to solve it:
Simply trigger an RPC:RESPONSE event in the abort to signal that the RPC
is finished and that the screen can be unlocked.

closes odoo/odoo#105448

Signed-off-by: Samuel Degueldre <sad@odoo.com>

Currently, if the user uploads a facturx document whose move_type does not match the move_type chosen by the user, the document is not auto filled with the information contained in the facturx XML because of a restrictive check. Therefore, the document is empty and is sent to the OCR which acts as a backup.

Starting from this commit, we will remove this restrictive check. So, if the user uploads a facturx document, we will use the move_type define by facturx regardless of the move_type chosen by the user. This means that when we upload a facturx document, we will always use all the information that is in the xml to create the document and avoid using the OCR.

task-id 2961932

closes odoo/odoo#105447

X-original-commit: 81a68544
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Ricardo Gomes Rodrigues (rigr) <rigr@odoo.com>

Since this commit [1], the header language switcher has been moved out
of the header navbar. This created a bug, when the off-canvas option of
the navbar is activated, the language switcher is no longer accessible
on mobile.

As this commit is in stable version, the fix is only in Javascript. It
puts the language switcher back in the navbar when the off-canvas menu
is opened.

A specific case with the "hamburger full" header template, where there
is the same bug with the "call to action" button, is also fixed by this
commit.

This commit also fixes display issues in the off-canvas menu.

[1]: https://github.com/odoo/odoo/commit/2a000e33c5a44ddf0a777b43d8266cc413d8e4e2



opw-2964824

closes odoo/odoo#100235

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

Steps to reproduce:
- Create a product and complete a sales order.
- Then try to change the product type.
- The following message is shown:
"You cannot change the products type because it is already used in sales orders."
However, we can close the message and save.

Problem:
If some sales were already made, it should not be possible to change the product type.
There is a warning message on the onchange but it's not blocking.
This causes inconsistencies between the quantities and value shown in the quants and in the valuation layers.

Solution:
Raise an user error when trying to save the changes.

opw-3000886

closes odoo/odoo#105292

X-original-commit: 1b2c045f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Since the provider only accepts A4 letters, prevent the user from using
non A4 formats by giving them an error when clicking the Send button.

closes odoo/odoo#105206

X-original-commit: 3e257644
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>

This commit fixes premature usage of `purchase_price` field on
sale.order.line model, before its definition in sale_margin module.

Since this test requires both sale_mrp and sale_stock_margin to pass,
this commit adds an auto-install bridge module that solely address this
issue.

Steps to reproduce:
- Install sale_mrp module
- Run tests (at least .test_kit_cost_calculation)

Problem:
Traceback:
AttributeError: 'sale.order.line' object has no attribute 'purchase_price'

See #100126

closes #104891

closes odoo/odoo#105304

X-original-commit: https://github.com/odoo/odoo/commit/74b36c48f73710495e19c3ad258645f05e589a73


Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Co-authored-by: Thibault Libioulle <thibault.libioulle@aerospacelab.be>

The valuation field of the product_id is company-dependent.
If the user validate the picking in multi-company context with his current company != picking company, then the checks may fail, and the account move can not be created.

closes odoo/odoo#105272

X-original-commit: 33fa9cff
Signed-off-by: William Henrotin (whe) <whe@odoo.com>