How to reproduce:
- Open PLM app, open an Engineering Change Order;
- Click on "Update Documents";
- Try to upload a document -> Traceback.
As we did not cast res_id as integer, the check method of ir.attachment
crashes when accessing company_id on a malformed recordset of ECO
because the domain generated by _filter_access_rules_python is:
`['|', ('company_id', '=', False), ('company_id', 'in', [2, 1])]`
This route is also used when adding attachment to a `product.product`.
In this case the check didn't work either but somehow passed because no
domain is generated by `_filter_access_rules_python`.
The following snippet shows that if there was one, it would also crash:
```
In [16]: records
Out[16]: product.product('25',)
In [17]: records.stock_move_ids
Out[17]: stock.move()
In [18]: self.env['product.product'].browse(25)
Out[18]: product.product(25,)
In [19]: self.env['product.product'].browse(25).stock_move_ids
Out[19]: stock.move(41, 13)
```
task-2223153
closesodoo/odoo#48515
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
With this commit, Selection fields with `required=True` which are
extended via `selection_add` are given proper ondelete policies to
ensure the cleanup of records containing these extended options during
uninstall of the extending module.
This commit also cleans up leftover uninstall hooks that were being used
to handle the same set of problems prior to the ondelete mechanism being
implemented for Selection fields.
closesodoo/odoo#46325
Related: odoo/enterprise#9117
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Usecase to reproduce:
- Create a MO as draft
- The stock move inside don't have a reference despite the MO name is
already set.
It happens because the reference and the group are set during the
action_confirm. However it's not great if the user takes time before
confirmation or if he cancels the MO. In those case the reference
on the moves remains 'new'.
opw-2201986
closesodoo/odoo#48568
X-original-commit: 1b7e304a907d8a43d5f561226028a4b353902fab
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Steps to reproduce the bug:
- Let consider a user U from a single company C (Multi companies = False)
- Let's consider a BOM B for a finished product FP with product P1 as component and product P2 as byproduct
- Let's consider that P2 is tracked by lot
- Log as U and create a MO for FP
- Produce the MO
Bug:
A widard was opened but it was impossible to create a lot for P2
opw:2216028
closesodoo/odoo#48556
X-original-commit: 30ebdee091362b8c857bdcad2bdf44bd698572c4
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Creation of production order from a bom with 0 quantity to produce will
fail. As there is already a constraint on the quantity to produce on MO,
this commit adds the same constraint on BoM.
closesodoo/odoo#48485
X-original-commit: 1330500885ae096372ab32fba4ffc9db252dd2d4
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Confirms and plans the manufacturing order created for table (MTO) in
demo data to have already a work order.
task-2199747
closesodoo/odoo#46464
Related: odoo/enterprise#8922
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this commit, some tracked product quantities didn't have a SN/LN.
To avoid some issue at the use, it's better all demo data fulfill
requirements like that.
Task #1970460
Demo data product's quantities are no more put in sublocation as by
default, multilocation aren't active.
Also, adapts `test_location_usage` because as we moved quantities from
sublocations to the main stock location, the stock warehouse will have
reserved quantity due to a backorder created by demo data.
In this test, we try to change location as a scrap location, what we
can't do if this location has some reserved quantities.
Task #1970460
Handle missing barcode for 'pick components' and 'store after
manufacturing' picking types
closesodoo/odoo#47201
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Commit abef168389 adds the fields
'product_description_variant' on mrp.production and purchase.requisition
models. This text is taken from the product variant.
This commit make them invisible in case they are empty.
closesodoo/odoo#47716
Related: odoo/upgrade#948
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
When `mrp` or `mrp_subcontracting` are uninstalled, the routes used as
'Picking Before Manufacturing Route' and 'Resupply Subcontractor' are
kept active. When the modules are re-installed, the routes are created
again, and appear duplicated.
The routes should be deleted if they are not used anywhere else.
opw-2222895
closesodoo/odoo#48206
X-original-commit: ce219b8375dc14daf9d380433d254b622a947773
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Purpose of this task is to prevent users from setting portal users on
internal documents by mistake, and preventing noise and performance
issues resulting from loading all the portal users in those fields.
This commit fixes internal many2x fields to res.users which are now
restricted to internal users by setting domain (share=false) on form view.
closesodoo/odoo#47553
Taskid: 2172779
Related: https://github.com/odoo/enterprise/pull/9204
Related: odoo/enterprise#9204
Closes: #47553
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
* remove global assignation in xml, it is a computed field anyway, let the orm compute it
* put all `ir_rule` definition as noupdate in the xml
closesodoo/odoo#47688
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Purpose
=======
The main definition of 'assignation' is the following:
"an appointment to meet someone in secret, typically one made by lovers"
The correct word we should be using is 'assignment':
"the allocation of someone or something as belonging to a particular group or category"
So in this commit change every iteration of the word
'assignation' to 'assignment', across all modules.
closes odoo/odoo#45041
Taskid: 1966215
Closes: #45041
Related: odoo/enterprise#8375
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
- Change the font-awesome icon from fa-book to fa-question.
- Change the icon color to text-secondary (the same than the multi-company
icon).
- Adjust the icon size to the uppercase text size.
closesodoo/odoo#47210
Taskid: 2209062
Related: odoo/enterprise#9116
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- In inventory app, create an attribute that is dynamic
- Create a product with a variant with the dynamic attribute
- Create a bom for the product with some specific component for that variant
- Open structure and cost
A crash occurs.
In this case, the object is a `product.template`, so a condition
product-specific shouldn't be checked.
The template is set at:
https://github.com/odoo/odoo/blob/3588487ab4ef867f7fb981a395deaf298eb4a4e4/addons/mrp/report/mrp_report_bom_structure.py#L107
opw-2198976
closesodoo/odoo#47769
X-original-commit: 3c476dee5d3a0cc0fde0f9c6620507a07929e4fc
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- create product comp1
- create product finished1
- created bom: 1 comp1 for 1 finished1
- activate PBM
- 100 units of comp1 in stock
- create an MO for 5
- on the pbm, deliver 3 and no backorder
- on the mo, check availability, produce 3
- on the pbm, unlock, change delivered qty from 3 to 5
On the mo, the raw move is reserved to 5 units but the 3 units
used in the first produce are removed.
It happens because editing the quantity or initial on a move
will try to reserve the next moves. In order to reserved,
_do_unreserve will destroy the stock.move.line and _action_assign
(call just after) will recreate them in order to regenerate the
reservation. In the process the qty_done on the stock.move.line will
be loss. We want to avoid this behavior in mrp so we call
_decrease_reserved_quantity from mrp that will keep stock.move.line
with quantity done.
opw-2206472
closesodoo/odoo#47617
X-original-commit: c6cf5841015c87163f8ea16dd75232e5cb855df6
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Adaptation of the code throughout all modules to properly instantiate the newly
refactored control panel and update it accordingly.
Part of task 2196029
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
PURPOSE
Keep consistent behavior of the stat buttons and the different stock
reports when archiving a product
SPECIFICATION
Currently, you can archive a product but the behavior of the different
stock reports, stat buttons isn't coherent afterwards. Here are the
different behaviors that should be improved:
1.Keep quantity on hand and forecasted quantity visible (in the stat
button + when opening it)
2.Automatically (un)archive RR and BOM if the product is (un)archived
3.Valuation report: show the archived products without the "archived"
filter (behaves already this way in the inventory and forecast reports)
4.When a product has been archived and still has quantity in stock,
include it in inventory adjustments for which counted quantity = default
to stock on hand (dont do so for archived exhausted products).
Also, revert #47478 since we don't have active field.
LINKS
Task 2178269
PR #45586Fixes#41634
Related: odoo/upgrade#811
Related: odoo/enterprise#8513
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Allow to propagate custom information to upper document. It could be
usefull in many buisness that do custom stuff for people
(t-shirt with user defined text, poster with own pictures...)
The customes values are pass throught procurements'values and are
display on MO or purchase order line.
Task: 1970476
Make it so documents auto-generated by other actions have Odoobot set as
the creator rather than the user triggering the action. This includes
the following documents:
1. Delivery (stock.picking) - generated by Sales orders (including MTO)
2. Purchase orders - generated by dropshipping, manual replenishment,
and run scheduler
3. Manufacturing orders - generated by made to order (MTO)
This is addresses specification 2 of overall usability improvement task.
Task: 2041853
This commit updates product, stock and manufacturing views for improved
usability. Handles view only changes of overall usability improvement
task. Specifically spec numbers:
1. Add "Run Scheduler" (from stock) to the manufacturing app under operations
5. Make "detailed operations" wizard modal have more intitutive footer
buttons (i.e. don't say "Confirm"/"Cancel" when changes aren't
possible.
8. Rearranging of vendor pricelist view
9. Updating of tooltip content for "property_stock_account_input_categ_id"
Task: 2041853
In this commit,Add a attribut "delete" in mrp workorder gantt view
to disable Remove button on "Planning by Workcenter" gantt view.
task-id:2206166
closesodoo/odoo#47064
X-original-commit: 669408f8b1e760a815e212d9e9fab8663e665dd6
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
For stock, purchase, repair and mrp modules, do a small clean of ACL:
Remove duplication and useless line.
Also improve the readability of the stock traceability report.
task-2172399
closesodoo/odoo#45055
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Create a products A
- Create a products B
Tracked by lot
UoM: kg
- Get some quantity in stock for B
- Create a BOM for A: 2g of B to produce A
- Create a MO for A, Produce
In the lot registration wizard, 2kg of B are suggested instead of 2g of
B.
In this case, the UoM of the product is taken instead of the move.
However, it should only be the case if the product is tracked by unique
S/N.
opw-2200263
closesodoo/odoo#47019
X-original-commit: 9d114eb7a48b82b76e9c900cce22dc5022206367
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Purpose:
Modernizes and facilitates files upload in manufacturing app.
In this Commit:
- Show the image in Kanban.
- Allow to access a preview of the file when clicking on it in the
Kanban view.
- Add a 'Edit', 'Delete' and 'Download' in kanban card dropdown menu.
- Add Upload button in control panel to upload document which will
create new record of `mrp.document` and also add a testcase for it.
task-1960733
closesodoo/odoo#42168
Related: odoo/enterprise#8977
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Steps to reproduce the bug:
- Create a MO
- Click on 'MARK AS TODO'
- Update the quantity to produce
- Produce the MO and click on 'MARK AS DONE'
- Unbuild the MO
Bug:
A traceback was raised because finished_move was not a singleton.
opw:2199529
closesodoo/odoo#46765
X-original-commit: a48573f3089bf78892f90df1dc883a257d047312
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Commit a4c0994 uses variable `qty` as input parameter but override it
at each loop iteration. The original value of `qty` is lost after the
the first pass and so give wrong results for all next iterations.
This commit uses another name to never lose the given value.
closesodoo/odoo#46587
X-original-commit: e1c30bceba6d47d8e087e540f995a02086fa6283
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Purpose
=======
A 'book icon' link to the documentation of a feature has been
added in its settings panel, when it is useful (complex feature).
Add a nightly test that parses all the res_config_settings views
from the base one and checks that all documentation links are still valid.
Add the o_doc_link class to all documentation links to be able to easily
catch them if needed.
closesodoo/odoo#45813
Taskid: 2180574
Related: odoo/enterprise#8601
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- Since 5118d248cc , the action with
id='act_product_mrp_production' was unused.
- Since 85a3e1e385 , the action with
id='action_mrp_unbuild_move_line' was renamed due to duplicate ids
(with action_mrp_unbuild_moves), then remove it (unused) and move
the helper message to the original one.
- Since 81577bf24e , the action with
id='mrp_workcenter_productivity_loss_action' is unused because
the commit remove the menu item using this action
- Since it was integred, the action with
id='mrp_workorder_delta_report' was unused, then remove it.
Co-authored-by: Victor Feyens <vfe@odoo.com>
Steps to reproduce the bug:
- Install Manufacturing
- Go to General Settings/Inventory and tick Units of Measure
- Create a product P (storable) with UOM kg
- Create a Bill of Material for this product: e.g. 1 kg
- Add a component C with UOM "kg", but in the BOM uses "g"
- Create a MO for P, Mark as todo, Produce
- Click on C to change the quantities (e.g. change the first line to 900 g)
- Add a second line with 0.1 kg (as the uom of C is in kg, you are forced to set in kg)
Bug:
The strict consumption check is raised. It happens because the
lines quantity done are not correctly converted in the same
UoM
opw:2181892
closesodoo/odoo#46103
X-original-commit: e385930f8687fc4051ddd375fe0551dba59a8750
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
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>
In case of MTO+Manufacture, a sale order have a count of
manufacturing order created from it :
1. create SO with MFG+MTO product with quantity of 5.
2. confirm it. MO will be created for 5 Nos.
3. increase it to 7 . another MO created for 2 Nos.
4. there are 2 MO created based on 1 SO.
It was due that new stock move was merge, and the
'created_production_id' info was lost during the merge (keep only
the original one). To fix, avoid merging stock move with distinct
'created_production_id' (done by override
'_prepare_merge_moves_distinct_fields' and
'_prepare_merge_move_sort_method' methods ).
task-2199568
closesodoo/odoo#45800
X-original-commit: 1fb32cfd17122b625d211a7d22ec319fba35e87f
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Steps to reproduce the bug:
- Let's consider two companies C1 and C2
- Let's consider two production locations L1 in C1 and L2 in C2
- Let's consider that the company of SUPERUSER is C1
- Add the field Production location in the form view of mrp.production
- Log in C2
- Create a product P with a BOM in C2 with L2 as production location
- Create a MO for P
Bug:
The production location of P was L1 instead L2
PS: related_sudo is set to True by default.
opw:2196707
closesodoo/odoo#45692
X-original-commit: aef3d1864826a939fbd9cfd9b666614169a1db0e
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Commit c883ed1087 let the possibility to
add additional stock moves in a confirmed production. The issue is those
move don't get the production group and their procure method is set
(and never changed) to make_to_stock.
This commit call adjust_procure_method before confirming additional
moves.
closesodoo/odoo#45660
X-original-commit: 96cc10fa79a120172b3cde88d50ba2fda5e75ab5
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Let's say we have a chain of move
wh1 - intercomp transit -> intercomp transit - wh2
The second move will be reserved according to what the first move
brought since they are chained. This behavior resulted in rev[0] which
tries to work around the ir.rule limiting the access of stock.move and
stock.move.line records in multi-company environment.
This patch wasn't perfect since, if the first move brought a lot, the
second move will reserve this lot and it will result in another access
error since the lot will still have the company of the first move.
We fix this by implementing the following logic: receiving from another
company should behave the same as receiving from the supplier, no
reservation is applied. We fix this by marking the inter company transit
as `_should_bypass_reservation` and we break the move chain if the
pull/push rule create an intercompany chain.
[0] 6ff34073153767d449804669f31e26c04de0a670
closesodoo/odoo#45601
Task: 2160847
X-original-commit: 67b45da9d877a5a1bb9adb3ce14051e01f67045f
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Set the following product configuration:
Storable finished product with a flexible BOM made of storable
components in manufacture + MTO:
Component choice 1 Quantity = 0
with BOM made of component 1, quantity 1 with purchase mto route
Component choice 2 Quantity = 0
with BOM made of component 2, quantity 1 with purchase mto route
Create a MO for finished product, set the "to consume" quantity of
"Component choice 1" to 1, and try to mark it as to do. The following
issue is raised: The quantity to produce must be positive!
This is because a procurement with 0 quantity will be solved in a MO
producing 0 quantity. We fix this issue by ignoring procurements with 0
quantities.
Also, this MO without initial demand is not considered assigned. We fix
this issue by considering 0 move as assigned.
task-2159374
closesodoo/odoo#45552
X-original-commit: dffb3a1f2762d6e1517eb9b7d225521f99d874d5
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
VAT, NIF in Spanish, is translated NIT in Spanish from Bolivia
Clean and translate the files with the correct translation.
opw-2197155
closesodoo/odoo#45533
X-original-commit: 641c14f08435b1df1d89184cc00855416bf40bc5
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>
`action_explode` unlinks the kit move and create the stock moves for the components.
As the `create_multi` is not used, it results in lots of delays. Use the `create_multi`.
closesodoo/odoo#45326
X-original-commit: 4818ee61b4f23ab7b388acd2bdd452c27e25fc0d
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
`action_explode` is called when confirming the moves of a picking. It
calls unlink() when the move contains a kit. As this method is not
multi, when confirming 50 kit moves, unlink is called 50 times resulting in
a lot of cache invalidation, prefetching and so on.
We make `action_explode` multi in order to call one time `unlink` per
kit levels.
X-original-commit: 096c682e748f7e581e48f0070ec8a3284d8a2fe7
Usecase to reproduce:
- Create a product MTO manufacture with a BoM
- Set produce delay as 1 day.
- Create a SO for the product and validate
The production order is created but with a duration of 1h.
It's due to commit 8944674d6d
It will use the moves finished date in order to determine the MO
finished date. However before this commit during _run_manufacture
the MO was created with a fix finished date and the move finished
date_expected was created with this date as date_expected.
Now the MO is created with the finished date, the inverse does
nothing since the finished moves do not exist yet.
In order to fix it, generate move_finished_ids use the product/company
manufacture delay. A first patch tried to rewrite date_planned_finished
after action_confirm. However it triggers the propagate date on
following moves.
closesodoo/odoo#44532
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Usecase to reproduce:
- Create a product with 10 days manufacture lead time
- Create a procurement in order to fullfill a need the 01/15
The MO start date is the 01/05 that's the expected values
The MO finished date is the 01/05, 1 h later than the start date
It happens due to commit 92aeaa47ff
This commit modified the wrong start date in order to take the
procurement date - manufacturing lead time. However it also
modified the finished date to 'the start date + 1h'. That returns
the problem to the opposite direction. Now the finished moves have
a wrong planning.
Fix it by using the production + company lead days when it's set
instead of 1h.
opw-2181962
X-original-commit: 6a5ce8de91d3ab2cb7f73127a6ee1c11578ccef9
Issue
- Install MRP
- MO > Import with BOM
The lines are not populated but it
was the case in v12.
Cause
In 7206b385b5, the lines generation
are done in a onchange but they are
not trigerred in imports
Solution
Call the onchange manually when we
are in an import case
OPW-2188066
closesodoo/odoo#45118
X-original-commit: 26c44fae1ad8a3ac2d79d9673255aef12fddeb17
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
svs-odoo