Community counterpart of the enterprise commit having the same name.
This commit acts as a setup to allow for the reworked gantt view to work
properly.
Task Id: 3105022
Part-of: odoo/odoo#110819
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
In the inventory menu, the "Operations" menu has now three sub items:
- Transfers
- Adjustments
- Procurement
All the existing `menuitem` go now under one of these sections.
Also, for the old transfers menu itme, this commit replaces it by three
other menu items: "Receipts", "Deliveries" and "Internal Transfers".
Each of them will display only the transfers with the matching picking's
type (depending of the picking type's code).
When a picking is created from there, its picking type will be set by
default according to it and the field will be filtered by its code.
When `mrp` is installed, adds a menu item for the manufacturing
operations in "Transfers" submenu too.
task-3076044
Part-of: odoo/odoo#109511
Usecase to reproduce:
- Set the warehouse as 3 steps receipt
- Put a security delay of 3 days for purchase
- Set a product with a vendor and 1 days as LT
- Replenish with the orderpoint
You expect to have a schedule date for tomorrow that contains all the
product needed in the incoming 4 days.
Currenly the internal transfer from QC -> Stock is for tomorrow (ok).
The transfer from Inpur -> QC is plan for 2 days in the past. (not ok)
The PO date is plan for 5 days in the past. (not ok)
It happens because the system check at each `stock.rule` application if
purchase is part of the route. If it's then it applies the security lead
time. It's a mistake because we should apply it only the first time.
To fix it we directly set it when the orderpoint run and not during
`stock.move` creation.
However for MTO it's not that easy. We don't want to deliver too
early the customer. So we keep applying the delay during the
`stock.move` creation but only when it goes under the warehouse stock
location.
X-original-commit: 97f52bd40d97109a7983549d252476959ddceada
Part-of: odoo/odoo#112325
Before this commit, the reserve/unreserve buttons did not work / were
hidden with multi-step delivery settings. The report now works with the
entire linked chain of moves, it displays which step is reserved,
if more than one is reserved in the chain the later move is shown.
Because reservation works differently on chained moves (they reserve
quantities brought by previous move in the chain) any extra unreservable
quantities are shown as on stock in transit.
closesodoo/odoo#112162
Taskid: 2858139
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This commit removes the legacy implementation of the form, kanban
and list views. It also removes the legacy view widget registry,
and all legacy widgets it contained. The legacy field registry
couldn't be removed yet as some fields are still used (e.g. in
client actions: FieldMany2One, FieldMany2ManyTags...), and
sometimes accessed from that registry (e.g. uom service). More
clean up will come later. Note that all tests using legacy views
have thus been removed, even though the tested feature might still
remain (e.g. FieldMany2One tests have been removed, but that field
is still there). However, those features are deprecated and
unlikely to evolve. They should be removed in the next saas, or the
one after.
Finally, this commit also removes the legacy view dialogs.
Task 3168640
Part-of: odoo/odoo#111809
Refactoring of report_stock_forecasted to owl
Since it wasn't really a report (no print action),
it changed from a report to a client action.
Task: 2885757
See Upgrade : odoo/upgrade#3926
See Enterprise : odoo/enterprise#32116closesodoo/odoo#101247
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When auto-fill the duration of workorders in immediate production, the
workorder cost is not included in the price of the product.
It happens becuase we calculate the price in _post_inventory but we set
the duration after _post_inventory. To fix, we set the duration of the
workorders in before _post_inventory.
closesodoo/odoo#111898
X-original-commit: 707769478b9f63319689ff2347d300ce1800d1d0
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
before this commit, the precision given for the field product_qty in mrp.bom model is Unit of Measure, which is not existing by default in Odoo decimal precisions.
after this commit, precision will be updated to default Product Unit of Measure precision
closesodoo/odoo#111115
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This is mostly a cleaning/refactoring change.
The current API for init hooks (pre, post, uninstall) is to pass
`cr, registry`.
But the first thing which was done by most
post init and uninstall hooks was to create an env using
the cr passed
e.g.
`env = api.Environment(cr, SUPERUSER_ID, {})`
and the `registry` argument was unused in all these hooks,
completely.
By changing the API of hooks to pass `env` instead
of `cr, registry`, we gain in average two lines in every
hooks:
- the line creating the env `env = api.Environment(cr, SUPERUSER_ID, {})`
- the line importing `api` and `SUPERUSER_ID`
Therefore removing ~250 lines of repeated code lines accross odoo/odoo and
odoo/enterprise.
In addition to these lines removed,
it also ease the API of init hooks for Odoo developers,
who are used to that `env` and not so much how to create an `env`
from a cursor.
Part-of: odoo/odoo#108254
Necessary for odoo/enterprise#35867
Steps to reproduce:
- Install Quality, Manufacturing
- Manufacturing > Settings > Enable Work Orders
- Manufacturing Orders > Create order for Table > Confirm > Work orders
tab > Open Tablet View
- Get to step 'Please encode the table legs lot number'
- Change the quantity to produce
- Pause > Continue
Issue:
The quantity to produce is reset to 4/4 Units.
Solution:
Check if the workorder is paused before applying `qty_done` changes.
opw-3032052
closesodoo/odoo#111402
X-original-commit: 4acb1781c5aedc011ba00054285f64963aa0dacc
Related: odoo/enterprise#36491
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Stefan-Calin Crainiciuc (stcc) <stcc@odoo.com>
When opening a work order and the quantity_producing is set at 0 by default, and since it is not possible to record 0 as done, the user always gets an error message when trying to carry on without manually editing that quantity producing field. This is not very user friendly as a manual input there on any device is burdensome.
This fix automatically sets qty_producing to be equal to qty_remaining in workorders for non-unique serial products when opening a workorder if the quantity is zero.
task 3113153
closesodoo/odoo#111156
X-original-commit: ff96659e7f8d4a239ff641d1b3541226ae3cb9e5
Related: odoo/enterprise#36369
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Diez Stéphane (snd) <snd@odoo.com>
This PR addresses a bug introduced in odoo/odoo/pull/109776
The user can indeed modify the timer, but because a started timer is a readonly field,
the timer does not update.
Using isDirty allows to check if the user really modified the timer.
closesodoo/odoo#111064
X-original-commit: 9aa8752da18ed679d7ddae93682c045204083104
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”:
- Variant: Color: Black and white
- BOM 1:
- product variant: P1 - White
- Type: Kit
- Consumable: C1
- BOM 2:
- product variant: P1 - Black
- Type: Kit
- Consumable: C1
- Create another kit product “P2” without variants
- Create an SO:
- Add “P1 - white”, “P1 - black”, “P2”
- Confirm the SO
- Go to the delivery → validate it Print the delivery slip
Problem:
only product "P2" is displayed in the report.
The `product_id.name` is used as `move.name`:
https://github.com/odoo/odoo/blob/16.0/addons/sale_stock/models/sale_order_line.py#L333
but then only compare it with the name of the `product_template` set in
the bill of material to filter the moves.
Solution:
Check if the `move.name` is equal to the `product_id.display_name`
set in the bill of materialale au product_id set dans la bill of
material.
opw-3051639
opw-3047822
closesodoo/odoo#110837
X-original-commit: eae5cf84625f8155bc72b63eaed28819698810cf
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This commit fixes the traceback when the user push the start button
in the Work Order list View of a work order without a date_planned_start.
To recreate the traceback, the order must be based on a manufacturing order
with multiple work orders, with at least one with a scheduled start date and
one without a scheduled start date.
When creating the manufacturing order, it is important to make sure that
only the confirm button is pressed.
closesodoo/odoo#110587
X-original-commit: c4d16a57e03d2a9183b232344579978b839a9fb9
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Since the conversion of the list view to owl, the relative field size
has not been reimplemented. We have decided not to support it anymore.
So we will remove all its uses.
The relative width consists in adding a width attribute with a
value. This value corresponds to the weight of the field, the higher
it is, the more space the field will take. This size is only used when
the list is empty.
Example of this:
<tree>
<field ... width="2">
<field ... width="1">
</tree>
The first field will take 2x more space than the first one when the list
is empty.
closesodoo/odoo#110382
Related: odoo/documentation#3375
Related: odoo/enterprise#36020
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since 5b68871097, the scrollable menu of
the picking type kanban card (`kanban-menu`) is the mrp one even for
stock picking type. The inherited view replace the template without
testing the picking type code as it was done before.
This commit adds a `t-if` for stock picking types and another for mrp
one to makes sure the two template are mutually exclusives
closesodoo/odoo#110412
X-original-commit: c7f49d1381ab1bf3dd7ed42436d0c881d7bab27d
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- Create an attribute with "Variant Creation Mode" = Dynamically
- In a product template, add the attributes and some values
- Create a new BoM for this product
- Click on "Stucture&Cost" smart button
Problem:
A traceback is raise, because the `_match_all_variant_values` function
is called but without the product, while it takes at least one:
https://github.com/odoo/odoo/blob/15.0/addons/mrp/models/mrp_bom.py# L456
https://github.com/odoo/odoo/blob/15.0/addons/mrp/models/product.py#L286
As the variant creation mode is set “dynamically”, the object must be a
`product.template` model and not `product.product` so the first
condition should be `True` and return a `false` value:
https://github.com/odoo/odoo/blob/5c16aa22c70f8a0a377a55b912307ab07222c643/addons/mrp/models/mrp_bom.py#L453-L454
Therefore, if the product has no variant, we have to use the
`product_template` and set it in the `_get_bom` function, but from this
commit:
odoo@ca3dfec
If there is no variant product, the template is no longer set:
odoo@ca3dfec#diff-e8f576a790cd7f3f0976358b9b07f63cee0c6f05b0ba6203fc7bcf91af3ad283L107
The change in this commit from line 107 to line 118 is useless because
it does not change any behavior and does not improve the code, the only
change is that the product_template is no longer set. So it makes sense
to revert this part of change
opw-3008838
closesodoo/odoo#110341
X-original-commit: 1d830b5080e4d05dc1ac6fbd4c435af532443f88
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This PR addresses a bug where the user tries to update the real duration of a work order in the list view.
The timer was updated in the backend (so the update was showing when refreshing the page) but not in the front
The problem was the following : the state was never updated in the widget
closesodoo/odoo#110132
X-original-commit: 42bb1ac5195b614de4de674c47864abab79a5082
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
RATIONALE
Purpose of this commit is to cleanup main post helpers and have a more easy
and understandable way of calling them.
SUMMARY
We now have two main API methods, based on business flow: either posting
on documents, either sending a mass mailing. Indeed those two flows are
different
* post: create message, then launch notification process by taking into
account subtype, followers, ...
* mail: create mails in batch with recipients being based on template or
given partners. No notifications is involved, only maybe traces if a
mass mailing is linked
Delegate QWeb rendering to the render mixin (i.e. _render_template_qweb_view)
in order to have a single point to forge evaluation context and re-use
existing rendering code.
SPECIFICATIONS
Main API helpers are now
* ``message_post_with_source``: (batch) post on records, using an ir.ui.view
(given a record or its xml id) or a mail.template record (given a record or
its xml id). When using a template, a composer is called to post on each
record (as batch post is not yet supported). When using a view, a direct
call to message_post using the rendered bodies is done, one record at a
time.
* ``message_mail_with_source``: send a mass mailing on records, acting like
invoking the mail composer in mass mode. Same arguments are valid, either
a reference to a view, either a reference to a mail template.
Other helpers are
* ``_message_log_with_view``: (batch) log on records, using an ir.ui.view
to render the body using QWeb (no notification process);
* ``_message_log(_batch)``: (batch) log on records (no notification process);
* ``message_notify``: notify partners on records (creating notifications
specifically for some people while message itself is not displayed in
chatter);
Code migration
* ``message_post_with_template`` in "mass mode": use ``message_mail_with_source``
and set the template record as source;
* ``message_post_with_template`` in "comment" mode: use ``message_post_with_source``
and set the template record as source;
* ``message_post_with_view``: its main usage was to post on a document, in which
case it generally can be replaced by ``message_mail_with_source`` using
the view reference as source;
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
RATIONALE
Purpose of this commit is to be explicit in subtype chosen when invoking the
message composer / calling message_post. As default value may not always be
clear, better be explicit in case the composer default value changes.
SPECIFICATIONS
Add explicit references to subtype when it is not obvious what will be the
final subtype, notably when using helpers (post_with_view or template which
uses the composer that is not crystal clear in its subtype management).
In this commit we also add support of XMLID-based subtype when invoking the
composer. A ``default_subtype_xmlid`` context key is transformed into a
``default_subtype_id``, to be used notably in JS where we cannot easily
use a ``ref``-like statement. Post API now also supports 'subytpe_xmlid'
argument allowing to give the xml id and ease calling the methods.
Use ``_xmlid_to_res_id`` to get directly the ID of subtypes in order to
avoid useless queries from ``ref`` that does an exists.
Also remove useless values given to post API, notably author_id that is by
default the current users' partner.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
When changing quantities of raw moves after MO confirm,
procurement is run to fulfill updated need.
Since procurement creates new moves, some fixes were also done to allow
moves to be merged with older ones, including:
1) `date_planned_start` of merged MO included microsecond which
blocked merging new moves created by procurement with orig moves.
Removed microseconds.
2) `_set_date_deadline` did not allow a simple date update to moves with
orig or dest moves. Added context to hard set all moves in self to specific
deadline.
3) `_update_candidate_moves_list` when merging moves, did not return candidates
from pickings that were merged to same MO. Usually just mattered when decreasing
quantity. Added explicit check for sibling pickings in MO
closesodoo/odoo#93712
Task: 2859547
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When redirecting the SML of byproducts, the capacity constraints of
the locations are not considered.
To reproduce the issue:
1. In Settings, enable:
- By-Products
- Storage Locations
- Storage Categories
2. Create three storable products P01, P02, P_comp
3. Create a storage category SG:
- Max Weight: 1000
- Capacity by Products:
- 2 x P02
4. Create two locations L01, L02:
- Parent Location: WH/Stock
- Storage Category: SG
5. Create a putaway rule:
- From: WH/Stock
- Product: P02
- To: WH/Stock
- Having Category: SG
6. Create a BoM:
- Product: P01
- Components: 1 x P_compo
- By-products: 1 x P02
7. Update on hand qty of P02:
- 1 x P02 at L01
8. Create and confirm a MO with 2 x P01
9. Set the producing qty to 2
10. Open the detailed operations of P02
Error: The destination location is L01, this would break the
capacity constraint. The location should be L02
When setting the producing qty, we also set the done quantities of
the finished moves and we redirect them thanks to the putaway rules:
https://github.com/odoo/odoo/blob/cc6e31efe6fdd9dee16de1565afe9e1b502de45d/addons/stock/models/stock_move.py#L1885-L1888
However, the SML created only has the `qty_done` defined and, when
applying the putaway rules, we consider the `product_uom_qty` which
is equal to 0 in such a case.
So, when trying to redirect the SML of P02, we check if the capacity
constraint of L01 would be exceeded with the quantity of the SML.
But, as explained above, that quantity will be 0, so we conclude
that the capacity constraint is ok and we return L01 as best solution.
This is the reason why this commit suggests the use of the maximum
between done quantity and reserved quantity. This logic is already
used in the putaway application process, when we check the forecasted
quantity by location:
https://github.com/odoo/odoo/blob/a217ba27600c64c9104f8c1f003afd74ad06bd05/addons/stock/models/stock_location.py#L297-L301
OPW-3100322
closesodoo/odoo#109669
X-original-commit: 4ee8f974f993d2bbea7d9fc00779ebb1c1fa047d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Before this commit, the byproduct and putaway feature do not work
together. More specifically, changing the quantity to produce on a
manufacturing order will create automatically a byproduct move line (or
update the existing one with the new quantity) but never look for a
putaway rule to apply.
This commit makes use of `_set_quantity_done()` method on `stock.move`
that *do* call the putaway strategy mechanism
X-original-commit: d4a968412e68cc9da3ec2d9725caa90830287c48
Part-of: odoo/odoo#109669
When you don't have any mrp access rights and want to open a product
template form view, you get an access error. This is caused by the field
bom_count that tries to count the number of BOM without having the
access rights.
So we only add this field to the view, and the action that depends on it
when you have mrp access rights.
closesodoo/odoo#109636
X-original-commit: a655276d556f1d2bf92c3f3160a8306cc673a115
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
- Many ui/text updates
- Fix To consume field display
- Add Draft/Done filters to Scrap views
- Fix BoM name_create problems due to _rec_name set to product_tmpl_id
Task: 3094741
Part-of: odoo/odoo#108446
in sale_mrp module, the method `get_sale_order_count` get all stock move
with created_production_id = the current production order. Without
index, this request is significantly slow.
X-original-commit: 4c17020fb452f639d9395dccdd5fcefee109ed01
Part-of: odoo/odoo#109201
This commit separate the templates, one for the card and another one for
the menu (the ellipsis dropdown).
The new template, called 'kanban-menu', will only contain the dropdown.
Note that, this behaviour is the same as the one used for the kanban
tooltips.
closesodoo/odoo#107589
Task-id: 3096776
Related: odoo/documentation#3284
Related: odoo/enterprise#34962
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Reproduction:
1. Install Sale, Inventory
2. Go to Sale->products, search for “Customizable Desk”
3. Hover the cursor on the stat button “Sold”, from its definition, the
analysis should show the sold items in last 365 days
4. Click on the “Sold” button, no filter for “Order Date”
Reason: in V14, the “time_ranges” feature is removed. Thus using it in
the context won’t create any filter for searching
Fix: We use a custom filter to replace the time range "last_365_days".
We also make sure that the domain produced by that filter is the same as
the one used to compute the button count server side (this was not the
case in Odoo 13 when "last_365_days" was used). Similar fix is also done
in mrp and l10n_ar. Mind the utc convert for correct results.
opw-3000595
Related commits:
Removal of time_ranges: https://github.com/odoo-dev/odoo/commit/be5a51a345b8986da0e19627260f64f984e11ae9
Date filter fix: https://github.com/odoo/enterprise/pull/10938closesodoo/odoo#108951
X-original-commit: 03057029b210a59f3d7012aeea66cfa95790a8c8
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Liu Jinjiu (jili) <jili@odoo.com>
In the BoM Overview, routes were always displayed regardless of the
display options selected in the filter. Since lead times are only
relevant when checking their associated routes (as they determine them),
it makes sense to add the display of the routes in the lead times
filter.
closesodoo/odoo#108808
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce the bug:
- Enable “Multi-Step Routes” option in the inventory settings
- Create a storable product “P1” with BoM:
- Add any Component
- Go to “Miscellaneous” tab
- Create a new picking type and set in the “Operation” tab
- Create a Mo:
- Add the product “P1”
- Select the created BoM
- Go to “Miscellaneous” tab
Problem:
The operation type set on BoM does not update when selecting the BoM
on a manufacturing order
opw-3091436
closesodoo/odoo#108632
X-original-commit: cd561574d044d4799163ac90305c7914855ead50
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Before this commit, if a user changes a MO move qty to 0
and then tries to change the MO qty to produce, an error occurs.
The move with 0 qty is no longer cancelled or unlinked as this was not
the intenteded behavior.
Since the change production wizard no longer deletes cancelled moves
a test was updated accordingly.
closesodoo/odoo#108534
Taskid: 3082611
X-original-commit: 39abadb30dc8fab6b2a1ca24cb2916ab148fb5fa
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Ahmed Khalaf <ahkh@odoo.com>
When a kit template has several variants, the on hand quantity can be
incorrect.
To reproduce the issue:
1. Create two products P_compo, P_kit:
- P_kit:
- Storable
- Variants:
- Color (White, Black)
- P_compo:
- Storable
2. Update the on hand quantity of P_compo: 10
3. Create two BoMs:
- BoM01:
- Product: P_kit
- Variant: Black
- Type: Kit
- Components: 1 x P_compo
- BoM02:
- Product: P_kit
- Variant: White
- Type: Kit
- Components: 2 x P_compo
4. Open the form view of the template P_kit
Error: it displays "15 units on hand", which is impossible (there are
only 10 P_compo available)
Since it is difficult to determine the expected value, a decision has
been made: hide these smart buttons if a template has more than one
variant and if at least one of the variants is a kit.
OPW-2645299
OPW-2678400
OPW-3076502
closesodoo/odoo#108284
X-original-commit: cf3b83d6a48c080d900d9cf343e4012be718c79d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Since 2515482d5a70, the duration expected of a workorder was always set
to the real duration at the validation of the workorder. This commit
ensure the duration expected is left unchanged even if the
date_planned_finished is updated.
closesodoo/odoo#108233
X-original-commit: 46e1ae4d9918de1aaf6b4a7565dba422b03fcb36
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
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>
Steps to reproduce the bug:
- Create a BoM with components
- Archive one of the components
Problem:
No warning is displayed for the user to inform that the product is
used as a component in a BoM
opw-3089104
closesodoo/odoo#107863
X-original-commit: 9b7c416387d93507b6f750aba58ad6233a59d512
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- install “mrp_mps”
- Create a storable product “P1”
- routes: Manufacture + MTO
- make sure there is no BoM set
- Go to “Master Production Schedule”:
- Add the product “P1”
- Add a quantity and click on “Replenish”
Problem:
A User Error is triggered with the following message: `The unit of
measure Units defined on the order line doesn't belong to the same
category as the unit of measure False defined on the product. Please
correct the unit of measure defined on the order line or on the product,
they should belong to the same category.`
The `compute_qauntity` function is called to convert the qty into the
UoM of the BoM, but since there is no bom, an empty record is given as
a parameter:
https://github.com/odoo/odoo/blob/8c5fb8b71538462422c8f166b772b5e316ecd6b5/addons/mrp/models/stock_rule.py#L122https://github.com/odoo/odoo/blob/0f91970020af640faa3a06369fa888315f83f98f/addons/uom/models/uom_uom.py#L215
opw-3085227
closesodoo/odoo#107476
X-original-commit: 7d0df9035cf603ed25ef88a3cf99ed89aef6771e
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
To reproduce:
Create a MO without product_id, then add a new line in work orders.
Error raises.
Since cab8d8fe7f744fb4dd0cd61b624f6f4519eb8d8d, we started to show
qty_remaining of WO on MO form. It triggered the compute function of
qty_remaining. Since we don't set product_id, production_id.product_uom_id
is not provided when doing the calculation.
To fix, add production_id.product_uom_id as dependancy of qty_remaining,
and don't do the calculation without it.
opw-3092723
closesodoo/odoo#107434
X-original-commit: 0b10241c0bcbecda73dae04c8a5f1ceb8033a388
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
Incorrect variable reference + calculation for unit BoM cost for
byproduct/product (to produce) within in BoM overview report. This
was leading to the displayed value having the cost_share being multipled
into the unit cost twice.
Steps to reproduce:
- create component with cost 100
- create BoM with 1 of this component + 1 byproduct with
qty = 2 and cost_share = 50.00
- click on Overview
result before this commit:
Manufactured Product unit cost = 25.00
Byproduct unit cost = 12.50
actual result should be:
Manufactured Product unit cost = 50.00
Byproduct unit cost = 25.00
closesodoo/odoo#107410
X-original-commit: 2339bed170b5f670b1f5a6cebd533a9cee72d4db
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
This commit changes popover widget such that instead of altering the
popover component during app lifecycle to make dynamic
popover templates, use `t-call` to call template passed in props.
closesodoo/odoo#107286
X-original-commit: f1a9de85c19a53c9516cac44de6cbaf53d850842
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Just change double the by single. This fixes various typos in error and
code comments.
closesodoo/odoo#107266
X-original-commit: 09dfedfc19c2bc34c2bb394dcc4bc609c5ac0107
Related: odoo/enterprise#34681
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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>
Since fixes done on the bom overview had to be done in a released
version, no method signature changes could be done, hence the use of
excessive context keys to bypass it.
Changes the signatures so that future work is done on better grounds,
and so that each method explicitely asks for what parameters it needs to
do its work.
closesodoo/odoo#107006
Related: odoo/enterprise#34577
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Previously, _intervals_duration (called by _compute_duration)
sometimes loose the last mrp.workcenter.productivity.
A fix has been made.
First, mrp.workcenter.productivity.loss _convert_to_duration
calculates according to the loss type, we have to take that in account.
Second, mrp.workcenter.productivity _close badly generates
performance timers.
For example, test_mrp_employee_analytic_account generated
- productive for 1st employee from 10:00 to 11:00
- performance for 2nd employee from 10:00 to 11:00
- performance for 2nd employee from 11:00 to 11:00 (! duration = 0)
Now, the timers are
- productive for 1st employee from 10:00 to 11:00
- productive for 2nd employee from 10:00 to 11:00
which is correct.
closesodoo/odoo#106908
Task: 2985735
X-original-commit: 8638ec145ab83e4afafa39a5c9e987e8d772bfd1
Related: odoo/enterprise#34533
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Jean-François Aubert <ajf@odoo.com>
