Prior to this commit, the layout of the settings in the kanban card was
broken
closesodoo/odoo#107895
X-original-commit: 922029c2197145d555b65becd7210c4d7a13d439
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The aim of this commit is to simplify and standardize the settings archs.
To do this, a small DSL exclusively for the settings was created. This
new DSL introduces 3 tags: `app`, `block` and `setting`.
The `app` tag is used to declare the application on the settings view.
It creates an entry with its logo on the sidebar of the view. It also
acts as delimiter when searching.
```xml
<app string="CRM" name="crm">
...
</app>
```
- `string` : The "display" name of the application.
- `name` : The technical name of the application (the name of the module).
- `logo` *optional* : The relative path to the logo. If not set, the
logo is created using the `name` parameter :
`/{name}/static/description/icon.png`.
The `block` tag is used to declare a group of settings. This group can
have a title and a description/help.
```xml
<block title="Title of group Bar">
...
</block>
```
- `title` *optional* : The title of the block of settings (the old h2),
you can perform research on its text.
- `help` *optional* : The description/help of the block of settings
(the old h3), you can perform research on its text.
The `setting` tag is used to declare the setting itself. The first field
in the setting is used as the main field (optional). This field is
placed on the left panel (if it's a boolean field) or on the top of the
right panel (otherwise). The field is also used to create the setting
label if a `string` is not defined. The `setting` tag can also contain
more elements (e.g. html), all of these elements are rendered in the
right panel.
```xml
<setting string="this is bar">
<field name="bar"/>
...More elements
</setting>
```
- `type` *optional* : By default, a setting is visually separated on two
panels (left and right), and is used to edit a given field. By
defining `type='header'`, a special kind of setting is rendered
instead. This setting is used to modify the scope of the other
settings. For example, on the website application, this setting
is used to indicate to which website the other settings apply.
The header setting is visually represented as a yellow banner on
the top of the screen.
- `string` *optional* : The text used as label of the setting. If it's
not defined, the first field is used as label.
- `title` *optional* : The text used as tooltip.
- `help` *optional* : The help/description of the setting. This text is
displayed just below the setting label (with classname
`text-muted`).
- `company_dependent` *optional* : If this attribute is set to "1" an
icon is displayed next to the setting label to explicit that
this setting is company-specific.
- `documentation` *optional* : If this attribute is set, an icon is
added next to the setting label, this icon is a link to the
documentation. Note that you can use relative or absolute path.
The relative path is relative to
`https://www.odoo.com/documentation/server_version`, so it's not
necessary to hard-code the server version on the arch anymore.
closesodoo/odoo#106425
Task-id: 3081367
Related: odoo/enterprise#34337
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: "Michael Mattiello (mcm)" <mcm@odoo.com>
mrp
===
- no time has been recorded on operations then give warning with apply button
- do not allow to mass edit UOM in any manufacturing state
- set value of lot/serial from MO and set read only on unbuild from MO
- remove "archive operation" icon
repair
======
Currently it is not possible to select a return on a repair order unless save it first. so after this commit user can able to select it without save it.
only show picking related to selected product
closesodoo/odoo#106571
Task: 2845380
X-original-commit: dd60647ce41547ecd00bbde45ddf564a7ada91c7
Related: odoo/enterprise#34403
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Issue: In the MO view, the src location for components was editable and
the dest location for byproducts was editable when neither of these
should be.
Due to the same field appearing twice in the same x2many field list,
there were 2 issues:
1. something changed (probably during OWL refactoring) that made it so
the 2nd invisible field instance of the field was overriding the
"readonly='1'" property of the 1st instance when it was in the view
(i.e. when multi-locations is active) [in previous versions this did
not happen]
2. because of the change by https://github.com/odoo/odoo/commit/168cbe66bee7824bdf389de5c6c680342e27bc6d
we ensure that these two required fields are always correctly set (to
the MO's values as per the default when multi-loc is active) when the
MO's moves are created.
Part of general bugfix task: 2985735
closesodoo/odoo#106542
X-original-commit: 1bb2c44d32e669a9b936da90cbd80721b2c897ef
Related: odoo/enterprise#34396
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
When manualy create a productivity log on the workorder form, you are
always asked to choose a time_id(productivity). But by default, the
field is hidden. Make this field shown by default for better use
exprience.
closesodoo/odoo#106007
X-original-commit: 84cde486c700420c8898847342f158393c02649c
Related: odoo/enterprise#34098
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
When the mrp_routing_workcenter table is big, the domain
[routing_line_ids, =, []] in the workcenter FormView can
lead to significant slowness. This comes from
the ORM having to retrieve the mrp_routing_workcenter
records in the read.
To avoid such issue, adds a new boolean computed field
to check if a given workcenter has Operations.
opw-2954461
closesodoo/odoo#99313
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
- set monetary widget to align foat field with other monetary fields
- use default production order in the list view to have the same order
everywhere.
Task: 2991906
X-original-commit: 38b82230b75f972a7da5d4c53ea1a4c7359cd913
Part-of: odoo/odoo#103055
Since odoo/odoo#95729
nodes with a `groups=` are completely removed from the views when
the user is not part of the group, instead of being made invisible.
In that PR, views have been adapted to add back fields, with invisible="1",
when they were required, for instance when they were used in a domain
of another field which was still there despite the user is not part
of the given group.
As `tree` views having `multi_edit="1"` where not considered
as editable views, the domain of fields in these views were not
validated:
- https://github.com/odoo/odoo/blob/1fb8fa16ab7dc298d54f089d7163fb556dbc5fcc/odoo/addons/base/models/ir_ui_view.py#L1460
- https://github.com/odoo/odoo/blob/1fb8fa16ab7dc298d54f089d7163fb556dbc5fcc/odoo/addons/base/models/ir_ui_view.py#L1321-L1322
while they are well required for the web client,
in `multi_edit="1"` this is possible to edit relational/many2one field,
and therefore it will do `name_search` calls using the domain of the
field, and therefore the fields used in these domains must always
be present in the views. Without it, a crash in the web client occurs
when attempting to edit the relational/many2one field.
This revision targets to consider the `multi_edit="1"` tree views
as editable, to make the field domains validated as they should be.
Hence, views are adapted to add back fields with `invisible="1"`
when they are required in domains of other fields.
Part-of: odoo/odoo#103790
Before this commit, in the mrp_production form view, the quantity items
were spread out.
After this commit, they are closer together.
closesodoo/odoo#102582
X-original-commit: 3aa74fd15ed951974485fadd6a362fdaf374b202
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
The status badge on workorder kanban card was hidden behind a dropdown
widget because of a wrongly used class.
X-original-commit: 491546a5c3ce6203763a7d829b44107e66ff3f42
Part-of: odoo/odoo#102398
When creating a MO with some WO from a mobile, the quality checks are
not created
To reproduce the issue:
(Need quality_control)
1. Create two storable products P_compo, P_finished
2. Create a BoM:
- Product: P_finished
- Components: 1 x P_compo
- Operations: create a new operation OP
3. Add a step to OP:
- Type: Pass - Fail
4. Switch into mobile mode
5. Create a MO for 1 x P_finished
6. Confirm it
7. Open the WO
Error: the tablet view skipped the pass-fail step, the user can already
mark the MO as done and close it
When confirming the MO, it leads to the quality checks creation. To do
so, we iterate on the `quality_point_ids` of the WO to generate these
quality checks:
https://github.com/odoo/enterprise/blob/7ff0f43df777027bf8544be3ac95e76feb7da957/mrp_workorder/models/mrp_workorder.py#L406
But, the WO has not any quality point, which is incorrect: it should
have the one related to the step created on the operation P. This field
is a computed one and is based on the quality points defined on the
operation linked to the WO:
https://github.com/odoo/enterprise/blob/7ff0f43df777027bf8544be3ac95e76feb7da957/mrp_workorder/models/mrp_workorder.py#L70-L73
But again, there is an issue: the WO has not any defined operation
(which is incorrect, it should be linked to OP). And this is because of
the WO creation from the kanban view: the field `operation_id` is
missing so it is not defined during the WO creation.
OPW-2984037
closesodoo/odoo#101346
X-original-commit: 751f1253d4a32491d210aceb4767084088c314ad
Signed-off-by: Adrien Widart <awt@odoo.com>
With the change to 'always edit' on form views by default, several
'oe_read_only' fields had to be modified to play nice with the fact
that in most cases, there is no read_only mode
closesodoo/odoo#101188
X-original-commit: 868992abeeda983768323e1126b5643eff8fdb33
Related: odoo/enterprise#31810
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Added an option on Manufacturing Operation Type
This option allow auto-consumption up to the reserved
quantity of tracked components in manufacturing orders.
Task : 2950200
Enterprise PR : odoo/enterprise#30805closesodoo/odoo#98461
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce:
- install the mrp_plm module (Product Lifecycle Management app);
- create a product with a long name;
- create a bill of material for that product;
- create a manufacturing order and select that bill of material;
- confirm the manufacturing order.
Issue:
The value of the bill of material field overflows into the second column.
Cause:
There is a problem in the use of classes in the .xml file (o_row and d-flex).
Solution:
Change the classes used (Bootstrap and Odoo classes) to have the correct rendering.
opw-2966863
closesodoo/odoo#100305
X-original-commit: 7a7c6870a2006edab8ffe62c016e5eb0681a46f8
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Create analytic accounting entries for employee times logs on workorder.
Compute BoM costs based on employee hourly cost and employee number
required on mrp operations.
closesodoo/odoo#91565
Task: 2427466
Related: odoo/enterprise#23032
Related: odoo/upgrade#3556
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This patch is part of a complete rework of the workorder tablet view and general
work order processing experience. It's mainly done in the Enterprise
repo. In community: the changes are the follows:
- The workorder kanban view remodeled
- Prepare workorder productivity timer to work with employee
Task: 2427466
Part-of: odoo/odoo#91565
This views has multiple custom features such as file upload, attachment
viewer and download.
A lot of files have been rendered obsolete and have been deleted,
notably `file_upload_mixin` which has been replaced by the
file_upload service and hooks.
closesodoo/odoo#99769
Related: odoo/enterprise#31145
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- 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
- 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>
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
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>
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>
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
Purpose of this commit to fix the UI in Manufacture app.
So, in this commit done following changes As suggested in Task:
- Able to expand next activity column of MO list view
- Added tooltip of default capacity field on work center
- Added quantity tooltip of BOM
TaskID - 2689994
closesodoo/odoo#95315
X-original-commit: 463a81eb325f624e8947f1b3444947f8ba1dc24b
Related: odoo/enterprise#29113
Signed-off-by: Tiffany Chang <tic@odoo.com>
For bugfix purposes, app administration groups have been given to
(implied by) the "Settings" group because without those rights,
opening/saving the settings crashed.
1) Do not load hidden view content
This commit uses the conditional inheritance of views
(depending on user groups) to avoid loading unnecessary view
& record content client-side.
This improves performance for admins without the specific application
admin rights, but also fixes the main bugfix problem,
caused by the webclient querying name_get for the records in relational
fields content.
Example:
sale_management adds a res.config.settings field to specify
the default sale.order.template for the current company.
If a 'Settings' user without 'sale.group_sale_manager' opens the
settings, he won't see this setting, but if a default template is
specified for the current company, the webclient will still request
the name_get of this template to the server, because the field
was present in the view, only hidden with a groups attribute.
With this commit change in sale, the field won't be in the view unless
you have the Sale manager group, avoiding the error/traceback/bug.
2) Remove implied application administration groups
Do not force the specific application groups on all 'Settings' user,
they globally do not need those rights, and if they need it, they
can add it to their account themselves.
3) Add a test to make sure settings user are able to manage settings.
4) Enforce 'settings' -> 'access rights' -> 'internal user' groups
As the previous test highlighted some 'false positives' because
it considered a settings user unable to read `crm.team`
and `stock.warehouse` records, we also took the opportunity to enforce
the fact that 'Settings' & 'Access rights' users must be internal users.
It makes no sense for a portal/public user to have access to the
settings, and didn't work anyway.
Part-of: odoo/odoo#91909
Currently MRP only allows sequential scheduling of work orders.
This commit allows to specify the dependencies for work orders to be
scheduled in parallel or in a complex diagram.
By enabling the feature in the settings and at the bom level,
you can specify dependencies between operations:
on the operation form, select the operations on which the
current one depends.
The dependencies will be reflected in work orders during planning.
The workorders Gantt view has been adapted for you to visualize
and manipulate the dependencies.
Please note:
- work orders without predecessors will be started first
- they can all be done in parallel
- when all work orders of this step are finished, their successors
will start
- and so on, step by step
Also, with the feature activated at the bom level and no dependency,
the parallel scheme will be applied (all operations at first step).
Finally, without activation at the bom level, the dependencies will
be created in order to satisfy the current sequential model.
Task: 2691328
Part-of: odoo/odoo#87131
When manfacture in 2 steps is setup on warehouse, transfers are created
when confirming an MO, manual moves added did not have a warehouse and thus not
included in the picking. The default warehouse is set to the source location
warehouse in MO.
closesodoo/odoo#91879
Related: odoo/enterprise#27577
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
- Add the concept of 'Days to Prepare MO' in mrp, similar to 'Days to
Purchase' but defined at the product level. Both concepts are merged into
Days to Order at the orderpoint level, taking the value of Days to Purchase
for orderpoints with a buy route and Days to Prepare MO for orderpoint with a
manufacturing route.
- Add the concept of 'Visibility Days' on orderpoints. The idea is to
avoid to create through reordering rules multiple small orders for the
same product on a small time frame but rather to order directly a bigger
quantity. When Visibility Days are defined, the quantity of the orders
created by a RR is not the quantity forecasted at Today + Lead times
(quantity that triggered the order according to the RR), but the
quantity forecasted at Today + Lead Times + Visibility days.
The Visibility Days are different for purchase and manufacturing.
Changing the route of the orderpoint will change its value. They
can be defined at the company level and further fine-tuned on the
orderpoint. In case of change of the parameters at the company level,
only orderpoints without a specific value of Visibility Days will
be changed.
- Alignement between Manufacturing and Purchase Security Lead Time
(previously the Manufacturing Security Lead time didn't impact the
procurement date, instead the manufacturing time was made longer).
closesodoo/odoo#86682
Task-id: 2738838
Pr: https://github.com/odoo/odoo/pull/86682
Related: odoo/upgrade#3415
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Morgane (morm)