Before this rev., the datepicker was opened when a date(time) field
was focused (e.g. with keyboard navigation). We don't want this
behavior anymore, and we want the datepicker to open only when the
user clicks in the input. This rev. makes this change.

Moreover, this allowed to refined the keyboard navigation (ESC) in
editable list views: when a datepicker is opened, and the user
presses ESC, we close the datepicker, but we keep the row in
edition, whereas before this rev., the row was switched to readonly.

closes odoo/odoo#32408

Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>

Assume an editable list view with a date(time) widget, click to
edit a line, focus the date field (the datepicker opens), press
ESC: there is a crash in the lib, and the datepicker remains open
forever.

This fix is twofold:
 - we added a check in the lib to prevent it from crashing (it is
 easily reproducible: it crashes when an opened datepicker is
 removed from the DOM).
 - we added an event handler of ESC keydown event to hide the
 datepicker before the field is removed from the DOM.

Subpixels computation is different accross browsers and platforms as no
rounding rule is specified by HTML5. Difference in this computation
breaks one of the editable list tests on Chrome and Firefox on MacOS.

In an editable list view with at least a facet (e.g. filter) in
the search view, start editing a row, then click on the 'x' to
remove the facet. The view being updated and re-rendered, the row
in edition (if still present) is back in readonly. However, the
buttons in the control panel are not updated ('Save' and 'Discard'
are still displayed, instead of 'Create' and 'Import').

Normally, when the user clicks outside the list, the edition is
left smoothly. However, this scenario is a corner-case because the
element we clicked on (the 'x' in the facet), is no longer in the
DOM when we enter the list '_onWindowClicked' handler, being in
charge of deciding whether or not we should leave the edition. For
this specific case, this handler doesn't leave the edition, because
it assumes that we have clicked on an sub-element of the list that
is no longer in the DOM (e.g. a modal opened from a field widget).
Since it's no longer in the DOM, there is no way to determine
whether it was in the list or not.

This whole '_onWindowClicked' logic is problematic, but we don't
have any better solution for now. So this rev. fixes the issue by
always resetting the buttons to 'readonly' when the view is
updated, which is valid in the case of the list view.

Unfortunately, we couldn't reproduce the bug in a test, because of
a difference between user clicks (with the mouse) in the browser,
and programmatical clicks (triggered in JS) as we do in the tests.
For natural clicks, there is a delay between the (different level
of) handlers call (probably a nextTick) whereas all handlers are
executed in the same tick for programmatically triggered clicks.
For instance, when the user clicks on the 'x' to remove the facet,
the 'click' handler on '.o_facet_remove' is executed, and the
searchbar is re-rendered (new Widget, so next micro-task tick, but
still before the next tick), and in the next tick, the 'click'
handler on 'html' is executed (and the event is triggered on
core.bus, followed by the execution on '_onWindowClicked'). In the
test, both handlers are executed directly, and thus when in
executing '_onWinowClicked', the searchbar hasn't been replaced by
the new one yet, and the clicked '.o_facet_remove' is still in the
DOM. The row is then unselected, and the buttons are correctly
updated.

Before this rev., when adding then discarding a new record in a
(main) editable="top" list, the record was added to the top of
the list, and then replaced by an empty row when discarding,
whereas that empty row should have been rendered below potential
data rows.

Recent work on the list view allowed to add buttons in group
headers (see 015958dc). However, we couldn't execute the action
of the button by pressing Enter, because the Enter keydown was
stopPropagated by another handler (folding the group).

This rev. makes this work, and also improves a bit the style of
the buttons in group headers.

Task 1915702

Assume an x2many editable list where the user edits a record (input
field), and then clicks on 'Add a line' (and keeps it pressed for a
while, before releasing the click).

When the 'mousedown' event occurs, the 'change' event is triggered
on the edited field, and (once potential onchanges have been
applied), the list is updated, i.e. all rows except for the one
being edited a re-rendered.

However, the 'Add a line' handler listens to the 'click' event,
which never occurs if we release the click after the rows have been
re-rendered.

This is an issue for every rows, not only 'Add a line', but for
data rows, the issue is already present in former versions, and is
not that easy to fix). The 'Add a line' case is a consequence of
the recent work on list views (see 234d92c4), so we can fix it
independently.

Task 1915702

There was one tax group per tax which was strange, so remove all duplicated tax group and only keep one tax group per tax percentage (0%, 6%, 12%, 21%)

closes odoo/odoo#32585

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

Rev. odoo/odoo@9fbb4fb wrongly removed the fixed width on handle and
button width on list views.

This commit restores it.

closes odoo/odoo#32467

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

Since rev. odoo/odoo@015958d it is possible to add buttons in list group
headers. These buttons are defined in <groupby> nodes, pointing to m2o
fields. Modifiers specified on these buttons thus use fields on the m2o
comodel.

There was a traceback in editable list view, when grouping by a m2o
that defines a groupby button with modifiers as the modifiers are not
registered with the same datapoint. When updating the modifiers, one
must ensure that the modifier are related to the updated record.

closes odoo/odoo#32456

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

Task#1964518

This commit removes es6 code that was unintentionaly introduced
by the product configurator for better compatibility

closes odoo/odoo#32452

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

Since 491deeb3, only check related to
reconciled invoices are printed. Adapt test to take it into account.

Usecase:
- Go on a BoM with a routing. Go on the first operation and set
the next operation(batch field) as 'Once a minimum number of products is
processed'.
- Set the batch size (minimum operation) to 0.
- Create a MO and plan it.
- The second work order has state 'pending' instead of 'ready'

