closes odoo/odoo#105279

Signed-off-by: Raphael Collet <rco@odoo.com>

Prevent the PowerBox command bar to open in (non html) Odoo field
embedded inside the editable zone.

task-3040872

closes odoo/odoo#104414

Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

Version: V15.0

Since version 15.0, the shortcuts allowing to switch between views (kanban and list) via the `ALT + K` and `ALT + L` are not supported.
It is necessary to update the view which summarizes shortcuts.

opw-3052364

closes odoo/odoo#105293

Signed-off-by: Bruno Boi (boi) <boi@odoo.com>

Steps to reproduce:
 - Install website_sale_coupon
 - Load demo data
 - Create a promotion program that applies on the order
 - Go to the webshop and add 2 different products to the cart

Bug:
The line of promotion is in second place, instead of at the end.

Fix:
move the old sale order line to the end if it applies on all the order

opw-2985632

closes odoo/odoo#105253

X-original-commit: dadd272d
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>

EXPLAIN ANALYZE SELECT "stock_move".id
FROM "stock_move"
WHERE ("stock_move"."created_purchase_line_id" in (24065, 24066, 24081, 24082, 24083, 24084, 24085, 24086, 24087, 24088, 24089, 24090, 24091, 24092, 24093, 26121, 26487)) and ("stock_move"."company_id" in (1))
ORDER BY "stock_move"."sequence" ,"stock_move"."id" ;
Goes from 2231.021 ms to 1ms on a database with 2.800.000 stock_move.

closes odoo/odoo#105153

X-original-commit: d7ea47f4
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

Steps to reproduce:

  - In odoo, create an event "example" in the future with alice@outlook.com and add
    bob@outlook.com to the attendees
  - In the bob outlook account, there should be an ics file with the
    following email "Invitation to example"
  - Drag and drop the ics file into outlook calendar
  -> Bob is set as the organizer

Cause of the issue:

  The organizer property is missing from the ics file
  cf https://www.rfc-editor.org/rfc/rfc5545#section-3.6.1



opw-2841276

closes odoo/odoo#105052

X-original-commit: f3d2e517
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>

Before this commit, performing a search in a m2o can block your ui
despite the result already being displayed.

Why?
When you perform your search in a m2o, a set of RPC queries are made
with the different search values (name_search). If the last search value
(the one that will be used by the m2o in its autocomplete) has already
been resolved, but one of the other RPCs has still not been resolved,
then the screen will remain blocked until all the rpc's have been resolved.

Solution:
Since we are only interested in the last rpc, we will cancel all the
others. So with each new rpc, we will cancel the previous one.

How to reproduce:
- Go to a form view with a m2o field
- Edit this field +- slowly (several rpc will be done with different values)
- Receive the result of the search. (The autocomplete is displayed with
     the right values)

Before this commit:
If one of the other rpc's is not yet resolved, the ui will block
until all rpc's are resolved.

After this commit:
The ui will not block.

closes odoo/odoo#104984

X-original-commit: f07ee076
Signed-off-by: Samuel Degueldre <sad@odoo.com>

To Reproduce
============

- enable QR code on Accounting settings
- with a customer who has a bank account create a credit note for him/her
- in other info tab, make sure that the qr code method is empty
- send or print the credit note

The Problem
===========

the qr code method field will be filled with SEPA, and a QR code will be added to the PDF

Solution
========

Generating a QR code for a credit note doesn't make any sense, so the qr code method field must be hidden
and no QR code should be generated.

opw-3010649

closes odoo/odoo#105239

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

Before this commit, if two or more lines in sale_report had the same value as price_total, they were group together in _compute_kpi_sale_total_value and included in output sum only once. That leads to incorrect values in digest mail.

This commit fixes that issue by changing grouping column from price_total to company_id.

Steps to reproduce the issue:
----------------------------

1. Send Digest Mail for database and check values in it (assume we have both All Sales KPI and PoS KPI).
2. Create several sale_order_line and/or pos_order_line with exactly the same price_total (for example: 5 PoS transaction, each one for one product of value 10000).
2. Send Digest Mail again and check values in it.

Current behavior:
-----------------

The All Sales KPI will increase by value of only one of lines (in our example: PoS KPI will increase by 50000 = 5*10000, All Sales KPI will increase by 10000)

Expected behavior:
-----------------

All Sales KPI should include all transactions from sale_report in given period of time (all sale_order_line and pos_order_line).

opw-2938952

closes odoo/odoo#102677

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

