The quantity to consume for a component is computed in different places
(community and enterprise modules, workorder and produce wizard) during
a production. This commit share those computations into a static function.
closesodoo/odoo#32864
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Task 1966321
There are 3 different ways to configure a bank account and it’s confusing:
- config bar wizard
- journal
- bank account (Menu: Configuration/Accounting/Bank accounts)
We want to use the wizard for creation and the journal for configuration, so removing the bank account (Menu: Configuration/Accounting/Bank accounts) view).
closesodoo/odoo#32590
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
The link and media tooltips were not taking Summernote's `tooltip`
option into account. That option ensures that tooltips are disabled if
the option is off (which is for instance the case on mobile).
This fix ensures that these tooltips are disabled when the option is
set to `false`.
It also disables tooltips in the keyboard tests. They are not relevant
to the keyboard tests and occasionally caused the DOM to not be properly
cleaned after the tests were run (most likely due to their 2000ms
`setTimeout`).
Usecase to reproduce:
- Create a MO for drawer with SEC assemble BoM
- Plan the workorders
- In the first workorder record the production without specify a lot or
serial number.
- Second workorder, register a new serial for finished product and
record production.
A UserError that prevent to use a new serial number is raised. It
happens because the system check the remaing quantity on other
workorders + the quantity already produced for the current lot. In this
case the remaining quantity for the first workorder is 0 and the current
lot was not produced. However it should count the lines without lot as
a 'remaining quantity' since they could be used later to create a new
serial or lot number.
This commit register the lines without lot and use them to raise the
UserError and compute the allowed lot domain for finished lots.
closesodoo/odoo#32632
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- set the tax adjustment menu to be seen only in debug mode
- add a new reconcile model for suspense account
- change chart_template.py to consider 'to_check' field when loading
the COA
closesodoo/odoo#32780
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
This commit ticks the 'Create component lot' checkbox for
the demo manufacturing operation type of first warehouse.
This change will leave the default behaviour for all warehouses
but tests with demo data are now more straightforward and do
not demand too much parametrization
Task : 1970450
closesodoo/odoo#32772
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Commit 84ae731d5d used 'self.code' in a method
called by a multi one. As 'self.code' expect a singleton, the transaction
raise an error in case of multiple records into the recordset
This commit calls the method into a loop on 'self and change its signature
to pass 'code' and be sure its a non multi one
Javascript is responsible of showing the menu, potentially with some
parts regrouped in an extra dropdown, on page load (this is what we
call the "autohide" feature). This was done on both the menu and the
affix menu. It worked on the affix menu because the affix menu widget
was initialized before (by luck: alphabetical order).
Since the jQuery 3 update https://github.com/odoo/odoo/commit/bb004e3d7f3df5a5af6b2e994ec0af79e2da890f
deferred are always delayed (even if their resolve condition is met on
creation). This made the animations to be initialized in the same order
as before but their 'start' method to be delayed (as the willStart was
delayed). So what happened before was:
1) Find menus to enable affix
2) Enable affix on found menus (duplicate the menus to do that)
3) Find menus to enable autohide
4) Enable autohide on found menus (both the menu and the duplicated one
were found)
And since jQuery 3:
1) Find menus to enable affix
2) Find menus to enable autohide
3) Enable affix on found menus (duplicate the menus to do that)
4) Enable autohide on found menus (the duplicated one was not found at
step 2 since it did not exist yet)
In fact, widget starting should never have relied on alphabetical order.
The fix only consists of starting widgets on the duplicated menu once it
is ready. This is what this commit does.
However, doing this revealed another bug: if the widgets are started
only for a DOM portion like a '.a' element, a widget with a multiple
parts selector like a '.a .b' selector will not be considered, as
searching inside a '.a' element will not allow to match elements with
a selector containing a '.a'. This is in fact not really a "bug" but a
limitation, so unless we get problems because of this in stable
versions, we can only "fix" this for the current saas. This is fixed
thanks to `dom.cssFind` which already existed. This commit however
improves it to try making it more efficient.
closesodoo/odoo#32465
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Using "async" in the event parameter is not enough, you have to
return correct promises in the event handlers.
closesodoo/odoo#32479
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The closure overrides the arguments, which makes it impossible to
recover the attachment_ids hence sending null python code which then
breaks.
closesodoo/odoo#32810
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Make sure the move, journal and the accounts will share the same company to prevent undeterministic error in runbot ('Cannot create moves for different companies.')
closesodoo/odoo#32759
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Before on rubot
odoo.addons.sale_mrp.tests.test_sale_mrp_flow tested in 97.08s, 117272 queries
After on runbot
odoo.addons.sale_mrp.tests.test_sale_mrp_flow tested in 50.84s, 61903 queries
closesodoo/odoo#32537
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before on runbot
odoo.addons.mrp_subcontracting.tests.test_subcontracting tested in 11.40s, 14213 queries
After on runbot
odoo.addons.mrp_subcontracting.tests.test_subcontracting tested in 7.95s, 9863 queries
Before on runbot
odoo.addons.stock_account.tests.test_stockvaluation tested in 25.52s, 59252 queries
After on runbot
odoo.addons.stock_account.tests.test_stockvaluation tested in 20.43s, 38535 queries
before on runbot:
odoo.addons.stock.tests.test_move tested in 31.79s, 63166 queries
odoo.addons.stock.tests.test_move2 tested in 33.69s, 68046 queries
odoo.addons.stock.tests.test_quant tested in 8.48s, 15351 queries
odoo.addons.stock.tests.test_stock_flow tested in 16.99s, 31506 queries
amounting to 90 seconds on a build page
after om runbot:
odoo.addons.stock.tests.test_move tested in 12.41s, 24197 queries
odoo.addons.stock.tests.test_move2 tested in 13.55s, 24254 queries
odoo.addons.stock.tests.test_stock_flow tested in 9.74s, 15795 queries
amounting to 37 seconds on a build page
Use savepoint case instead of transaction case.
We took the opportunity to rename the master data more appropriately,
which results now in a bigger diff in TestMove and TestQuant. In
TestQuant, the master data creation had to be moved in the setUpClass
too.
We removed test_shipment as test_backorder_1-4 in tet_move_2 covers the
same parts of the code.
subproduct and byproduct are both used in code.
However the UI always shows by-product only.
Rename sub.product, sub_product,... in byproduct
in order to use the same term everywhere.
closesodoo/odoo#32540
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Be consistent with by-products and byproducts. Only use by-products.
When a product is created from the BoM view, it has a default type
as storable product, set the same type when the product is created
from by-products tab.
Usecase to reproduce:
- BoM with final product tracked by SN
- Produce wizard add a component tracked by SN (not from BoM)
- Produce and mark the MO as done
The tracability report do not show the extra component used.
It happens because _record_production call _action_done on moves raw
and finished. _action_done create extra move with moves that created
more than expected (the purpose is to trigger rules). However in stock
the new move is created then merged in its parent but in mrp moves are
not merge. _record production set the tracability for initial moves but
ignore the extra moves created. So the tracability report is not
complete.
Fix it by catching the new moves created after _action_done and set
the consume_line_ids for the extra moves also.
In MRP the tracability is only set between the finished
products and the components. However when the by-products is
tracked by serial number, it could be usefull to know from which
components it was created. This commit add the link between by-products
and raw materials (only in produce wizard at the moment).
Technically we replaced the one2many field by a many2many.
Unbuild a manufacturing order only undo the final product and its
components. The byproduct created will not be undo with the correct
ratio. This commit will allow to undo a ratio of byproducts for a
specific MO or base on the BoM if the byproducts are not tracked.
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>
William Henrotin