It happens because the system automatically set the first wo as
'ready' and the following as 'pending' and don't check the batch
and batch_size.

closes odoo/odoo#32628

Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>

closes odoo/odoo#32591

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

closes odoo/odoo#32582

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

The validation error introduced in 552da8dc can pop up in contexts where
it is not expected;
e.g. not in editing user rights but while upgrading a module.
Therefore we make it more explicit, giving the user a way to resolve the error.

closes odoo/odoo#32623

Signed-off-by: Nans Lefebvre (len) <len@odoo.com>

From an onchange, at this point, (4) doesn't mean "no change" it means
"reset to database values". Through the interplay of client and server
reverse-engineering one another at this point the client (is supposed
to) assume the o2m results are "complete" and a diff from the
current *in-database* values rather than the in-client (sent to the
server) ones.

So a (1) should completely replace all existing values, and a (4)
should just remove all of them (but keep the record linked).

closes odoo/odoo#32617

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

Steps to reproduce:
- Create a sale.coupon.program with a discount of 10% and generate coupons for it
- Go on the shop and add a product of 100€ in the cart
- Go in your shopping cart and add a promotion code
- A new line has been created in your cart with a discount of 10€
- Click on "Process to checkout"

Bug:

The discount had been removed from the cart

Technically:

When clicking on button "Process to checkout", the function "recompute_coupon_lines" is called several times.
The second time, in function "_remove_invalid_reward_lines", the valid applied coupon program couldn't be retrieved
due to the sale price of the discount_line_product_id = -1000000 €. The function _filter_on_mimimum_amount filtered
the targted program  because the untaxed_amount of the order was equal to -999900€. So the program._compute_program_amount
was all the time greater than untaxed_amount or untaxed_amount + tax_amount

It s not consistant to set a default value to -1000000 to prevent pricelist strikethrough because in some currencies,-1000000 is not enough.
Now the reward lines are not strikethrough.

X-port/cherry-pick of odoo/enterprise@2748249c0b0674d659a363bae4acbc7b4c230dc7

opw:1957671

I shouldn't have trust the comment and apply the patch anyway.

Task#1958723

This commit fixes the survey form to allow creating, testing and sharing
surveys that don't have sections as long as they don't use the "page_per_section"
layout.

closes odoo/odoo#32159

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

- when answer is correct, then score should be +1.

Related to Issue: 1967506

closes odoo/odoo#32612

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

Steps to reproduce the bug:
- Create a SO with no salesperson
- Add a SO line with 2 storable product
- Confirm the SO and deliver only one product
- Click on "No backorder"

Bug:

A error was raised because the function "_log_activity"(called by _log_less_quantities_than_expected) requires a responsible

Partial Backport: https://github.com/odoo/odoo/commit/e1f9499d2672fb0a346f8ac74552f038f5204a64



opw:1950968

closes odoo/odoo#32592

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

This allow enterprise tests to pass.

- Set a product P to average valuation, real time
- Create a PO for 1 unit @ 100, validate the picking
- Create a PO for 1 unit @ 0 (e.g. you receive a free product)

You cannot validate the picking because of the message 'The cost of P is
currently equal to 0...'

This error message is historical, to prevent users from an incorrect
configuration.

Since we still want to prevent misconfiguration, but support the
mentioned use case, we introduce an `ir._config_parameter` for people
who 'know what they are doing'.

opw-1962249

closes odoo/odoo#32550

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

This reverts commit abc45b19
Since by default the ondelete attribute of a many2one is `set null`,
this was completely unnecessary to begin with.

Bug caused by this commit:
Unlink a record that has some attachments.
The unlink first removes the record, then its related attachments.
It calls remove_as_main_attachment, which reads the attachment res_model and
res_id. This triggers a check that the related record can be read.
However the related record has already been removed, an exception is raised.
It is thus impossible to unlink a record.

Closes #32563

closes odoo/odoo#32572

Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

In multicurrency

Do an invoice with cash basis lines in the foreign currency
Make a payment for almost all the invoice
"almost" refers to the point where virtually all taxes will be paid

i.e., paying 90 over 100, that contains a tax of 5%
The tax paid will be an amount almost equal (to a few cents) to the
total amount of the tax
It is not negligible, but if the currency rates are in the right configuration
(i.e. 0.005888)

Before this commit: the Cash Basis reconciliation will be considered as full and will trigger
the creation of the Exchange Diff Entry.
In turn, paying the rest of the invoice will pop up an error saying that some entries are already reconciled
(with the Exchange Diff entry)
It is not *that* that an exchange rate entry has been created the first time
after all, a percentage sufficiently close to 100 has been paid
But it blocks subsequent reconciliation, hence this fix

After this commit, if the cash basis entry doesn't match at least 100% of the paid move
then, we force to not check for full reconciliation

OPW 1953027
closes #31168

closes odoo/odoo#32023

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

Before this commit, test reconciliation was inherited by
test reconciliation widget.
It made the actual test_xx functions of the former
being executed twice

After this commit, we create an intermediary test class for setUp and helpers
And the tests for each class execute only once

Before this commit, when reverting a move
that will be subjected to the creation of a cash basis move
the process failed saying that some entries were already reconciled

That was because the process tried to create the cash basis move during
the revert.
This is  wrong, because no real cash is dealt with.

After this fix, the move lines of the original entry are reconciled
only with their revert counterpart

OPW 1938809
closes #30972

Oversight of 82d733d6

See #32149

closes odoo/odoo#32557

Signed-off-by: Christophe Simonis <chs@odoo.com>