Technical refactoring in order to set by-products the same way
than raw materials. Before this commit byproduct were always set
at the last workorder or automaticaly set at the end of produce
wizard with the same quantity than in the BoM. In order to modify
it, the user has to produce the finished product then unlock and edit
the finished move line linked to the byproduct. In this commit, the
user could specify at which workorder the byproduct is created and
he could directly specify another quantity done in the produce wizard
inside a specific tab for by-products.
Technicaly, abstract workorder will add a new many2one key on workorder
line in order to set 2 different one2many (one for finished goods and
the other for raw materials). The key is set depending the many2one
key for production on the linked stock move. On the by-products itself,
it is now managed as a workorder line, thus the code to generate them
and transform them in a finished stock move line is the same than for
the raw components.
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.
closesodoo/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 015958dc17). 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 234d92c4f0), 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%)
closesodoo/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.
closesodoo/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.
closesodoo/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
closesodoo/odoo#32452
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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.
closesodoo/odoo#32628
Signed-off-by: Simon Lejeune (sle) <sle@openerp.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.
closesodoo/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).
closesodoo/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@2748249c0b
opw:1957671
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.
closesodoo/odoo#32159
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- when answer is correct, then score should be +1.
Related to Issue: 1967506
closesodoo/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
closesodoo/odoo#32592
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
- 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
closesodoo/odoo#32550
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This reverts commit abc45b1
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#32563closesodoo/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#31168closesodoo/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
Before this commit, Odoo notifies the user of all the recurring past
events, existing before the installation of the module Calendar (old
events imported when synchronizing with Google, for instance). This
occurs only the first time a synchronization with Google is made. This
occurs because Odoo notify all the events that occurs since the last
time it notified, and the first time you install the module the date of
the last notification is empty.
Now, when the module Calendar is installed, the date of the last
notification is set by default to the current date (the date of the
installation of the module)
opw-1942443
closesodoo/odoo#32535
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Arnold Moyaux