The error were untranslatables

Courtesy of Moises Lopez

closes odoo/odoo#35573

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

- Set the rounding of Unit(s) to 1.0
- Create a PO for 1.4 Unit(s), validate => the picking contains
1.4 Unit(s)
- Validate the picking

The backorder wizard is displayed, and if no backorder is selected, a
crash occurs.

The quantity should be rounded when the picking is created. Otherwise,
inconsistencies will appears when it is rounded in subsequent processes.

opw-2046965

closes odoo/odoo#35560

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

_on_login_cooldown is documented as being disabled when
"base.login_cooldown_after" is set to 0, however the incorrect return
value meant setting this parameter to 0 would put every user on login
cooldown permanently.

Closes odoo/odoo#35544 reported by @rodrig92

closes odoo/odoo#35555

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

The following rounding is incorrect:
```
>>> float_round(6.6 * 0.175, precision_digits=2)
1.15
```

Indeed, 6.6 * 0.175 = 1.155 ≈ 1.16.

In this specific case, the `epsilon` computed is not sufficient. A
precision of 53 gives:
normalized_value = 115.49999999999997
epsilon = 1.2823075934420547e-14
=> new normalized_value = 115.49999999999999

Bad luck, this is just not enough to tip the value in the right
direction.

However, a precision of 52 is sufficient:
normalized_value = 115.49999999999997
epsilon = 2.5646151868841094e-14
=> new normalized_value = 115.5

The value of 53 was chosen from the `binary64` number format precision.
In case of Python, the corresponding machine epsilon is 2^-52 [1].
Therefore, using 52 instead of 53 does make sense.

It is worth noting that the value of the machine epsilon
2^-52 = 2.2204460492503131e-16, which is still 2 orders of magnitude
below our dynamic estimation.

[1] https://en.wikipedia.org/wiki/Machine_epsilon


[2] `numpy.finfo(float).eps = 2.2204460492503131e-16`

opw-2047368

closes odoo/odoo#35521

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

When using limit=1, PostgreSQL sometimes use sub-optimal plan like
"Index Scan Backward using xxx". To avoid this, adding a fake sort
will make PostgreSQL to use the same plan as without limit, and in
this particular case, the index on message_id

closes odoo/odoo#29278

Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>

The field "date_planned_finished" was not computed when changing the fields
"date_planned_start" or "duration_expected".

opw:2048416

closes odoo/odoo#35537

Signed-off-by: Simon Goffin (sig) <sig@openerp.com>

- Set a language using RTL (e.g. Arabic)
- Activate mobile mode (through debug mode or on a mobile device)
- Go to the CRM kanban view (make sure no record exist so the no_content
message is displayed)
- Add a new record
- Fill in the name, click outside of the field

The no_content message is displayed over the form view and it is impossible
to save the record.

The root cause is the incorrect structure of the kanban view page in RTL,
leading the user to the wrong element and triggering the wrong event.

We make the structure of the view aware of the RTL configuration.

opw-2046231

closes odoo/odoo#35509

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


Co-authored-by: Mohammed Shekha <msh@openerp.com>

- Set a language using RTL (e.g. Arabic)
- Activate mobile mode (through debug mode or on a mobile device)
- Go to a grouped kanban view (e.g. CRM pipeline)
- Swipe to the left

The column to the left if shown instead of the column to the right.

In RTL, the kanban groups order are inverted. Therefore, we also need to
invert the swipe direction.

Before this commit, when a user imports an Excel file, with date as
strings. The _try_match_date_time function will try to find the best
date parsing to use in the import without taking into account the
language of the user.

Now, the function will take into account the language of the user when
trying to find the best date parsing pattern for the import.

opw-2046217

closes odoo/odoo#35540

Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>

Sales > Configuration > Products
was present twice

Move to sale.prod_config_main and remove menu_product_settings in master

closes odoo/odoo#35159

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

Introduced at db4f62bd
This was causing issue with upgrade_boolean widget, cf odoo/odoo#20030

closes odoo/odoo#35469

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

Before this fix the save button in settings was not replaced when
pos_mercury is installed.
Caused by 2 views with the same id.

closes odoo/odoo#35517

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

Before this commit, when validating an e-invoice there are blocking
errors if VAT or Codice fiscale fields are empty for non Italians
buyers.

After this commit, if VAT or Codice Fiscale fields are empty for non
Italians buyers, the system will allow invoice validation.

