Before this commit, owl was in the linter's accepted global variables.
This allowed direct access to owl global object.
For instance, to use xml from owl, you could do :
`const { xml } = owl;`
or you could use it directly:
`owl.xml`
Now, owl is not accepted on linter's global variables anymore, so to
import xml, now you need to use a proper import:
`import { xml } from "@odoo/owl";`
task-id 3498859
closesodoo/odoo#137517
Related: odoo/enterprise#48364
Related: odoo/design-themes#709
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Steps to reproduce:
- Create a two-layers Bill of Material (BoM and child BoM).
- Create a Manufacturing Order with the top-level BoM and open the
Overview.
- Click 'Unfold', then hit the 'Replenish' button on the component.
- Select 'Manufacture' as preferred route and confirm.
Issue:
The newly created Manufacturing Order is correctly added in the report
but already unfolded, which can greatly change the visibility of the
report if it has lots of components.
This is due to an `undefined` value in the ComponentsBlock fold indexes
as they were not updated after the new props update.
closesodoo/odoo#137613
X-original-commit: 9dc2425dc69c1797cb85ecd794019ea44c541334
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Steps to reproduce:
- Create a component C (automated/FIFO)
- Create and confirm two PO for C
qty: 1, price: 10
qty: 1, price: 20
- Make an MO with C as a component
- Unbuild that MO
Bug:
The valuation of the new component C is wrong, the new move in is valued
at the current product cost instead of its original value.
Fix:
create moves as a return to get the correct value
opw-3379457
closesodoo/odoo#137353
X-original-commit: d42238cc75fe6621c1eb893395856870c8bfbafb
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Before this commit
==================
Currently, when we try to modify the BoM Overview report from the studio then
it's return traceback.
Steps to produce
================
- Install Manufacturing(`mrp`) and Studio(`web_studio`)
- Now open Manufacturing and click on the studio icon
- click on the reports button and select BoM Overview report
- Now you can see the traceback
After this commit
=================
With this commit, no more errors occur when we try to modify reports from the studio.
closesodoo/odoo#137175
X-original-commit: 00785e729ab3aaf650102c0ca8b14f9855744574
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Bhavin Patel (bat) <bat@odoo.com>
This reverts commit 656d8ace87.
The rational was: "If people don't have inventory, they will need a
backorder anyway and it's logical to not display the popup even
if the picking type has 'ask' for create backorder".
Also for the barcode application in OE we only show the reserved lines and
you could have the message if the picking was not fully reserve. Even if
you completed all the lines. So we could have a single flow for backend
and frontend.
But it's difficult for poeple to understand that the backorder is
base on the reservation and not on the initial demand. So we do a
step back. On top of it, people usualy won't mix flow. So they
could totaly use the "always create a BO" option on picking type
when they use the barcode and "ask" when they use the backend.
closesodoo/odoo#136725
X-original-commit: ed291c4d47783c5912ffb40db7893c321ccdb1e2
Related: odoo/enterprise#47959
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Previous fixodoo/odoo#131279 missed marking component lines added in
from the consumption warning wizard as "additional". This made it so the
added line was also added into the backorder when it should NOT have
been (since the backorder should only be based on the original MO's
values).
Followup of task: 3456604
closesodoo/odoo#136728
X-original-commit: 7a45b691781e2862e87da7914a8b3b9a6487b7e9
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Steps to reproduce:
As Admin:
1. Create a Storable product with a Route of Manufacture
2. Create a re-ordering rule for this product.
3. As a user with no MRP access rights, create a sale order with this
product and confirm the sale order.
This creates a new `mrp.production` record with `sudo()` on line
\#85: https://github.com/odoo/odoo/blob/fae59cee91969692c2375b3bd37e914ec0fb606e/addons/mrp/models/stock_rule.py#L85
4. Duplicate sale order and try to confirm again.
This produces an access right error because the first loop finds the
existing `mrp.production` record and tries to create a
`change.production.qty` record.
However, the user doesn't have access rights so they get an error.
Solution:
Add `sudo` to the create call.
opw-3508819
closesodoo/odoo#136640
X-original-commit: c5758e122db5396e23a57826a1b12ed7d9765f55
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Andrew Gavgavian (andg) <andg@odoo.com>
Commit 4da8c6ebca change the way the
detailled operation of a stock move is openned. This has been done only
for the picking. This commit adapts the
MrpProductionComponentsX2ManyField widget to act also as the stock move
widget used in the stock pickings.
Part-of: odoo/odoo#136067
In 6698406b92a598f24fa0a778a28b6ef727adc008, we removed action
mrp.mrp_production_report. action_view_mos still using this action, we
change it to use mrp.mrp_production_action instead.
closesodoo/odoo#136382
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
When adding a new raw SM to a confirmed and locked MO, it should still
be possible for the user to define the to-consume quantity (else, he
would have to unlock the MO and only then to edit the new line)
OPW-3253204
closesodoo/odoo#136009
X-original-commit: b78c468317079ac415d7b1fdbd4d4d081ff3976b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Since the new model (PR: odoo/odoo#114024), updating a record no longer
triggers a deep render and therefore no longer triggers the onWillUpdateProps
for Field components.
The goal of this commit is to adapt the usage of onWillUpdateProps
in Field composents in order to fix the bugs introduced by the RelationalModel
closesodoo/odoo#135842
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In DocumentViewer, we need to generate google slide urls.
In this commit, we're going to create the getGoogleSlideUrl utility that
generates a google slide url.
closesodoo/odoo#135851
Related: odoo/enterprise#47573
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In this viewtiverse, the heroes remove the context dependencies for
`get_views`, from the views and python fields (such as domain). To reduce
inconsistencies and the number of rpc.
Current issues:
* There may be inconsistencies in views at the JavaScript level. Some
overrides modify the behavior of get_views or domains on fields via
context keys, therefore by changing the action, the rendering may be
different. However, these views are cached. However, the cache key
(Javascript) does not reflect the entire context, and requires additional
post-processing from the server.
* Multiple rpc for the same rendering. get_views being dependent on the
context, as soon as it changes, a new rpc is performed. In most cases,
when JavaScript needs the same view, there is no change depending on the
context, the rpc is useless.
* Inconsistency when rendering subviews, some views could be different
depending on the context, this context can be modified in the view itself
via the context attributes. However, the JavaScript client does not redo
an rpc for each change of these sub-contexts. Therefore the result may be
inconsistent.
Solution:
Limit as much as possible the number of context keys provided when calling
get_views, and use the context provided as a cache key. The authorized
keys are 'lang' and '*_view_ref'. For the cache key, options are added in
the get_views method.
Instead of using the context, it is inserted into python expressions.
This will be evaluated by JavaScript and thus avoids inconsistencies.
task-3414108
task-3414068
closesodoo/odoo#135145
Related: odoo/enterprise#47584
Signed-off-by: Raphael Collet <rco@odoo.com>
added a contextual action to call action_plan_with_components_availability()
if each component line of a production order has a forecast_expected_date,
the date_start of the production order will be the latest forecasted date
task 3395161
Part-of: odoo/odoo#129933
Previous fixodoo/odoo#121602 did not correctly handle the case when not
all of the qty to manufacture is manufactured (the qtys to change to
were miscalculated in this case).
Additionally, it missed fixing a few more use cases when setting the
qtys to match the wizard's lines/qtys:
- if the UoM of a MO's component line is changed => the correct qty was
not correctly converted into the move.product_uom's qty (now it is)
- if a component's move is deleted before the MO is confirmed => the
move (i.e. the missing component) was not correctly added back into
the MO (now it is)
- if there are 2 MO component moves with the same product => both were
set to the same "correct qty" value (now we only set the first move to
that qty, others are set to 0 since we have no way of knowing how to
distribute the qtys otherwise)
Also, since an UserError needed to be added in case of a missing comp
move for a tracked product, existing error logic has been updated to
list all applicable products and the message has been improved to be
more helpful.
Note that the fix for saas-16.4 and earlier is slightly different from
this fix due to the change in how stock move original demand qtys no
longer change like they used to (see: odoo/odoo#130342) and because a
backorder bug was also exposed by this change.
closesodoo/odoo#135796
Task: 3456604
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
In order to reduce the amount of RPCs in the detailed operation view.
The two wizards to populate the stock move line one2many with lot/serial
number to create are replaced with twos Owl dialogs.
only one RPCs is done to generate the stock move lines values from
either a serial number + a count or a list of lots name
Task : 3256447
Part-of: odoo/odoo#124409
This commit replaces the opening of the stock moves detailed operation
wizard by the one2Many record preview. This means creating a move in a
picking is still done via a new line but the edition is done via the
`fa-list` button that open the record in the web client. The goal is to
reduce the RPCs call as much as possible. The stock move lines data are
stored in the stock move record until the picking save.
Additionally, this commit change a bit the immediate transfers flows.
The stock move show only initial demand (`product_uom_qty`) but the
column wording is still "Done". In the detailed operation view, the
stock move line `qty_done` is displayed as "Reserved".
At picking validation, the user is expected to enter the same quantity
in `product_uom_qty` and `quantity_done`. If `product_uom_qty` is equals
to 0, the done quantity is used as actual transfer quantity. If
`product_uom_qty` is different than 0 but small than the done quantity,
an error is raised.
Task: 3256447
Part-of: odoo/odoo#124409
Commit 167c51b1f9 makes `use_create_lots`
and 'use_exisitng_lots` computed fields in MRP module but did not mark
them as `readonly=False`. Thus, they were readonly by default for any
picking types.
Also, make sure new reception picking type have their `use_create_lots`
set to True and delivery picking type their `use_existing_lots` set to
True.
closesodoo/odoo#135900
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1” with BoM:
- Add a tracked component
- Add another component (no tracked)
- Create a MO to produce 1 unit of the product "P1":
- Confirm
- Unlock the MO
- Set the "to consume" quantity of the tracked component to 0.
- Try to validate the MO
Problem:
A user error is triggered: “You need to supply Lot/Serial Number for
products:”
Solution:
If the quantity to consume is 0, ignore the serial number verification
for this move.
opw-3471256
closesodoo/odoo#135657
X-original-commit: 5e591cf36cdc6dcbdb8a5ee3753247578a771e9f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
If a subassembly was used as component in a finished good and both the
subassembly and finished good were unbuilt, the subassembly could not be
produced again with the same serial (specific use case: medical hardware
refurbishment, medical device is produced/packaged (subassembly), put as
a component into a procedure pack (finished good), both are returned and
unbuilt so the medical device can be refurbished and produced/packaged
again into a subassembly with the same serial).
The _is_finished_sn_already_produced function duplicates domain was
wrongly picking up stock move lines related to the unbuild of the
finished good, making the function wrongly returning True. This fixes
the search domain and adds a test to prevent regression.
closesodoo/odoo#135716
X-original-commit: 4f07b260807053586ac6c01cf92ac3d5e37b1041
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
`_set_dates` didn't work properly with multiple records.
In fact, it only used the `date_start` and `date_finished` of the
first record. The assumption was that `date_start`/`date_finished`
is always the same for each record in self, because it usually
comes from a write call (writing the same values to a batch of
records). But inverse methods are also called by the create
method, and then the previous assumption isn't true anymore.
This bug leads to several inconsistencies between the `date_start`
and the `leave_id`. The `test_replan_mo_without_bom` was fixed in
the previous version, but with the new onchange, it breaks again
because of these inconsistencies.
closesodoo/odoo#135635
Signed-off-by: Raphael Collet <rco@odoo.com>
The 'sale_ebay' module adds the `product_variant_ids` one2many field on
the `product.template` form view. The `product_variant_ids` view
contains `virtual_available` (depending on `uom_id`). When the user
changes the `uom_id` of the `product.template`, onchange is triggered,
it takes a snapshot of the previous data, and it will computes the
previous value of `virtual_available`. But the associated compute
method will fail with a traceback:
File "/data/build/odoo/addons/stock/models/product.py", line 199, in _compute_quantities_dict
res[product_id]['qty_available'] = float_round(qty_available, precision_rounding=rounding)
File "/data/build/odoo/odoo/tools/float_utils.py", line 54, in float_round
rounding_factor = _float_check_precision(precision_digits=precision_digits,
File "/data/build/odoo/odoo/tools/float_utils.py", line 29, in _float_check_precision
assert precision_rounding is None or precision_rounding > 0,\
AssertionError: precision_rounding must be positive, got 0.0
The `precision_rounding` is `0.0` because the `uom_id` of the product is
empty. It is is empty because we force the `uom_id` of the
`product.template` to be `False` in `initial_values` (before the
snapshot), and then the `uom_id` takes the value of its
`product.template` (`False`). But actually, the cache of the product
should be full with its previous values before doing the snapshot.
This was not the case because we only copy data from store fields
(see `fnames`). Then compute fields was computed after setting field
change to `False`.
opw-3334822
opw-3419392
X-original-commit: 5021e77ba52fac465a5d842ac04c0a3a22aea2dd
Part-of: odoo/odoo#135635
Co-authored-by: William Henrotin (whe) <whe@odoo.com>
Fix the issue when update the bom on a draft MO, the product_qty and
product_uom_id will be reseted to 1.0 unit.
The original product_qty and product_uom_id hould be kept when update
bom.
X-original-commit: f1a397ede16c56db3410fd9c5fe387dc98c46422
Part-of: odoo/odoo#135691
Legacy code still use 'onchange' on the 'stock.picking.type' field code
to compute the different xxx_location_id.
As it is no more viable, this commit replace all these onchange by
compute methods.
These changes also has a side effect as some already existing compute
methods now get a set of 'stock.picking.type' in input, such that these
methods are also updated to handle this case.
closesodoo/odoo#134650
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce:
- Create and confirm an MO with extra components in stock
- Update the quantity to produce
Bug:
the reserved qty is not updated (it actually is but to the previous
value if you update MO quantity multiple times)
since this commit[1] moves are now assigned during the write
before the new product_uom_qty is written on them
opw-3489226
[1]:https://github.com/odoo/odoo/pull/93712closesodoo/odoo#135548
X-original-commit: cc23ebefb4a15d163ec508cd535bf757cf626fa5
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Before this commit
==================
Currently, There is no way to know how many qty users can produce with the current stock.
After this commit
=================
With this commit, In the MO Overview report, the following stages are added:
'Ready', 'Not Ready', and '{X} Ready'. the Ready to Produce qty is based on
the component reserved quantity + component free quantity. Furthermore, the
table header in the MO status overview report has been slightly highlighted for
improved visibility.
task-3356499
closesodoo/odoo#124474
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
* = account, base_iban, bus, calendar, crm_livechat, hr, hr_holidays,
im_livechat, mrp, project, sms, snailmail, test_mail,
test_mail_full, web, website_livechat, website_slides
Add support in `contains` for most operations that we use in tests.
Remove return value from `contains`.
Move into `web` module.
Remove import/export chains, directly import from correct module.
closesodoo/odoo#134652
Related: odoo/enterprise#47064
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to Reproduce the Bug:
- Create a storable product "P1" with 2 Bills of Materials:
- BoM 1:
- Component: C1
- BoM 2:
- Component: C2
- Create a MO:
- Select BoM 1.
- Save.
- Select BoM 2 without saving. Result: The component C1 is deleted
and replaced by the component of BoM 2.
- Select BoM 1.
Problem:
The component of BoM 2 is not cleared. Because we check if the new BoM
is different from the original one, but since we didn't save the change
when selecting BoM 2, the `move_raw_ids` are not cleared.
Solution:
Clear the `move_raw_ids` if any move with `bom_line` is not linked to
the current BoM.
OPW-3473387
closesodoo/odoo#135044
X-original-commit: f874fd46fcf8c2668c6d2ab42224196868ec0f0a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce:
- In Manufacturing, create a the following BoM
- Product: P1
- Components:
- 2 x P2
- 2 x P2
- Set the quantity in stock for P2 to 2
- Open the Overview from the BoM
Issue:
The 'Ready to Produce' column will indicate 1, as it checks line by line
how much product there is in stock compared to what is required for this
line.
To avoid this, we just need to sum the quantities required by products.
closesodoo/odoo#134890
X-original-commit: b8fda0bdb2238cba21a4541f4292da04003704cf
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce:
- Create a serial tracked product
- Update quantity add random SN
- Edit "ir.sequence" for serial numbers
(search sequence with dev mode enabled)
- Add a prefix for exemple "xx%(doy)sxx"
- Manufacture the product and generate new serial
Bug:
if a serial already exist next number in the sequence will be generated
instead of using the sequence
Fix:
apply same logic than for lots i.e. first generate from sequence then
take next number if it already exists
opw-3291532
closesodoo/odoo#134879
X-original-commit: df96d9ca10c576981f6af79e330b5b46cdeea377
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Before this commit, formatters like `formatMonetary` and `formatFloat`
weren't loaded in the assets front-end.
This commit introduces `formatAmount` ( `formatMonetary` calls
`formatAmount` but makes some prior processing to deduce the currency
from the field) and makes `formatAmount` and `formatFloat` accessible
from any front-end application.
Note: The currencies were added in the front-end session info because
they are needed in `formatAmount`.
closesodoo/odoo#133824
Related: odoo/enterprise#46658
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Introduce new model of "Product Documents" to hold documents linked
to a given product template/variant, displayed on:
* quotations
* confirmed sale orders
* e-commerce product page
This will also replace the previous "Digital Files" (website_sale_digital)
logic & module, which allowed to specify product documents available
to customers after the SO invoice was paid.
This exact feature will be lost after upgrade, since we only keep the
choice to link documents on quotations/orders, but:
1) on e-commerce, carts are supposed paid when confirmed
2) on portal, the "Online Payment" settings makes sure the users
have to pay to confirm their quotation.
therefore we consider new configuration sufficient, without needing
a "paid order" choice as well.
task-3249201
Part-of: odoo/odoo#132739
Usecase:
- Create a BoM for a template
- Replenish 2 different variant
Expected result:
2 distinct production orders for each product
Current result:
A signle production order with the first product variant and twice the
quantity
closesodoo/odoo#134067
X-original-commit: 2a658fb4a509238cd1462e2ffb615ecec05bc2e2
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Following commit 5620e47f80
1. workcenter automatic setting should be in demo data
2. Routings in demo data where set to active=False and enable
in mrp_workorder (OE) module. Since we enable by default
workcenters in mrp, we could remove this restriction
closesodoo/odoo#133908
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
* = calendar, hr, im_livechat, mrp, project_todo, sms, snailmail,
test_mail
The parameter is too often specified with its default value to be worth
being a positional parameter.
Part-of: odoo/odoo#133717
1. In mrp settings, check workorder by default
2. Remove stock for Table leg in demo data
closesodoo/odoo#133758
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>
Minor cleanup after odoo/odoo#104741 thanks to edge-cases and the fun
complexity of logistics code. Fixes include:
- removing some readonly=False that were added on computed/stored fields
that already have an inverse func or were already not readonly (i.e.
redundant => cleanup)
- fixed visibility of qty to prod in subcontractor portal view of a MO
(i.e. yay they know how much they're supposed to make again)
- remove unused imports
- adding back in readonly functionality of default dest of repair
operation type (and removing the now useless field override that used
to add in the readonly functionality)
- adding back in the `_set_product_qty` inverse function since it was
probably removed by mistake (and is still important to have)
unrelated to viewpocolypse change, also fixed:
- mobile view of PO was for some reason allowing products to be changed
in already confirmed/done POs, which could lead to some inconsistent
data => made this consistent with existing desktop view behavior
closesodoo/odoo#133502
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
When opening the list view of workorders, a traceback was triggered.
The problem was that parent was not defined when not in a view form.
Checking if parent first exists solves the problem
closesodoo/odoo#133213
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
To reproduce the issue:
1. Create two products A, B
2. Create two BoMs:
- Product: A
- Component: B
- Product: B
- Component: A
3. On one BoM, open the report "Structure & Cost"
Error: an Odoo Server Error is raised: "[...] maximum recursion
depth exceeded while calling a Python object"
The error occurs because of the cycle between both BoMs. There is
already a check for that in `:MrpBom.explode`:
https://github.com/odoo/odoo/blob/2a73890d304476833d76bac9a36ef92f12f267a3/addons/mrp/models/mrp_bom.py#L329
But it's too late in the flow. We should not be able to configure
such BoMs.
OPW-3200969
closesodoo/odoo#132806
X-original-commit: ba66f6b2ad3ea226779af23cdb4ddf223dd7fe85
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Following 332c117, the list of workorders cannot be accessed from the
menu. This is due to the `parent` not being defined in this case. The
`column_invisible` clause is useful when using the tree view from within
a MO form.
Before the change, the `attrs` attribute (containing the
`column_invisible` clause) was overwritten in the inherited view that is
accessible from the menu. Now that each previously-attrs are separate,
we need to explicitely overwrite `column_invisible` to get rid of the
reference to `parent`.
closesodoo/odoo#133026
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
The report "Manufacturing Orders" is just the graph/pivot view of MO,
most of the infomation can be found on a more accurate report
"Production Analysis".
In this commit, we removed "Manufacturing Orders" from the report view.
Users can still access it from Operations -> Manfacturing Orders ->
graph/pivot view.
Task-2695732
closesodoo/odoo#130342
Related: odoo/enterprise#44912
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Currently on stock moves, product_uom_qty indicates the demand qty
before the move is done and it indicates the acutual done qty when
the move is done.
As a result, when validate a stock move with qty_done !=
product_uom_qty, a new move is always created for the difference.
And the product_uom_qty of the original move will be changed to match
qty_done.
In this commit, we change to that product_uom_qty will always indicate
the demand qty, and qty_done will always indicate actually done
quantity.
To do that, when underconsumption, we won't split the move when no
backorder. and when overconsumption, we will always merge the extra move
back to the original move.
Task-2695732
Part-of: odoo/odoo#130342
Jorge Pinna Puissant