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

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

closes odoo/odoo#102814

Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>

In https://github.com/odoo/odoo/commit/4fb0933986534e31337aa1dce3478a67deea72de

, we faced an owl error when changing the tour:
"Component is destroyed"

This is due to the tour leaving the kanban view right after clicking on the "Validate" button.
After the validation, the kanban view is reloaded that is triggering a call to "web_search_read".
For some reason, the 'web_search_read' was triggered right after the component is destroyed.
To fix that issue, some additional steps have been added to the tour but this was just making the tour failing in a not determinist way.
Since the root cause of the issue has been fixed since, such additional steps are no longer needed.

closes odoo/odoo#102662

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

The rpc service has a protection (when used via useService) that
prevents the returned promise from being resolved/rejected if the
component has been destroyed meanwhile.

However, as the FormView still uses the legacy BasicModel, all rpcs
done by its model do not go through our new rpc service. As a
consequence, before this commit, they did not benefit from the
protection. This caused a non deterministic issue in the main flow
tour.

This commit implements a similar protection as the rpc service, but
specialized for the BasicRelationalModel, which redirects all RPCs
done by the BasicModel.

This change highlighted two scenarios where we sometimes performed
RPCs (or could perform RPCs) on a destroyed component. This commit
fixes those as well.

Part-of: odoo/odoo#102662

closes odoo/odoo#105263

Signed-off-by: Martin Trigaux (mat) <mat@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#105228

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

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

closes odoo/odoo#105216

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

Before this commit, when compiling a form group, the scope class is
added to the elements of the outer group. It was added on the element
class attribute. The issue is that FormLabel don't have a class
attribute but a className attribute. So the class wasn't shown on the
DOM.

Now, the class is added on the FormLabel className attribute and shown
in the DOM.

closes odoo/odoo#105184

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>

Before this commit, the labels tags that were after the fields losses
their attributes (i.e. classes) after the compilation of the form view
arch.

Now, the attributes are correctly copied after the compilation.

similar to : 873790f8

Part-of: odoo/odoo#105184
Co-authored-by: Patrick Hoste <pko@odoo.com>

**Issue**

Login as an ordinary user (demo) and open Apps to make a request
access to a module. A wizard will appear asking for the admin users
to request to and the reason for request. Input elements are not
properly shown.

This is because inside an inner group, as we remove the label (cf.
nolabel=1), the input field is put in the first column which is supposed
to be the location of the (non-existing) label.

**Solution**

Make the field take both columns (label + field) as it has no label.

closes odoo/odoo#105130

Signed-off-by: Pierre Paridans (app) <app@odoo.com>

closes odoo/odoo#105089

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

Steps to reproduce:
- select a language where thousands separator is not (e.g. portugese)
- try editing any number input field

Bug:
 error when parsing the new value when thousands separator is not defined

Fix:
 fixed default value (only fallback to commas if it's not the decimal
Point separator)

opw-3041135

closes odoo/odoo#104644

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

In the quick create form views in CRM, the 'recurring_plan' field is missing
(or rather invisible). It is a required field so it prevents the use
of the quick create.
The purpose of this commit is to let it be visible again to users.

Task-3007756

closes odoo/odoo#102277

Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>

As `_get_view` is cached,
and `_get_view` has been overrided to change the label of the fields
`company_rate` and `inverse_company_rate` according to the company
currency, the company currency must be added in the `_get_view` cache
key, so it returns the view with the correct labels
when you use two companies with distinct currencies,
and not the label using the currency of the other company.

closes odoo/odoo#105250

Signed-off-by: Denis Ledoux (dle) <dle@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#105244

X-original-commit: 804c485f6afe98c5d63cfe91ce65e0a8352fc92e
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

The confirmation dialog to delete a token from a portal user is the
same whatever the linked records. This part of the code is now moved to
a separate function `_buildConfirmationDialog` in order to allow
overrides of the method in particular cases (e.g. Subscriptions).

task-3048269

closes odoo/odoo#105103

X-original-commit: 6c59d356f16c2bf1f64b7d0346d78724952ca706
Related: odoo/enterprise#33682
Signed-off-by: Vallaeys Valentin (vava) <vava@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#104411

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

closes odoo/odoo#105229

X-original-commit: 3cfec9a0
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

Before this fix, the constraint did not prevent changing the company to a bad one on an existing field.
We also remove the GROUP BY clause as it is useless.
Another query was also useless in `analytic_account.py` and has been removed.

closes odoo/odoo#105129

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

This query itself is useless and its result is never watched.

Part-of: odoo/odoo#105129

Before this fix, the constraint did not prevent changing the company to a bad one on an existing field.
We also remove the GROUP BY clause as it is useless.

Part-of: odoo/odoo#105129

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

X-original-commit: 83edc563
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@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#105232

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

The code removed by this revision was added at a time any user
could access the `res.config.settings` model, including non-admins.
odoo/odoo@a468aee5184a62e0dbf0d680036a014079827c2a
So, it made sense at the time to make the module installation checkboxes
readonly for non-admin users accessing the settings.

However, since revision
https://github.com/odoo/odoo/commit/65530dfd6a0486f44134917f5cc42a2c30b95762#diff-e275aaa5de11da2815c2f0cc18bc046f967df5e4eba94999ee55ffe8926c87bdR109


the `res.config.settings` model is restricted to admins only,
who have the write access the `ir.module.module` model.

This override is therefore pointless,
as since then it's impossible for non-admins to access
the settings.

closes odoo/odoo#104593

Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>

Since odoo/odoo#99660
the `depends` field attribute is no longer passed
from the server to the web client.