closes odoo/odoo#105161

Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

Issue :
- When sending an sms reminder by cron user, `_get_display_time` is
used which always uses Odoobot (cron user) timezone regardless of the
partner timezone

Fix:
- use `partner_id.tz` instead of Odoobot

OPW-2991624

closes odoo/odoo#105135

X-original-commit: 7e3954bd
Signed-off-by: Mohamed Megahed Abbas Megahed SALLAM (mome) <mome@odoo.com>

Steps to reproduce:
1-set language to an LTR language (arabic / hebrew...)
2-select any field with the date-time range widget (eg: planning>add)
3-the hour and the minute selection is reversed.

Bug:
the hours and minutes order depends on the language orientation where
they should always follow this format HH:MM

Fix:
force the time to be displayed Left To Right regardless of language

opw-2953221

closes odoo/odoo#105134

X-original-commit: 4f94cf2b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>

The wizard would update the amount and payment_difference in multiple
cases as the fields get updated by the user.
In multicurrency, the base amount would be converted to the selected
currency at the date of the payment selected by the user.
If the date is emptied before changing the currency, this would lead
to a traceback when calculating this amount.

In order to fix that, we can fall back on today as date to convert
the amount, which will avoid a traceback and won't impact the result
since the amounts will be updated again when the required date field
is filled.

Fixes https://github.com/odoo/odoo/issues/92114



closes odoo/odoo#105122

X-original-commit: 9ddb9155
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>

closes odoo/odoo#105106

Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

Taxes on self-invoices for non-EU export actually have amount > 0,
l10n_it_has-exoneration = False but they must have the law reference
field filled out, so we're taking the "invisible" clause
out of the view.

Task: https://www.odoo.com/web#id=3010849&model=project.task


opw-3010849

closes odoo/odoo#105036

X-original-commit: 825bb40c
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>

Since we changed add product signature to be asynchronous, we had to change all the functions and the calls to this function to be awaited or set as async.

closes odoo/odoo#104467

Related: odoo/enterprise#33382
Signed-off-by: Masereel Pierre <pim@odoo.com>

This commit allows another module to force a new order when a refund order is done.
This is mandatory in certification context. A pos order cannot sell refunded products and new products.

To use this feature, the module have to use this function:
doNotAllowRefundAndSales()

Part-of: odoo/odoo#104467

Steps to reproduce the bug:
- Create a storable product “P1”:
    - change the cost to $20
    - product category > costing method > standard price
- Create a SO:
    - Add the product “P1”
    - Change the cost from $20 to $10
    - Save
    - Sent the quotation by Email

Problem:
The `purchase_price` is recomputed and changes back to the original value.

When the quotation is sent, the state of the order lines change,
marking the field `qty_delivered_method` to be recomputed, but also
other computed fields depending on it, including the purchase_price
(because of the dependency added in sale_timesheet_margin).

To avoid this unexpected recomputation, we remove the useless
dependency on the `state` for the field `qty_delivered_method`.
There is no reference/check on the state in the method
_compute_qty_delivered_method or any of its overrides and
therefore the field should not be necessary in the compute
dependencies.

opw-2994136

closes odoo/odoo#103739

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

Before this commit, when point of sale order line (in table pos_order_line, Point of Sale app) and empty sale order (in table sale_order, Sales app) shares the same id number, it may create duplicate id in sale_report sql view. Empty sale order is an order with no products, so not connected to sale order line.
Additionally, these duplicates creates some discrepancies between pivot and list view in sale report in Sales app.

This commit fixes the issue by removing sale orders with no order lines.

Steps to reproduce the issue:
-----------------------------
1. Create order in Point of Sale app with minimum pos_order_line id equal to "n"
2. Create empty sale order (no order lines inside) with id equal to "n"

To reproduce issue on runbot, one may check the minimum order line for one of pos orders (assume this is n) and then delete all order lines from sale order with id equal to n.

Current behavior:
----------------------------
There will be two lines in sale_repot sql view with id equal to "-n"

Expected behavior:
----------------------------
Id in sale_report view should be unique

opw-2946444

closes odoo/odoo#100222

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

Those tags should only be created by the tax reports; creating them manually makes no sense.

closes odoo/odoo#105037

X-original-commit: 1a3b8344
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>

The scheduled end date of a work order is not consistent with its
scheduled start date when starting the work order

Steps to reproduce:
1. Install Manufacturing
2. Go to Settings > Manufacturing > Operations and enable Work Orders
3. Create a manufacturing order for any product, with any component and
   a work order