opw-2045244

closes odoo/odoo#35515

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

Although this makes sense to warn the user, a `UserError` stops the
execution of onchanges but do not prevent saving incorrect settings. A
non-blocking warning would be another solution, but one issue remains:
a pop-up is raised when the user opens the settings, even if they are
unrelated (e.g.: open Website settings, an error message implying
Inventory appears).

This reverts commit c7beb999.

closes odoo/odoo#35511

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

Add validation using stdnum library since vatnumber is deprecated.

closes odoo/odoo#35433

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

Follow up on https://github.com/odoo/odoo/commit/63f052a40072e3a5487a8fe61c29f29d48807334#r34578119
Due to this https://github.com/odoo/odoo/blob/12.0/addons/pos_mercury/views/pos_config_setting_views.xml#L3

 was being replaced by this view (See manifest for info)

closes odoo/odoo#35471

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

In the customize theme modal, if one option enabled views which were
a subset of the views which are enabled by another option, both options
would be checked on modal opening if all the related views were active.

This is the case for the "choose an image" and the "choose a pattern"
options: the first one enables a view which adds an image on the body
and the second one enables the same view but also another which enables
the fact that the image must be repeated.

This commit solves the issue by always selecting the option enabling
the most views among the checked options in a same set.

opw-1958395

closes odoo/odoo#35465

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

Allow to see the lot/serial number on the order form, only for the users
with group group_production_lot.

opw-2037285

closes odoo/odoo#35443

Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>

- Set the user language to a RTL language, e.g. Arabic
- Open a list view containing float or monetary fields, e.g. the invoice
list view

The numbers are left aligned while the corresponding columns headers are
right aligned, making the list view confusing.

The header alignment is hardcoded at rendering rather than in the SCSS.
Therefore, `rtlcss` doesn't affect it.

Instead of hardcoding the alignment, we use a proper CSS class so it is
adapted by `rtlcss`.

opw-2044019

closes odoo/odoo#35414

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

Steps to reproduce the bug:
- Install stock_dropshipping module and enable Routes on SO lines
- Create a storable product P with a supplier S
- Create a SO with P and set this line with the route dropship
- Confirm the SO ( a PO has been created to S with P)
- Change P on the SO with an other product

Bug:

The product P stayed on the PO.
So a product linked to a PO line cannot be changed on a SO.

opw:2040249

closes odoo/odoo#35383

Signed-off-by: Simon Goffin (sig) <sig@openerp.com>

324268a9 has the side effect of
generating an extra query.

Field zipcode is optional, while it is labelled
as mandatory.

closes odoo/odoo#35401

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

Open the reconciliation widget, with a statement line that has
some move lines to reconcile with

Put your browser in Fast 3G to slow down stuff
then click multiple times on a move line to add it to
the reconciliation chain of the statement line

Before this commit, as many lines appeared in the reconciliation
chain as many clicks were made

After this commit, one can only click once on the lines

linked to #35194

OPW 2042751

closes odoo/odoo#35417

Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>

Attributes are documented for the gantt view but were not available in
the RNG
https://www.odoo.com/documentation/10.0/reference/views.html#gantt
https://github.com/odoo/enterprise/blob/fe0213e70de952/web_gantt/static/src/js/gantt_renderer.js#L32



closes odoo/odoo#31001

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

A user without stock acces rights was not able to read the fields
added by the stock module

The statbuttons display the number of items available which are
computed fields An accountant (no inventory or sale access rights),
opening the product view will trigger the recompute which will fail
(no access on stock.warehouse.orderpoint)

closes odoo/odoo#32499

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

You can check

https://www.plangeneralcontable.com/?tit=526-dividendo-activo-a-pagar&name=GeTia&contentId=pgc_526



for further information on the account.

This is needed for proper bank statement reconciliation and for AEAT model 123.

closes odoo/odoo#35357

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

Mass mailing themes are redefining some bg-* classes their own way...
unfortunately that way was not working anymore with BS3. This commit
adapts the CSS code to solve the problem but ideally, themes should be
refactored to be more BS4 compliant.

opw-2032131

closes odoo/odoo#35333

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

Before this patch Amount currency was always +ve and doesn't care about about Debit/Credit values.
See _check_currency_amount constrains.
Fixes: #35403

closes odoo/odoo#35422

Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>