Because of this, the "Set Defaults" feature
of the debug menu is completely unusable,
as the list of fields on which to set a default is empty because of it.

The use of this `depends` field attribute has been introduced in
revision odoo/odoo@ce9bbf6c10962e64138c04ca34b7485084e4cdaa
In the commit description, we can read that setting a default
on computed fields having depends has been disabled
because the defaults set were being overwritten by the call to onchange.
Note that only the fact the field has depends is required,
the actual list of field names is not used, just the fact the list is
not empty.

However, since revision
odoo/odoo@488e334fc8fd6601e304635fa577c98b9bfd18e6,
available since Odoo 14.0,
this is no longer the case, the defaults are no longer being overwritten
by the call to `onchange`, since the `default_get` has been integrated
into the `onchange`.

A video attached to the pull request of this revision
shows the behavior difference.

Hence, setting a default on a computed fields having depends
(with an inverse method, hence not readonly)
can be allowed again in this "Set defaults" debug feature,
therefore avoiding to have to send back the `depends` field attributes
to the web client.

opw-3031290
opw-3038711
opw-3055292

closes odoo/odoo#105009

Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>

This commit fixes missing hover style on the buttons in the composer.

Task-3050035

closes odoo/odoo#105198

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

The accounts shown in the widget could be shown while being in the wrong company.
Previously, only the plans were limited by the company.

closes odoo/odoo#105188

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

For a trigram indexed translated field field_x,
domain leaf ('field_x', '=', value) and ('field_x', 'ilike', pattern)
will miss records if the pattern contains accent characters

This commit set ensure_ascii=False for json.dumps to avoid escaping special
characters

opw-3048182

closes odoo/odoo#104928

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

Task-3058786

closes odoo/odoo#105173

Signed-off-by: Louis Wicket (wil) <wil@odoo.com>

closes odoo/odoo#105162

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

Tests for `deleteBackward` with a non-collapsed selection should always
be repeated using `deleteForward` to ensure the behavior is indeed the
same for both. This was not the case for some of the tests.

task-3032817

closes odoo/odoo#104285

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

Tables have their own custom selection in Odoo Editor, so rectangular
cell selection is supported. Selecting a whole row/column/table then
pressing delete/backspace removes the whole row/column/table. But just
selecting some cells should only empty them, which we failed to do,
resulting sometimes in broken tables.

The code to remove selected rows/columns/table was triggered when
pressing backspace/delete, which failed to account for cases where we
need to delete the range without pressing those keys (for instance when
typing a character). This moves that code to `deleteRange` so as to make
it the standard behavior when deleting a range that includes table
cells.

task-3032817

Part-of: odoo/odoo#104285

deleteBackward and deleteForward tests were just directly calling the
editor's implementation, without triggering events that are sometimes
crucial to the behavior. This is at least preventable in cases where the
selection isn't collapsed, by triggering the keydown event and calling
the document's `execCommand` function with the "delete" command.

task-3032817

Part-of: odoo/odoo#104285

Prior to this commit, when we clicked on an article, it would flicker on
mobile.

This commit fixes this issue.

task-3058162

closes odoo/odoo#105115

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

task-3048314

closes odoo/odoo#105070

X-original-commit: 99ad94f3df65c5657d9d7859ba79ff349d79f01c
Related: odoo/enterprise#33666
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>

We have internal utils that will use a wanted format in a localized way.
We should use those utils rather than hardcoding a format, otherwise
that format will be used for all languages which is weird.

So, passing a `short` / `medium` etc format directly to babel will avoid
that issue. On top of that, the `value_to_html` of our
`ir.qweb.field.datetime` also provided options like `date_only`,
`hide_seconds` etc.

This commit simply gets rid of those hardcoded format and achieve the
same thing using utils & tools, which will be localized on top of that.

The "error" was report by our translator: `MMM d, yyyy` in french leads
to `oct. 18, 2022` which is not ideal. It should be `18 oct. 2022`.

closes odoo/odoo#104977

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

Partly due to our recent last minute merge in 16.0 just before the OXP
where the 16.0 was actually not really stable yet (there were officially
a few weeks where non stable change could still be shipped), we forgot
to add the .pot file with those IMP (as we usually don't add the .pot
file with an IMP as it should be in master where the .pot is not needed
as it will be synchronized/updated when the master will become the next
stable branch).

This commit simply sync the .pot files related to our apps so we start
clean in 16.0 which is still very early.

closes odoo/odoo#104917

Signed-off-by: Romain Derie (rde) <rde@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#104908

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

Part of [1] was lost during the frontend>backend merge [2].
The SEO name field was not "slugified" anymore in JS, it led to 2
issues:
- Bad UX, one could type something and it would end up after save with
  something completely different
- 404/crash: as the generated URL in js (based on the seo name value)
  would not be slugified, it would redirect to that URL, which would not
  be found as the record URL in python would be slugified. There would
  be an URL mismatch between the python route and the JS redirect value.
  This could still somehow happen as the JS and PY slug are not doing
  the exact same things but at least this will restore what we had
  before and mitigate the issue.

Step to reproduce:
- Go to a blog post and open the SEO dialog
- In the custom URL input, type "créé"
- You will be redirected to `/@/blog/travel-1/créé-1`
This will be a 404 page, as the correct URL is now
`/@/blog/travel-1/cree-1`.

[1]: https://github.com/odoo/odoo/commit/c387ec19b4648ae52bf3210253febd7825745627
[2]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b

Part-of: odoo/odoo#104908

Before this commit, the highest number warning was displayed on multiple lines.

This commit fixes this by inlining the name of the invoice with the highest number.

closes odoo/odoo#104744

Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>