- Add columns setup/cleanup time to Specific Capatities of Workcenter
- Take into account these 2 fields when compute expected duration in WO
task-2925474
Part-of: odoo/odoo#97588
Auto mark manual_consumption as True as soon as the component is use in
an operation and make the field read-only
task-2925474
Part-of: odoo/odoo#97588
The commit modifies the following:
- add tooltip : 'Displays the consumed Lot/Serial Numbers consumed.'
- Change the column Serial Numbers to also display lot number
- Make the column read-only
task-2925474
Part-of: odoo/odoo#97588
Currently, the kanban view show qty_production. However, the Listview
show the qty_remaining. So this commit match the field for 2 views (both
should show qty_remaining)
task-2925474
Part-of: odoo/odoo#97588
When mass producing from several reserved lots, we display a warning
message that the lot reservation is 'multiple'. This commit displays
that message in red.
task-2925474
Part-of: odoo/odoo#97588
Since d7716f071d, the onchanges to create the stock moves in mrp
production have been replaced by computes.
There was a hack in the create() method to trigger the onchanges in case
of import. As those onchanges do not exist anymore, this hack needs to
be remove too.
The compute methods are called naturally in imports.
closesodoo/odoo#99434
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This commit fixes two bugs:
1) Wrong source location
Before this commit:
- Source location is incorrect after merging MOs and 3-step manufacturing is selected.
- Operation type is incorrect after merging MOs
After this commit:
- Set the source location from the correct picking_type's value while merging MO.
- Set the Operation type for the merged MO to be the same as the original MOs';
2) Traceback when splitting mo
Before this commit:
- When splitting a MO without a "responsible user" set then boom it's throwing traceback
After this commit:
- The "responsible user" is no longer required which matches the existing MO behavior
TaskID - 2754217
closesodoo/odoo#99374
X-original-commit: 67e3f2f66aeb1aa1a93ad5091af7c0375f6d9a93
Signed-off-by: Tiffany Chang <tic@odoo.com>
Steps to reproduce:
- Manufacturing app > Operations > Manufacturing orders > Create
- Set product to [FURN_7800] Desk Combination > Save > Confirm
- Click on scrap, choose any product > Done
- Edit the manufacturing order > set the quantity to 1/1 > Save
An error pops up: You cannot change the UoM for a stock move that has
been set to 'Done'.
This happens because the scrapped product has its destination location
wrongly set to the production location of the manufacturing order.
Because of this, it is considered as a component of the manufacturing
order. The scrap is also confirmed right after creation, so its state
is set to 'done'. Finally, when confirming a manufacturing order, all
of its component moves are also confirmed, hence the error.
This commit prevents the override of the scrap's destination location,
so that it is not wrongly considered a component anymore.
The commit also adds tests for the override method, added in
commit 0b247ab17ccc5be0c2058ef92ccf3502c97e0bb3
opw-2945182
closesodoo/odoo#99218
X-original-commit: 81820d4df5f23d9b6b2701e513ada89b528a865a
Signed-off-by: Adrien Widart <awt@odoo.com>
The move line form view is too technical for the average user so instead we
can to auto-magically open the reference document instead (picking or MO
only for now).
We do the same with stock valuation layers as well, but this feature
will not be available until its custom JS is converted to OWL
"product moves" part of b2b task: 2882539
closesodoo/odoo#97109
Related: odoo/enterprise#29974
Related: odoo/upgrade#3819
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
- reorder/rename/remove menu contents for "Inventory" and "Reporting",
including:
- removed "Forecasted Inventory" menuitem since this view is no longer
considered useful (code for view to be removed in separate commit)
- removed "Stock Moves" (moves report) menuitem
- renamed "Product Move" (move lines report) menuitem => "Moves
History", this will also be reflected in any "History" buttons that
open this view from other views.
- made "Inventory Report" menuitem visible only when applicable (i.e.
multi-location or consignment is active/debug mpde)
- made "Run Scheduler" menuitem only available in debug mode (
main_flow_tour updated to skip scheduler click since general flow is
expected to still the same/work)
Goal of renaming/ordering of menuitems is to clean them up and make them
more intuitive for users.
- "Run Scheduler" in mrp menus has also been made debug only viewable as
well to mirror the inventory change.
"menu" part of b2b task: 2882539
ENT PR: odoo/enterprise#29974
Part-of: odoo/odoo#97109
The goal of this revision is to get rid of the `groups_id` field of the model `ir.ui.view`.
- This feature wasn't really known or used by most developers,
and not straight-forward to understand.
Removing it allows one less complicated thing to learn for developers.
Besides, thanks to odoo/odoo#95729,
changing the behavior of the `groups=` attribute,
we can easily get rid of this `groups_id` feature
by simply adding `groups=` in the elements of the views
using the `groups_id` field, it will have the same effect:
adding the elements in the view only for the users part of the specified group.
- By getting rid of the groups_id many2many field on ir.ui.view,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the groups_id groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
Part-of: odoo/odoo#98551
Since the new Overview report can compute the lead days and availability
delays from a BoM and all of its components and/or subassemblies, we can
use this data to compute the days that would be required to resupply all
components from a BoM.
So we add a button to compute it directly on the product form.
Task-2628323
Part-of: odoo/odoo#93194
Changes "Structure & Cost" report to "Overview", as the goal for this
report is improved.
The point is to have on a single report all components and sub-assemblies
that make it up, in parallel with the route and lead times associated to
each. This way it becomes easier to identify issues, such as:
- Missing routes.
- Longer lead times on a specific sub-assembly.
- Unavailable component in the foreseable future.
- ...
Also did the conversion to OWL, changing drastically the structure of
the report.
Task-2628323
Part-of: odoo/odoo#93194
The legacy field MrpFieldOne2ManyWithCopy added a control create
that performed an action when clicked.
In the new listRenderer we have added the possibility to define control
action buttons. So it is no longer necessary to create a custom field
for this use case.
Part-of: odoo/odoo#97558
This revision is to make uniform the behavior of the `groups` attribute
on the Python model fields
and on the node in the view architecture.
In both cases, remove the node from the view completely.
Before this revision,
in a back-end view:
- In the Python model, if a field has the `groups` attribute set
and the user is not part of
the groups, the field is removed, completely, from the view.
- In the view architecture, if a node has the `groups` attribute set
and the user is not part of
the groups, the node is made invisible (not completely removed, just
made invisible).
in a front-end view:
- if a node has a "groups" or "t-groups" set and the user
is not part of the groups, the node is removed from the view.
So it's 2/3 cases removing nodes restricted to a group.
and 1/3 case making invisible nodes restricted to a group.
It's simpler to have a uniform behavior for the 3 cases,
simpler to understandard for developers.
In addition, this will help for the goal to cache back-end views.
It makes possible to convert views using the `groups_id` field
by moving the content of these views directly
in the view to which they add content which is suppose to be completely
removed when the user has not the according group.
By getting rid of the `groups_id` many2many field on `ir.ui.view`,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the `groups_id` groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
closesodoo/odoo#95729
Related: odoo/enterprise#29592
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Purpose
======
When creating a specific Operation Type of type 'Manufacture' the default
operation type is not the correct one on object creation.
So in this commit, we set default `Operation Type` in picking when Type of
Operation is `Manufacture`.
taskID - 2939078
closesodoo/odoo#98145
X-original-commit: b28c44a38698018ebbbc420f6567c17b2b97c279
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- Go to Inventory→ Configuration→ Warehouse Management →Operations Types
- Go inside “Receipts”, and enable the checkbox “Create New Lots/Serial
Numbers for Components” and `Use Existing Lots/Serial Numbers`under the
traceability section
- Create a receipt transfers with a traceable product
- Mark as to do the transfer
- Try to add a SN for the product
Problem:
Traceback is triggered: “key error: raw_material_production_id”
because we use this field to add it in the context from the parent in
the `stock.move.line` view:
https://github.com/odoo/odoo/blob/15.0/addons/mrp/views/stock_move_views .xml#L53
But this field is not present in all views of the `stock.move` model
Solution:
To avoid adding this field in all the `stock.move` views, it is better
to add it in the context from the `python` code
closesodoo/odoo#98110
X-original-commit: 545713ae0a559e7f2747dd3cb4211ab752e1ef0c
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Steps to reproduce:
- Inventory app > Settings > enable barcode scanner
- Manufacturing app > Create a new manufacturing order
- Under components, add a product that has a barcode
- Save > Print > Production order
The barcodes of the products on the report all encode the
same (incorrect) value, which is the manufacturing order name.
This commit changes the barcode value to the corresponding
barcode string of the products.
opw-2930848
closesodoo/odoo#97968
X-original-commit: 71d4d977d42e69e8e3d7e069098707b84812ee07
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: stcc-odoo <stcc@odoo.com>
Installing mrp on a large database will take lots of time computing the
unit_factor of stock_moves created in stock. As this value is only
needed in mrp, this commit bypass the computation for moves that have
been generated before the mrp installation
closesodoo/odoo#97750
Task: 2918852
X-original-commit: a2f064446b1e232efc3e6924879f63b79e0bc986
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Part of the overall v16 SCSS optimization/restyle, task-2704984.
task-2896849
closesodoo/odoo#94767
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This commit improves the design and removes unnecessary SCSS.
Part of the overall v16 SCSS optimization/restyle, task-2704984.
task-2896849
Part-of: odoo/odoo#94767
* commons & setup refactoring:
* convert setUp to setUpClass
* move setups where needed (stock/mrp commons or specific test
classes)
* create test data in batch (faster, less sql queries & batched
operations)
* move most tests post-install to allow runbot splits
* by default, run tests without mail logic
* by default, run tests in a consistent environment (fixed currency
imposed in the BaseCommon)
* refactor existing tests to use new commons data (while trying to keep
diff reduced)
* add dedicated test file to test the common data
* use mute_logger to reduce useless test logs (less spam to scroll in
logs, less data on runbot builds, ...)
Part-of: odoo/odoo#96791
The render API was confusing as mixing the access to the report and
the rendering env.
The ambiguity was present for code such as
`report.sudo()._render(record_ids)` where it was not clear if the
`sudo()` is needed to access to `report` or to `record_ids`. For low
priviledge users (such as portal or public), it was common to use
`report.with_user(SUPERUSER_ID)._render(record_ids)`.
This PR changes the render methods signature to be `api.model`. The
`report_ref` can be:
- ir.actions.report external id
- ir.actions.report id
- ir.actions.report recod
- `report_name` value
This will allow to call the report methods with any user and no longer
need to use `with_user(1)` to render reports as public user.
Task-id 2670865
closesodoo/odoo#91341
Related: odoo/upgrade#3650
Related: odoo/enterprise#27323
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”:
- routes:
- MTO
- Manufacturing
- Create a SO:
- Select the product “P1”
- Confirm the SO
Problem:
The created MO is in confirmed state instead of draft.
This blocks the user, for example imagine that he has configured
the product with a first BOM without components and 2 others with
components. when the MO is created, the first bom will be selected,
and as the MO will be confirmed, the user will not be able to
select another BOM
Solution:
Since the MTO rule is not linked to an order point, we could be more
flexible, so the production created via `_run_manufacture()` without
bom or with a bom without component and operation via the MTO mechanism
will not be confirmed
opw-2897267
closesodoo/odoo#97099
X-original-commit: c623478aba040c0493e6da8a67c9742880572199
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Steps to reproduce the bug:
- Go to Inventory→ Configuration→ Warehouse Management →Operations Types
- Go inside “Manufacturing”, and disable the checkbox
“Create New Lots/Serial Numbers for Components” under the traceability
section
- create a MO with a traceable component
- Confirm the MO
Problem:
You can create a new SN for the component without any warning,
while the user is supposed to be blocked by a user error:
https://github.com/odoo/odoo/blob/master/addons/mrp/models/stock_lot.py#L11-L16
The solution:
We need to add the `active_mo_id` key in the context so that the user
error will be triggered
opw-2900256
closesodoo/odoo#96648
X-original-commit: 6d0ddc388d1c389e1911a6bb1c59c252870da1a7
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
On the commit 69dcdd4, the order='create_date desc'
was removed and the way of getting the MO for the notification changed. Now, the context is used, it should be written_after instead of written_date.
(The MO created is correct, only the notification is wrong)
OPW-2877457
closesodoo/odoo#96856
X-original-commit: b80287b265a4c01babedcbb58459c35d36a48066
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- Enable 'Multi-Step Routes' option in Inventory settings
- Edit warehouse and update Manufacture = 'Pick components, manufacture and then store products (3 steps)'
- Create a storable product 'P1' with BOM:
- BOM type: Manufacture this product
- operations: “OP1”
- Components: product 'C1' consumed in the operation 'OP1'
- Set Reordering rules for product 'P1'
- Run Scheduler and MO will be generated with order points
- Edit MO and add Producing Quantity less than to produce
- Validate the MO and create backorder.
Current behaviour:
- child/parent MO were getting visible when backorder was created in 2/3 Step Production.
Expected behaviour:
- No child/parent MO visible until child/parent relations are there
closesodoo/odoo#96533
Task: 2846768
X-original-commit: 14431b2497dcf4aaf778ef1b06e023101b00a4e2
Signed-off-by: Tiffany Chang <tic@odoo.com>
_split_productions wrongly compute duration expected for backorders.
Setting quantity on production adapt many things including workorders,
so adapt original production after copy_data for backorders.
closesodoo/odoo#96179
Task: 2884562
X-original-commit: 71b8531881ff6924762ec34db3f2ddf858383218
Signed-off-by: Tiffany Chang <tic@odoo.com>
When creating a new manufacturing order with `move_finished_ids`
passed in the values, but `byproduct_id` is not amongst the move values,
the creation of the manufacturing crashed.
```
File "/home/odoo/src/odoo/master/addons/mrp/models/mrp_production.py", line 811, in create
vals['move_finished_ids'] = list(filter(lambda move: move[2]['byproduct_id'] is False, vals['move_finished_ids']))
File "/home/odoo/src/odoo/master/addons/mrp/models/mrp_production.py", line 811, in <lambda>
vals['move_finished_ids'] = list(filter(lambda move: move[2]['byproduct_id'] is False, vals['move_finished_ids']))
KeyError: 'byproduct_id'
```
By reading the implementation of the byproduct moves field:
```py
@api.depends('move_finished_ids')
def _compute_move_byproduct_ids(self):
for order in self:
order.move_byproduct_ids = order.move_finished_ids.filtered(lambda m: m.product_id != order.product_id)
```
it seems a better implementation to filter the move on the fact their
product is different than the manufacturing order to determine whether
they are byproduct or finished product moves.
Take the opportunity to write a unit test testing the tricky behavior
of the create override when both `move_finished_ids` and `move_byproduct_ids`
are passed in the create values.
This is related to revision
odoo/odoo@6c087f2043closesodoo/odoo#96044
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”
- Tracking: by serial number
- BOM:
- Component: C1
- Create a storable product “P2”
- BOM:
- Component: P1
- Create a MO to produce one unit of P1:
- serial number: SN1
- Confirm and mark as done
- Unbuild the manufactured product
- Manufacture the same product using the same serial number again
- Create a new MO to produce one unit of “P2”:
- Component P1 → select SN1
- Try to confirm and validate the MO
Problem:
Get User Error: The serial number “SN1” used for component “P1”
has already been consumed
We do a search in the `stock.move.line` to find if the SN has already
been used in a previous MO, but there is no specific condition to get
only those used in an MO so the unbuild order is in the same condition
and therefore the SN is considered as it has already been used
opw-2883450
closesodoo/odoo#95935
X-original-commit: 5ac7f4d6fa5551ba7c6da49a52edf0a7df2d0745
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Stpes to reproduce the bug:
- Create a storable product “P1”:
- tracking: Serial number
- BOM: 1 unit of C1
- Create the MO 1:
- produce 1 unit of P1:
- Create the SN1
- Create the MO 2:
- produce 1 unit of P1:
- Create the SN2
- Create an Unbuild order:
- Select the MO1
Problem:
You have the possibility to select any Serial number linked
to the product “P1”, whereas only SNs created in this MO can be selected
opw-2834529
closesodoo/odoo#95956
X-original-commit: 167b1668450c5af44bc1d36d1c7d59921bc2b811
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
This allows to create a mrp.unbuild record without
the need to call the onchanges to set the uom and locations
or to set them manually during the `create` call.
For instance, this makes easier to create unbuild orders
using XMLRPC when you do not use multiple UOMs or multiple locations.
closesodoo/odoo#95557
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
With this revision, the expected duration is correctly set
when creating a production order with work orders without the need of
onchanges, through a form.
For instance, this allows an easier implementation to create a production
order with work orders through XMLRPC API calls,
as you will not need to manually set the expected duration value
or to call onchanges manually to set it.
For instance, without this change to remove the `default=60.0`,
the part added by this revision in the test `test_update_quantity_3`
would fail
```
2022-07-11 09:15:14,644 21 ERROR master odoo.addons.mrp.tests.test_order: FAIL: TestMrpOrder.test_update_quantity_3
Traceback (most recent call last):
File "/home/odoo/src/odoo/master/addons/mrp/tests/test_order.py", line 347, in test_update_quantity_3
self.assertEqual(production.workorder_ids.duration_expected, 90)
AssertionError: 60.0 != 90
```
while it just does the same thing than the existing `test_update_quantity_3` test
but without the use of a form / onchanges.
Part-of: odoo/odoo#95733
This allows to create a production order record without
the need to call the onchanges to set the product, uom or bom
or to set them manually during the `create` call.
For instance, this makes easier to create production orders
using XMLRPC when you do not use multiple UOMs.
closesodoo/odoo#95544
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
In the web client, in a real use case, it's not possible
to write on fields which are invisible,
as it's not possible to write on fields which are readonly.
This is a first step in the goal to change the behavior
of the `groups=` attribute in the back-end views,
to remove them for the view instead of making them invisible.
This is mainly to reduce the diff of the revision that will introduce
the mentioned above behavior change.
As nodes with `groups=` will be removed from the view
when the user doesn't have the group, it's no longer possible
to set a value on a field having a `groups=` the user doesn't have
in the `Form` test class, as the field will no longer be at all in the
view.
However, these unit tests shouldn't have been able to set values
on invisible fields in the first place.
This revision therefore aims to correct the unit tests setting value
on fields which were invisible because the user executing the
test was not part of the required group(s) for these fields
to be visible in the view.
closesodoo/odoo#94337
Related: odoo/enterprise#28936
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Currently, when a BOM is archived via the ECO mechanism, its operations are
still selectable via the `copy existing operation` action on the BOM.
In this commit, we have added domain in `copy existing operation` action.
TaskID - 2845022
closesodoo/odoo#95548
X-original-commit: 272cd5358e8b78bc273d4aa72b8c42649f1f5171
Signed-off-by: Tiffany Chang <tic@odoo.com>
> Media query mixins parameters have changed for a more logical approach
> media-breakpoint-down() uses the breakpoint itself instead of the next
> breakpoint (e.g., media-breakpoint-down(lg) instead of
> media-breakpoint-down(md) targets viewports smaller than lg).
> Similarly, the second parameter in media-breakpoint-between() also
> uses the breakpoint itself instead of the next breakpoint (e.g.,
> media-between(sm, lg) instead of media-breakpoint-between(sm, md)
> targets viewports between sm and lg).
https://getbootstrap.com/docs/5.1/migration/#sass
Task ID: 2766483
Part-of: odoo/odoo#95450
From [1]:
> Dropped all .badge-* color classes for background utilities
> (e.g., use .bg-primary instead of .badge-primary).
We now have to manage constrast for some badge. It's why we
add 'text-dark' at some point.
Note:
Due to the backport of 'text-bg-#{theme}', we can use this to
avoid to use 'text-dark'.
Ref:
[1] https://getbootstrap.com/docs/5.1/migration/#badges
Task ID: 2766483
Part-of: odoo/odoo#95450
Convert the onchange on `product_id` to a compute field
This allows to create a `mrp.bom.byproduct` record without
the need to specify the uom during the creation nor calling the onchange
method. The uom defaults from the product uom.
This way, if the database is not configured to use multi UOMs,
the users do not have the specify the UOM to use.
For instance during an XMLRPC call to create a byproduct.
closesodoo/odoo#95270
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Rewrite _find_delivery_ids_by_lot to reduce the number
of recursive calls by grouping the producing move lines
together before each recursive calls. This reduces
the number of search calls, speeding up the whole method.
Add a unittest to check if the delivery_ids field
of a lot recordset is properly computed.
opw-2824464
X-original-commit: e7b9f14d4a9ce4ed61451b24b567f751fb4bcbe2
Part-of: odoo/odoo#95398
Triet Ngo