4. Confirm and plan the MO
5. Edit the scheduled start date of the work order to the next working
   day and save
6. Start the work order
7. The scheduled start date changes but the scheduled end date doesn't

Solution:
When starting a work order, change the `date_planned_finished` according
to the new `date_planned_start`

opw-3005767

closes odoo/odoo#104890

X-original-commit: 0edeed2f
Related: odoo/enterprise#33577
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>

When deleting a selection in a table, we need to restore the cells the
browser removed or the table will be broken. We however failed to
restore the rows they belonged to when said rows were entirely contained
in the selection.

task-2930516

closes odoo/odoo#104831

Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

o_mail_notification should only be hidden when seen from the chatter.

At the moment, the notification is hidden everywhere in odoo and
after this PR the notification are only hidden in the chatter

opw-2720840

closes odoo/odoo#104811

Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

To reproduce the issue:
1. In Settings, enable UoM
2. Edit the UoM 'Dozens':
    - Rounding: 1.0
3. Create two products P_finished, P_compo:
    - P_finished:
        - UoM: Dozens
4. Create a BoM:
    - Product: P_finished
    - Qty: 1 x Dozens
    - Compo: 1 x P_compo
5. Create and confirm a MO for 1 x P_finished
6. Edit the MO:
    - Set the producing qty to 1
    - Set the 'to consume' quantity of P_compo to 1.23

Error: the consumed quantity of P_compo is still 1.0 (it should be
1.23). If the user tries to set the quantity to 1.56, the consumed
quantity will become 2 (also incorrect, should be 1.56)

The UoM used to round the new consumed quantity of the component is
incorrect. Considering its definition:
https://github.com/odoo/odoo/blob/0fdd35cfb5c7145b3a7a855956004e38de7c6e2a/addons/mrp/models/stock_move.py#L164-L170


the UoM of `unit_factor` is `UoM_sm / UoM_mo`. Therefore, in
`_update_quantity_done` (see diff), when we compute `new_qty`, we have
(in terms of UoM) `(UoM_mo - UoM_mo) * UoM_sm / UoM_mo`. So, the value
is already in the correct UoM (`UoM_sm`) and we just have to round it
based on that UoM

OPW-3016837

closes odoo/odoo#104993

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

Paste a url in the editor from the URL bar of the browser. If you then
select it all and paste another URL in its stead, the zws inserted by
the sanitizer when deleting the selection ends up in the URL.
This is because the sanitizer moves downward into the DOM tree,
therefore change the link URL before removing the zws in its text child
node. To make sure this can't ever happen, we now remove zws from URLs
when parsing them from the link's text content.

task-3054233

closes odoo/odoo#104853

Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

Steps to reproduce the bug:
- Create two storable products:
    - kit_1 and Comp_1
- Create a bill of materials:
    - Product: kit_1
    - Type: Kit
    - Components: 1 unit of Comp_1
- Create a SO with:
    - kit: 1 unit
    - Confirm the SO
- A picking with 2 units of “comp_1” will be created

- Edit SO:
    - Reduce the qty of kit_1 to 0

Problem:
“Comp_1” qty not updated to 0 on the picking.

When the SOL qty is updated, the pickings should be updated too.
So we get the qty in delivery:
https://github.com/odoo/odoo/blob/e11dfa341baf82fedee753502aef5ef2972f75cb/addons/sale_stock/models/sale_order.py#L553

then the difference between that qty and the new SOL qty is computed.
And procurement based on that difference is created:
https://github.com/odoo/odoo/blob/e11dfa341baf82fedee753502aef5ef2972f75cb/addons/sale_stock/models/sale_order.py#L573-L578

but the `_get_qty_procurement` function returns 0 as result, because
the `_compute_kit_quantities` function is called with the qty set on
the SO (“0”), so the result will be 0 because we need 0 qty to have 0
kit:
https://github.com/odoo/odoo/blob/4ee5df76607c80c94a4aea832dcd2f73ad8e5ee1/addons/sale_mrp/models/sale_order_line.py#L121-L122



opw-3018258

closes odoo/odoo#104631

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Before this patch, when doing an SMTP connectivity check, Odoo always checked if the current user with their current email address could connect.

That was inaccurate because:
1. If the `ir.mail_server` were configured with an email address as `from_filter`, that's going to be the address used to connect with the server always; never your user email.
2. If it were configured with a domain as `from_filter` and your user had an email from another domain, your outgoing emails are going to get wrapped into that domain (SRS-like). Again, the connectivity check wouldn't be imitating real world connections.

