We add a index on the workcenter_id and workorder_id, both
have a One2many related to (`time_ids` of workcenter and workorder)
and both is in the some search domain in python (also in search view).
(Also change the `readonly='True'` into correct form `readonly=True`
of `production_id`, and remove duplicate fields `workcenter_id` in view)
task-2389380
closesodoo/odoo#63500
Related: odoo/upgrade#2042
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
The `bom_id` field has a One2many inverse `byproduct_ids`
then it should by index to avoid bottleneck if byproduct is
highly used by a lot of different BoM
Performance improvements:
When there is 20K of Byproduct line, read a BoM is x1.8 faster.
task-2389380
Remove index on fields `date_start` and `date_finished`. Both
has not used expected in the gantt view `view_production_gantt`
which not used anymore (and have no sense because it should use
`date_planned_start` and `date_planned_finished` instead.
Remove this old gantt view too.
task-2389380
The state of `mrp.unbuild` is a boolean value (`draft` or `done`) which
is already quite useless in the most of the case. Also this state is
never used explicitly in the code (in a search), then it seems legit to
remove it.
task-2389380
Indexed of boolean values is quite useless and the one of `priority`
(MO/Pickings) can be only used in filter search view (`starred`).
Then remove priority indexes from `stock_move`, `stock_picking` and
`mrp_production`.
task-2389380
- Create a new MO
- Remove the company name
The user see a traceback
This occur because the compute method does not check if the company is
set
opw-2422441
closesodoo/odoo#63917
X-original-commit: b7fa0cfad03a8319f03c1aa89eb67635e1200f67
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
`product_tmpl_id` of BoM line should be readonly,
there is no sense to change the product template from
the BoM line model. Also it avoids useless write on product
and inverse recomputation.
opw-2420830
closes#63631closesodoo/odoo#63890
Issue: odoo/odoo#63631
X-original-commit: 5a4746141670bdd241d85c7908a57ee9efa56c3f
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
With this commit, all instances of errors being raised inside
`BaseModel.unlink` overrides are moved into methods decorated with
`api.ondelete` which is safer.
- Create Product A with UOM of type Unit
- Create Product B with UOM of type Unit
- Create BOM of type Kit on Product A with Product B as a component
with UOM of type Unit
- After saving BOM, change the UOM of Product B with UOM from another
categories (e.g. kg) and save the product
- Try to access product list
A warning appears and prevent showing the products in any way.
It is caused by the call to `_compute_quantities`.
In this case, it is ok to skip the error. Indeed, it will raise later on
when trying to use the kit. But at least, it gives the possibility to
the user to access the product list.
opw-2393711
closesodoo/odoo#62537
X-original-commit: 6de2537ac82d9dad3cb3f56a7b9b35856681a6ad
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The 'On Hand' button triggers action_open_quants on product model. It
do not explode the kit into its component
closesodoo/odoo#62390
X-original-commit: 49b965eb1ec6a7ec6c07fa643cc6ae35ee8b5d91
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
What are the steps to reproduce your issue ?
1. Install 'Manufacture' and enable 'Work Order' in settings
2. Create product 'ProductA', enable 'Manufacture' in 'Inventory' tab
3. Create a BOM for 'ProductA'
4. For that BOM, create a new operation called 'OperationA' with PDF worksheet but don't attach any PDF
4. Go to 'Manufacture' and create a MO with 'ProductA', the 'OperationA' is automatically set in 'Work Orders'
5. Start the work order
What is currently happening ?
When you try to pause, an error is raised.
'TypeError: Cannot read property 'pdfViewer' of undefined'
What are you expecting to happen ?
Start and pause the work order even without attached PDF.
Why is this happening ?
'this.pdfViewer = existing.data('PDFViewerApplication').pdfViewer'
When there is no pdf attached. The data 'PDFViewerApplication' does not exist.
How to fix the bug ?
Change worksheet default value to text, and make the field mandatory in case of a PDF type
opw-2387428
closesodoo/odoo#62350
X-original-commit: 8597aada3d9bacc3cff4707bb78a7bc48d723cfb
Related: odoo/enterprise#14992
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
This commit makes it so a note is logged when an unbuild order is linked
to a manufacturing order is completed.
closesodoo/odoo#62012
Task: 2378831
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
- Create product FP product to manufacture
- Create BoM:
- 10 units of FP
- Product CP (component)
- two operations.
- Create MO for FP and plan.
- Complete operation 1 for the 10 units
- Complete operation 2 for 4 units only
- Mark MO as done for 4 units
- Click Create Backorder
- Check backorder MO
Operation 1 is present, marked todo for 6 units,
but it was completed for all 10 units.
With this commit the quantity todo for the corresponding operation in
the backorder is updated to match the qty already produced
Removing `qty_producing` as it is computed according to
https://github.com/odoo/odoo/blob/ff648a0ace9cf72274211662707e7ee33fc73252/addons/mrp/models/mrp_workorder.py#L50
opw-2374640
closesodoo/odoo#61841
X-original-commit: a32bdf257d7a960fcd96cf6d32443bfe0295a296
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
`do_unreserve` is a action that can be made in the tree view of
`stock.picking` but it was very slow and not batched.
For 80 picking with -/+ 10 `stock.move.line` related each
(calculate on 5 sample of 80 pickings):
It took 17947 +- 2741 SQL requests, 7.37 +- 1.09 sec of SQL
and 8.13 +- 1.31 sec of python execution (+- 15.5 sec in total)
Make some change to speed up the unreservation of
multiple picking/move:
- Batch the call of `_do_unreserve` of move in picking
- Use OrderedSet instead of RecordSet to reduce the complexity of
`_do_unreserve`. (Become significant when len(recordset) > 1000)
- Add `.with_prefetch()` in the unlink of stock move line
to patch issue with prefetching + unlink + cache.
- Batch `_recompute_state`
- Also batch the `do_unreserve` of MO
Result after change in the same samples:
It take now 1438 +- 20 SQL requests, 0.45 +- 0.02 sec of SQL
and 0.68 +- 0.02 sec of python execution (+- 1.13 sec in total,
13 times faster). Note that the gain increase proportionally.
task-2383111
closesodoo/odoo#62083
X-original-commit: e7a43655448db161150d0c62efa14c54ade0a2f6
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Otherwise, they may crash or be incorrectly verified when
creating/updating recordsets containing multiple records.
Also improve the constraint error messages to be more detailed.
When possible, use a sql constraint instead to speed up the records
validation.
Task Id: 2328664
COM PR: https://github.com/odoo/odoo/pull/55525
ENT PR: https://github.com/odoo/enterprise/pull/12250
Activate units of measure and workcenters (work operations)
Create Product C, uom Kg
Create Product F, uom Kg
Create BoM for F, 2000g manufactured from 5000g of C
Set 1 operation/work order in the BoM: processing
Create MO to produce 2kg (change the uom in the MO) of Product F
from 5000g Product C
Confirm MO and go to the work order put the quantity of Product F to 1 Kg
then click Record Production/Mark as Done
The manufacturing backorder is automatically created but is not
showing the components.
This occur because of a mismatch between the uoms, `move._split` expect the
parameter `qty` to be based on the product uom, instead it is the quant uom
because the BoM was created using a different UoM than the one defined
in products
opw-2376217
closesodoo/odoo#61782
X-original-commit: 8b32e558fde3cb3aaa1deb40acb07488d04d343e
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Add to `check_company` on `bom_id` of operation, to avoid company issue
after in MO when we create `mrp.workcenter.productivity.loss`.
Also remove the readonly on `company_id` to get the possibility of
modify it if the company_id of BoM change.
Checks the MO `date_planned_start` is set to do the onchange.
Also, add `product_id` in the onchange trigger because the produce delay
can be different for each product and so the MO `date_planned_finished`
must be recomputed also when the product change.
task-2359839
closesodoo/odoo#61295
X-original-commit: b48d0047f6a0a3084739e8991f32aae4a2b399c2
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Usecase to reproduce:
- 10 company having 10 000 moves in state 'confirmed', 'partially_available'
- Run scheduler manually (without cron)
It will takes a huge amount of time.
It happens because the run scheduler wizard will call run_scheduler
as sudo for each company (passing company as arg).
run_scheduler will try to assign move that could be reserved. However
the domain in order to search move do not include the company_id and
search for every company.
Following upper usecase:
Instead of running action_assign 10 times on 10 000 moves, it will
run action_assign 10 times on 100 000 moves.
Databases with multi companies and having a lot of stock will have a
scheduler speedup from this patch.
Thanks "Rémy Voet <ryv@odoo.com>" for finding this issue.
opw-2328707
closesodoo/odoo#61183
X-original-commit: a21f9876b5b9d01380d03d638deb48cd091f26e7
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
The _compute_is_planned() method was only triggered at the workorder
creation and not at the modification of date_planned_start or
date_planned_finished.
This commit change the depends fields to trigger the compute at right
time.
closesodoo/odoo#60620
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
The feature was actually not working as expected. It has been fixed,
and a test now ensures it does work as expected. This commit also fixes
some invalid parameters, hopefully nothing critical.
closesodoo/odoo#60429
X-original-commit: 231bdca3f26d96f578503694e5aec062de2317ed
Related: odoo/enterprise#14285
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When select a BOM in the field, now we only search by the finished
product name. In this commit, we will also match the reference of the
BOM.
Task 2326786
PR #57945
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Current behavior before PR:
It is possible to create a BOM that has a BOM line that reference the
same product as the BOM itself. This is undesirable as when we create a
manufacturing order for this product we will have an error.
It is a regression bug that was introduced in commit
575353e251a0cce3bbff759edaeb56b5718beb11 between v12 and v13.
Behavior after PR is merged:
When saving a BOM it will validate that no product line references the
same product, or the same product variant, as the BOM itself. Note that
it is allowed to have a BOM for a product variant that references
another variant of the same product.
opw-2347941
closesodoo/odoo#59633
X-original-commit: 917e4c67b4aa14ca71ec6cba4bc6d20a86459f42
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The Duration Per Unit should be averaged, not summed.
opw-2353041
closesodoo/odoo#59446
X-original-commit: 54b40f1eb096ea9531f1f9b0478937536c8292fc
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit makes sure we do not try to update the quantity on a
finished stock move (during record production or confirming the produce
wizard) if there is no finished move available.
Closes#57227closesodoo/odoo#59430
X-original-commit: 141df3b398aee2bac10e3ce94e15bb4bd14d17af
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Before this commit, when copy a workorder, the real duration was copied
too, which is unwanted.
task-2328830
X-original-commit: 6063bf7576a0abf975c2668ebacb6ad68c24315e
Before this commit, there was some bugs with MO by-product moves:
- When creating a new MO, if user deletes the byproduct move(s) then
save, the byproduct moves will be come back.
- With a newly created MO, in edit mode, increase the qty. to produce:
-> Creates a new byproduct move with updated quantity to produce
instead of update the existing one.
These issues was due to the fact when computing the byproduct moves on a
virtual record, the original move in `move_finished_ids` and its
counterpart computed in `move_byproduct_ids` have different virtual id
and so aren't considered as the same move.
X-original-commit: c1768d00e8eb76af32ead10f75ce3d09a5aefac9
This commit change the _split method to return new move values instead
of create it and confirm it.
This allow multi creation and multi confirmation when every move of the
recordset are split
Task : 2076873
closesodoo/odoo#58594
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
- On `mrp.production`, remove `workorder_done_count`
unused since mrp v14
- On `mrp.workorder`, remove `use_create_components_lots`,
unused since ed7012e8fd
Co-authored-by: Feyensv <vfe@odoo.com>
Usecase to reproduce:
- Launch 2 procurements for 2 manufactured products.
Only the last MO created has finished moves.
It happens since the list is wipped at each iteration.
closesodoo/odoo#57972
X-original-commit: d654c05f3e06898a5de025c1b830ba29c039f781
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Remove the json_forecast of the sale order line,
it was a duplicate of information with the qty_at_date_widget.
But improve this one:
- Use the forecasted move information in case of confirmed SO.
- Change the icon (i) to chart.
- Link to the forcasted change to target new forcasted report
(Unfortunately we loose the feature to see components product forcasted
of a kit)
- Change information print in the popover in case of confirmed SO.
Also refactor the json_forcasted of `stock.move` into multiple fields
to avoid to dump/loads for other model who needed the forcasted data.
task-2324039
closesodoo/odoo#56425closesodoo/odoo#57526
Related: odoo/enterprise#13063
Related: odoo/enterprise#13160
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
date_deadline of the stock move has been reviewed:
- Now, it represents the datetime when the operation must
be done to be in time for the uppest document (SO/PO/MO/RR).
- At the creation of stock move the date_deadline is computed in
the same way than the sheduled date expected that it is not include
security days (inverse the logic for PO).
- When we update the delivery date (or lead time) of SO (or PO).
The deadline of related stock move is updated and the delta is propagate
between origin and dest moves.
task-2324039
Was not super visible, especially without HR as the dialog immediately
closes (limitation of the web client), or when an administrator user
massively disables totp.
Show a toast notification indicating the success of the action.
Also fix the logging of `totp_disable` so it correctly handles being
called on more than one record, and change the logging data to
<browse_record> (<logins>) across the board.
Also add a way to provide an action to execute after a notification:
by default nothing happens, which leads to dialogs not closing and
forms not reloading, and there is no good way to show a notification
and/then do some other thing, which is inconvenient.
This commit does 3 things:
1. When 'action_confirm' is triggered in a manufacturing order, any
'move_raw_ids' (components) that are unable to be fully reserved
when `action_assign` is triggered will be checked for an automatic
reordering rule (RR). If a rule exists it will be auto-triggered.
This includes subcontractor manufacturing orders. Relevant test
updated to match this.
2. When a MO is completed, auto check if there are corresponding
confirmed stock moves that can be populated by the completed products
and trigger their 'action_assign' to reserve the completed products.
3. If a new move line is added to an already confirmed MO, then do same
auto-RR check/trigger. (note will occur for pickings without extra
code since `stock_picking.action_confirm` is triggered again in this
case.)
This reuses similar logic as odoo/odoo#52433 from task 2244230.
Originally this was done in the `action_assign`, but has been moved to
`action_confirm` so as to imitate the now archived MTO process with RR.
Overlapping logic has been moved into stock_move for easier reusability.
Note that this now means editing existing moves' `product_uom_qty` (i.e.
Demand) will not have a flow to auto-trigger their RR.
Subcontracting test updated to match + new mrp test added for this new
feature.
closesodoo/odoo#57334
Task: 2322496
X-original-commit: 2688cd1bae489b1dec8862f4de727ac20514844c
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
In case of manufacturing a product tracked by serial number,
there is no reason to be able to make it with a different UoM of
the product (which lead to rouding issue).
Then when we confirm the MO in this case, the UoM and quantity
will be converted to product UoM.
PR #56000closesodoo/odoo#57333
X-original-commit: f0da27e7eb474e6db4cd999306c420804aaa6f9b
Related: odoo/enterprise#13059
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Change the default rouning digits of all UoMs to be two, also change the
decimal.precision of UoM to be two. Adapt all the tests.
Also to avoid hardcoded digits in `should_consume_qty` widget.
PR #56000
X-original-commit: 460ec0402a2352a5b179d81935f7230f6bc97cb7
Steps to reproduce:
- Let's consider a product.template TP with a kit
- Let's consider the variants V1, the only variant of TP with a kit
- The virtual_availalbe of V1 is 100 (smart button Forecasted in the form view)
Bug:
The virtual_available of TP was 0 instead of 100
The virtaul_available of a product.template must be the sum of virtual_available of all its
variants with kit
PS: This commit changes the available quantity of product_product_table_kit in demo data.
As this quantity was not equal to 0, the type of the product could not be changed.
opw:2297226
closesodoo/odoo#57325
X-original-commit: 74b762da63e159b1965428b2bcb972293c4efea6
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Co-authored-by: Florent de Labarre <florent.mirieu@gmail.com>
Mainly transifex issues but also some errors found through 'grep' checks.
Fix typos and obscure english strings in xml contents, fields strings/helps, some docstrings, ...
ensuring correct translations base (and fallback when translations isn't available).
closesodoo/odoo#57276
X-original-commit: 4214f05d454bca2b60fda3a288d529c098e84f77
Related: odoo/enterprise#13053
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
tracked
On production order view, dot not show the Serial Numbers column
when in draft or when no component tracked by serial number
closesodoo/odoo#56889
X-original-commit: 4fc8374ee4470a05b27216999e341418e72f28ea
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When a user is accessing a work order in state ready, we are updating it and
rewriting date_planned_start field. We also update accordingly the associated
slot of the workcenter calendar (leave_id), but if the ressource of this slot
is linked to another user, a record rule on resource.calendar.leaves is preventing
the update, which should occur without error, even if the user does not have
Time Off / All Approver rights.
closesodoo/odoo#57120
X-original-commit: 790fb1820fbd49d07206963077216cc304ed2b0a
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
If there is no `date_end`, sorting will crash.
opw-2326262
closesodoo/odoo#56603
X-original-commit: e981c17dd93c756a5cf0384ab2dcc25ef58cb1b1
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In case `date_planned_finished` is `False`.
opw-2326088
closesodoo/odoo#56578
X-original-commit: 5c7c6b42cc0e0fa5bdd78aeca48cdf4ba9f78cad
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
TL;DR
=====
Improve performances with nearly a factor of 2. Use case, call action_validate on hr.leave for 100 employees
- 1987 requests -> 844 requests
- 1300 ms -> 700 ms
Purpose
=======
The first purpose of this commit is to add a test ensuring the number of request while creating
a company leave for 100 employees, if 15 of them already have a leave during that period.
It includes, the mass leave generation, and the conflicts resolutions. (Cancelling/Splitting the
already existing one and adapting the dates accordingly).
The second one is to reduce the number of request for this test.
In term of requests, currently we have:
- 5154 requests without bypassing the mail tracking + the activities management
- 1987 requests when bypassing the mail post-process (this is the current value, the bypassing was
already done several month ago)
- 844 requests with all the optimization done in resource/calendar/hr_holidays
In terms of execution time, we have a reduction from +- 1300 ms to call the method action_validate
to +- 700 ms
As the performances issues severity increases with the number of leaves to create and the real time access
to the database, on the production base, we reduced the execution time to generate more than 500 hr.leaves
from several minutes to 21 seconds. A fix to avoid deadlock was already made at
https://github.com/odoo/enterprise/pull/10740/files
Some contortions were made to avoid changing a signature method in a stable release and thus
introducing for each method a second one, with the "batched" implementation, to keep a retro-compatibility
for the existing custom code.
But surely this could be cleaned in the master version. The old one will be deprecated while waiting to be
removed in a few versions.
closesodoo/odoo#56534
Taskid: 2256705
X-original-commit: 8c96a887d3f05680c923dcd44f9c70c0e5e0bd32
Related: odoo/enterprise#12670
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Rémy Voet (ryv)