Related fields are by default readonly and they should be when it
is possible. A editable related field will write on the related
model and will cause extra unwanted write of data. These unwanted write
can cause performance issues in some case (see odoo/odoo#63865).
Then remove the `readonly=False` of some related fields
(where it is useless):
- In 'mrp.workorder' (mrp): `working_state` and `production_date`
should be readonly.
- In 'purchase.order' (purchase): `product_id` should be readonly.
- In 'purchase.order.line' (purchase): `state` should be readonly.
- In 'product.supplierinfo' (purchase_requisition):
`purchase_requisition_id` should be readonly.
- In 'purchase.requisition' (purchase_requisition):
`product_id` should be readonly.
- In 'product.template' (stock):
`route_from_categ_ids` should be readonly.
- In 'stock.move.line' (stock):
`is_initial_demand_editable` should be readonly.
- In 'stock.move' (stock):
`product_tmpl_id` should be readonly.
- In 'stock.production.lot' (stock):
`product_uom_id` should be readonly.
- In 'stock.quant' (stock):
`product_tmpl_id` should be readonly.
- In 'stock.rule' (stock):
`route_sequence` should be readonly.
- In 'stock.change.product.qty' (stock):
`product_variant_count` should be readonly.
- In 'stock.return.picking.line' (stock):
`uom_id` should be readonly and also because it
is forced by `_prepare_stock_return_picking_line_vals_from_move`,
it should be related to the product uom not the one on the move.
task-2424248
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>
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
- 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>
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>
This commit makes use of _origin.id instead of .id into
mrp.workorder.name_get(). name_get() can be called from a compute method
(via _plan_workorders) which implies virtual ids. Searching amongst real
ids with a virtual one was not possible back then.
Task : 2278147
closesodoo/odoo#56469
X-original-commit: 346ecc3a52a7d1c3a2c6409a6799f6b013c3b6da
Related: odoo/enterprise#12641
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
- Go to Manufacturing > Configuration and activate Work Orders
- Create a Product (i.e. Product X) and create a Bill of Materials for it (with a Routing)
- Go to Manufacturing > Operations > Manufacturing Orders and create one for Product X
- Mark as Todo and Plan
- Go to Manufacturing > Operations > Work Orders and open the created one
- In Time Tracking tab, edit Planned Start Date or Expected Duration
The Planned End Date is computed without using the working calendar of the work center.
The working calendar should be used as it was at creation.
opw-2314555
closesodoo/odoo#56290
X-original-commit: 7b70da788d3a222467d88b06324a41e6c6efe605
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
- Refactor `order_finished_lot_ids` compute, to be linked to the `lot_producing_id`
the the related production (less boiler plate). We can't remove it because
it is used in mrp_subcontracting, and keep the Many2Many, for the tag widget.
Remove the second field compute by this method, `finished_lots_exist` (never used).
- Remove unused field `needs_lots` (also it is a duplication
with `has_tracking` info) from `stock.move` (mrp)
- Remove unused field `done_move` from `stock.move.line` (mrp).
- Remove unused methods `_strict_consumption_check` and `_update_raw_move`.
- Remove unused variables.
odoo/upgrade#1594closesodoo/odoo#54996
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Issue: when we created a new operation from the MO form,
the default of the expected_duration wasn't take in account and
override to 0.0.
Fix: in `_get_duration_expected` If there isn't workcenter is set,
instead of return False, return the `duration_expected`
closesodoo/odoo#56127
Related: odoo/enterprise#12517
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
It was impossible to add a workorder after a finished one
due to a constraint in the write (can't change next_work_order_id).
Remove this obselete constraint.
task-2278147
This doesn't make sense anymore: when we record production on a WO, in
any cases everything is processed as we make backorders.
Part of: https://github.com/odoo/odoo/pull/54283
task-2278147
Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
Replace wrong usages of any(list|recordset), by any(generator)
to speed up computations, avoiding list creations and/or looping twice on a recordset
for nothing.
any([generator]) => any(generator)
any(filtered) => any(generator)
closesodoo/odoo#55768
Related: odoo/enterprise#12360
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Starting a workorder should update the scheduled date only if the production
is started sooner than expected. In this case we want to clear the
calendar for the other production. If the production is started later
than expected, updating the calendar has no effect. We leave the
scheduled date unchanged to keep the information
Task : 2278147
Updating the quantity to produce on a production order will recompute
the expected production duration. This can be counter productive on
prototyping production when no BoM are given. The default expected batch
duration is set to 60 minutes. Setting the actual production time then
updating the quantity to produce will naively change the duration to
60 x the new quantity.
This commit compute the duration pro rata in case of 'no BoM' production
and recompute everything in case of BoM production.
Task : 2278147
Avoid concatenation of translated strings & raw values and/or other
translated values, and use the new _ API (by providing the formatting
values to ensure the fallback on the english terms in case of wrong
translation).
By including the expected values inside the string to translate, we
ensure that the formatted values are included at the right place in the
resulting translated text.
This also provides more information on the string to translate to
the translators, s.t. the chosen terms for the translations can be more
adapted to the translation context.
closesodoo/odoo#54635
Related: odoo/enterprise#11925
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
On a MO which product_id has a serial tracking, some components and 2
or more WO:
The method _set_qty_producing of a WO will call the MO _set_qty_producing
method even if no changes is made on qty_producing which can produce an
undesired aditional move line when creating the MO.
On a MO which product_id has a serial tracking and some components:
Changing the qty_producing on a MO was adding a line on the component
move.
Since the _set_qty_producing method is called when creating a WO it sets
the qty_producing of the MO to 0. As it does not make sense to have a WO
set the qty_producing of a MO to 0 we will not replicate it.
task-2278147
closesodoo/odoo#54579
X-original-commit: ca8275aa28010b73cad14f667068e9cfc6c651a5
Related: odoo/enterprise#11896
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When more than one parameter is present in a message, it helps the
translation to use named placeholder. This way, the order can be
changed. It also helps the comprehension of the message.
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
Bunch of last minute fixes including:
- serial handling in tablet view
- expected durations and backorders
- button unplan unlinks the leave but the computed aren't recomputed
then we need to manually set the date_planned_start/finished
then we need to not propagate them on the related document
(move/production) because they are required
- operation company_id wrongly set
task-2241471
Removed abstract workorder
Removed the integration of expiry wizard in tablet view since it should
be moved in enterprise in the tablet view implementation (not possible
to set consumed lot on workorders on community anymore)
Refactor _set_quantity_done to use ORM command in order to not return a
dict with vals to_create/to_write
task-2241471
Instead using production name + name of WO as name in the
leave record, use the display name of WO to reprensent uniquely
the leave (even this record is not really reprensent in views).
task-2241471
The field note of mrp.routing.workcenter was not very usefull, and not
appear in the workorder related to this operation. Sometime, we need to
have a small description of the work to do for a opeartion in the WO,
instead of a complet pdf or google slide.
-> Convert the note field as a description of the job to do and add a
"text" worksheet_type to select it, in the mrp.routing.workcenter and
add the related field in the WO. Update the view of accordingly.
-> (migration): The 'note' content remain the same, then migration is
not needed. If the user change the worksheet_type into text, the
"note" will be the previous "description".
task-2196687
When a field is related, defining a selection or selection_add will
have no effect and the paramater is ignored.
Log a warning and fix all fields badly definied
Closesodoo/odoo#45716closesodoo/odoo#45832
Related: odoo/enterprise#8613
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The icon of the json popover become a warning icon
when there is a issue. Also, create a
field show_json_popover in mrp_production
to avoid using d-none to put in invisible the popover.
task-2178494
closesodoo/odoo#45420
X-original-commit: 270e8d34b2adec07e8ae3b8952514184d2a00b59
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Purpose: adding new component in a specific workorder via the form view.
This behavior is only available if the Bill of Material is in flexible
consumption. Adding new component was already made possible in
e1f518bb83 but the ability to add new
workorder lines conditionnaly in the workorder form view was missing.
Task: 2121714
Consuming product tracked by lot (or serial number ) to produce product
also tracked must ensure the link between the two lots (consumed and produced)
is always set. This test is not done in community version while there is
one in the enterprise conterpart (mrp_workorder module). This commit
move this test to the mrp module to have it everywhere
Task : 2121714
In some flows, a planned_datetime_start/finished will contains
milliseconds. In these cases, we can detect overlaps/conflicts between
workorders but these conflicts can't be see in the web interface
(because datetime is truncate when it is display).
Then, change the conflicts computation to remove milliseconds
in search of conflicts.
task-2169447
closesodoo/odoo#43013
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Now, the fields date_planned_start and date_planned_finished is
required in views, because it was strongly related to the leave date_to, date_from
which are required.
- Change the name_get in case of single WO in MO and replace the dot
by a dash.
- Improve the WO form view to be more responsive when it is open from the
gantt view.
- Change name of a Operation in the demo data
task-2169447
- Before, the auto-planning of workorder autorize overlaps between then.
E.g. if a workorder (WO1) begin at Now + 30min with a duration of 60 minutes
and we try to plan a new workorder (WO2) Now, this one will be plan now
until Now + 120 min (30 min of WO2 + 60 min of WO1 + 30 min of WO2).
In our case we don't want this behavior by default,
because in real case, it is not efficient to work on job A during
30 min, after change to pass to a other job B, and rework on A after
the job B.
But in a other hand, we need to accept overlaps with no-working hours
intervals. Then, rewritte the _plan_workorders method to take
these features in account.
Also small fix about the planning has been done:
- Due to the strong link of date_planned(_...) between the MO and WO,
the replan of the late first WO was wrong.
If the MO is planned before now, then don't take in account
date_planned_start and try to plan WO as soon as possible.
- Also, fix error handling when the WO is planned before the
previous one.
task-2169447
Remove color and capacity fields of mpr.workorder unused
and coming from commit : 2ddc35a530 .
closesodoo/odoo#42498
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
_get_unavailability_intervals didn't return the correct
dict (describe in the docstring). Then the override in
maintenance module was wrong.
task-2082261
closesodoo/odoo#42530
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Add scheduling information (icon) with popover to show info/warning/error
about the scheduling of workorder. Four extra pieces of information
is given (level change the color of the icon):
- Info level; If previous WO and pending state, show sheduling info of the previous WO
- Warning level; info if the WO is late
- Error level; if conflit with other WO (same workcenter in same time)
- Error level; if previous WO is planned after the current one
Also, add a button (in the popover) to replan correctly all WO of the MO of
the current WO (only if it is not in ready/progress and error(s) is detected).
It is done via a JSON data compute field ('json_popover') in the workorder and
the popover_widget of stock. It is allowing use to make computation in batch
and avoid to add lot of fields.
task-2082261
closesodoo/odoo#41950
Related: odoo/enterprise#7296
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
In order to clarify the flow of work order in calendar and gantt view,
add the sequence number of WO by MO. This sequence is
compute during the call of the "name_get".
task-2082261
Use case:
Plan a production of 10 units on 2 workorders. Produce 4 units of lot1.
Record the production and produce the 6 next ones with the same lot1. On
the second workorder, the suggested quantity is 4 and not 10.
This issue is due to the fact that we fill the next workorder quantity
only at the first production batch and we don't check that the same lot
can be used again.
This commit call the mathod to update the quantity on the next workorder
if the first lot is produced again.
closesodoo/odoo#41189
Opw: 2127665
X-original-commit: e15fc6ac994edabc8907c13295c883cff9320d10
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This commit extend the flexible consumption. On the workorder form view.
It's now possible to add directly new workorder line with any product
(even one not in any BoM line). For those new wo line. A confirmed stock
move is create in the record_production step.
Task : 2082448
Rémy Voet (ryv)