After the patch, both situations are taken into account when deciding the outgoing address that's going to be used for testing the connection. This will reduce false negatives when testing connectivity.

@moduon MT-1064 OPW-2942814

closes odoo/odoo#104417

Signed-off-by: Stéphane Debauche (std) <std@odoo.com>

When the seller is foreign, the Fiscal Regime of the seller must
be set to 'RF18', as per:
https://www.fattura24.com/manuale/altri-documenti/autofattura-fornitori/

Task: https://www.odoo.com/web#id=3010849&model=project.task


opw-3010849

closes odoo/odoo#104832

X-original-commit: a066a8b1
Signed-off-by: Josse Colpaert <jco@odoo.com>

Steps to reproduce:
- on Ecommerce website Add an item to your cart.
- Billing/Shipping info > Stop on Payment page.
- Duplicate tab, On the duplicate, add more products to your cart.
- Go back to the original tab (Payment page) > Check out with Stripe.
- Stripe acquirer page does not reflect the updated cart amount.
- Complete payment > Website will say order is confirmed.
- Go to this SO in backend

Bug:
SO is not confirmed and Stripe status says there is a mismatch
because it did not take updated amount.

Fix:
double check the ammount before processing payment

opw-2978244

closes odoo/odoo#101601

Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

The main motivation for this change is to improve performance of BoM
`explode`, which heavily rely on checking the lines to skip. `explode`
is also called from product `compute_quantities_dict` which is called
multiple times during upgrades. With this fix we improved the running
time of an upgrade _test_ from 3h:30m to 2h:55m which gives a 16%
performance improvement.

The goal of `_skip_bom_line` is to check that for each attribute present
on the line, at least one value associated to that attribute must be in
the attribute values of the product(*). If none is found then we
consider that we can skip the line.

The previous implementation was inefficient. It grouped all values by
attribute, then checked one by one if at least one value is on the
product. In case one attribute does not have any value on the product it
skipped the line.

The implementation we propose here is to take the intersection of the
product and line values, then check that their attributes are the same.
The later can be done with a simple length check. In case they are
different the line must be skipped. Note that this works because only
one value is possible per attribute in a product.

Both implementations are equivalent. The second is more efficient
because does not branch and relies on (record)set operations.

For example, let's consider a product with two attribute values
`a` and `b`, and a line with multiple values `a`,`y` for
attribute 1, and `z` for attribute 2.
```
Product                      Line
+---+                      +-----+
| a | <- same attribute -> | a,y |
+---+                      +-----+
| b | <- same attribute -> |  z  |
+---+                      + ----+
```
This line must be skipped. The reason is that the value `b` is not
among the list `[z]` of values for attribute 2 on the line. The new
implementation would get the intersection of attribute values as `[a]`
from there the comparison of the attributes will fail because `[a]` has
only one attribute while the line has two.

Let's consider a second case, where there is no value on the line for
attribute 2.
```
Product                      Line
+---+                      +-----+
| a | <- same attribute -> | a,y |
+---+                      +-----+
| b | <- same attribute -> |     |
+---+                      + ----+
```
This line is not skipped because there is no value for attribute 2 on
the line. Therefore the condition(*) per attribute is not violated for
this product. The new implementation gets `[a]` as intersection of values,
but now the attributes coincide: they are both attribute 1 for the
intersection and the line.

Finally,
```
Product                      Line
+---+                      +-----+
| a | <- same attribute -> | a,y |
+---+                      +-----+
|   | <- same attribute -> | z,w |
+---+                      + ----+
```
This line is skipped because none of `[z,w]` are in the product. The new
implementation would get again `[a]` as intersection which does not
match the attributes on the line.

closes odoo/odoo#104813

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

Commit [1] broke some confirm dialogs because the confirm and cancel
callbacks are not called with the same `this` anymore.

E.g.:
- Install website
- Go to the page manager (/website/pages)
- Clone a page (choose a name and confirm)
=> Crash (this.$ does not exist).

Note that this flow was quickly fixed with [2] by changing the local
code instead of fixing the root cause (this commit here actually
technically reverts that change so it keeps working).

The work done at [1] actually needed some more rework than that to
handle two other potential usecases:

- If the confirm dialog handlers' promises are rejected, the dialog is
  not closed (rightfully, like for example allowing to fill an empty
  required input)... but [1] prevented to click on the button again
  forever. With the same example as above, it can be reproduced: if the
  RPC to clone the page fails, I cannot retry.

- If not both confirm_callback and cancel_callback were given, [1] only
  prevented to multi-click on the related button (e.g. if you click on
  "Ok", a RPC which takes 10 seconds is made, you click on cancel
  immediately afterwards -> the dialog is closed while it should be
  prevented (and would be if cancel_callback was given, following [1])).
  That may not be entirely stable to make this change though but it
  seems to make sense and be better (just keeping what [1] wanted here).

Note: this adds some more tests to check all of this + some more things
that were found during development. For example: [1] relied on the fact
that callbacks returned a Promise or nothing... while developers
actually were returning random things (for no reason as no way to get
the result anyway). Adding a test for this prevents to break that in
stable (the first iteration here crashed in such cases).

[1]: https://github.com/odoo/odoo/commit/4b8b079a7d9991a8dc481fe71a45185d672135c9
[2]: https://github.com/odoo/odoo/commit/8216341f5ad8d82ad0bcb0d1f01d874477d2de7b

Closes https://github.com/odoo/odoo/pull/103712


opw-3033878
opw-3043224
opw-3046485
opw-3042542

closes odoo/odoo#104867

X-original-commit: 7d7960df
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Currently entering custom urls will be missing characters if they contain unicode.

Steps to reproduce:
1. Open Promote dialog
2. Enter a custom url that contains unicode (e.g. `Nội dung có Dấu`)
3. Output: `n-i-dung-c-d-u`

Expected output after this commit: `noi-dung-co-dau`

closes odoo/odoo#104854

X-original-commit: bb43d4db
Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Change isolation link unit tests to cover both deleteBackward methods :
- deleteBackward via direct contenteditable command
- deletebackward via input event ( mobile )

task-3054245

closes odoo/odoo#104837

Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

This reverts commit 331b9435.

task-3054245

Part-of: odoo/odoo#104837

Previously, when gracefully stopping the server, incoming requests got
queued in the socket's backlog until the workers all finished their
requests, then the socket closes and backlogged requests get their
error response.

This would leave the system administrator with the awkward choice
between giving existing requests time to finish and not creating too
big a downtime for new incoming requests before forcefully shutting the
server down.

As the workers will stop accepting new connections on the graceful stop
call, we can close the socket so the binded address is freed as well.

This allows a cleaner graceful restart of the service as we can
gracefully quit the Odoo server, start a new server on the same address
and let the old service finish its requests for as long as we want.

closes odoo/odoo#98202

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

When printing a check that comes from an expense,
the check has no reference to the move from which
the payment has been created.

The reason is that we filter the move by taking
only outbounds to complete the check informations,
but moves from an expense are of type entry.

With this commit, we allow moves coming from
expense to be taken into account by adding a
check on line_ids.expense_id.

opw-3044141

closes odoo/odoo#104824

X-original-commit: d005fd85
Signed-off-by: John Laterre (jol) <jol@odoo.com>

Keep the original context after duplication
This is a partial fix for this issue raised at opw-2868550

To reproduce:
- activate 2 languages (e.g. es_ES and en_US)
- set es_ES as default language
- edit an existing page (e.g. contactus) in the default language
- change a small detail (e.g. field label in form)
- save

When writing for the first time on a website page from the editor,
with the website creates a new page using copy
The copy removed the language on the record when creating the new
record but did not reset it.

>>> self.env.context
{'lang': 'es_ES'}
>>> copy = self.copy()
>>> copy.env.context
{'lang': None}

Not having the right language is an issue as the code following the
copy call bypass the translation system with a lang=None

This patch is only the server part.
The language still needs to be propagated in the context from the
editor.

closes odoo/odoo#100308

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

The tests in the purchase_stock module include some tests that make sure or
depend on the fact that the price_unit from the generated move lines equals the
price_unit from the purchase order line from which they were created.

However, the price_unit in the move lines exclude taxes (at least those that
have an account set, it uses the total_void computed from the purchase order
line). This means some tests will fail if an installed localization defines
taxes that are included in the price.

The problem is resolved by explicitly creating the test product used in those
tests without supplier taxes.

opw-3033340

closes odoo/odoo#104801

X-original-commit: 70f7e2d7
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: De Caluwé Tom (tdc) <tdc@odoo.com>

Even if a many2many field is forcely set to be sortable, it should
not be included in the list of custom groupby options if it's
an un-stored field.

closes odoo/odoo#104674

Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>