* account, analytic, calendar, coupon, crm, crm_iap_lead_website,
delivery, digest, event, event_crm, fleet, gamification, hr,
hr_expense, hr_skills, im_livechat, lunch, mail, maintenance,
mass_mailing, membership, mrp, point_of_sale, pos_mercury, product,
purchase, purchase_requisition, sale_management, sales_team, sms,
stock, stock_landed_costs, survey, website_crm_partner_assign,
website_event_exhibitor, website_event_track, website_forum,
website_slides, base
This commit removes oe_edit_only labels and adds placeholder
on fields in form views from a lot of apps to minimize the
shift when switching mode.
task 2330101
If a product is a kit and has a storable component, if this component is
already ordered (with sufficient quantity), when running the scheduler,
the ordered quantity of this component will still be increased.
To reproduce the error:
1. Create two products P_kit and P_compo
- Both are storable products
- P_compo must have at least one vendor
2. Create a BoM for P_kit:
- Must be a kit
- Add P_compo to components
3. Set a reordering rule for P_kit
4. Inventory > Operations > Run Scheduler
5. Go to Purchase and find the generated RfQ
- The ordered quantity is correct
6. Repeat 4-5
Error: This time, the ordered quantity is incorrect. While you don't
have any P_kit on hand, each time the scheduler is run, the ordered
quantity will increase.
A similar issue has already been fixed: #63891. The original commit
targets the version 13, but the fix has also been applied to v14 (#64277).
However, here the case is slightly different: the user run the scheduler
twice while the first RfQ is not yet confirmed and received. In such a
case, the scheduler must also check the "quantity in progress". In version
14, it seems nothing computes this quantity for the kits.
OPW-2421841
closesodoo/odoo#65100
X-original-commit: f53ab55000c32fd67c567f01a9533298936daaac
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Issue
- Install "Manufacturing" module
- Go to settings and activate "Master Production Schedule"
- Install Dutch language
- Switch user language to Dutch
- Go to Manufacturing -> Planning -> Planning by Production
- Hover work order
Dates are not displayed with user locale.
Cause
Date are formated to "YYYY-MM-DD HH:mm:ss",
regardless the locale.
Solution
Format date instead with locale format letters (L, LL, LTS, ...)
Doc : https://momentjs.com/docs/#/parsing/string-format/
Go to "Locale aware formats" section
opw-2430570
closesodoo/odoo#65092
X-original-commit: 08978c6d2d14a94e6ee2fea0dedc805a56378de0
Related: odoo/enterprise#15970
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Add two indexes (on `product_id` and `product_tmpl_id`)
on the `mrp.bom` model to speed up `_bom_find`
which is highly used and it uses always the `product_tmpl_id` and
sometime the `product_id` in the search domain.
Performance Gain:
With a DB with 2K BoM, a `_bom_find` search (`product_id` and
`product_tmpl_id` are in domain): The SQL execution time
is +- 5 times faster.
task-2390516
closesodoo/odoo#64934
X-original-commit: 64861aed03b616820d717bc08e7c38c56145e0f2
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Replace union of RecordSet by union of OrderedSet to reduce the
complexity and improve the scalability. It can be a bottleneck to
huge number of move to validate.
task-2390516
X-original-commit: d9510aee26578e1b345a7700f7c94032d5745bf4
Related fields are by default readonly and they should be when it
is possible. A editable related field will write on the related
model and will cause extra unwanted write of data. These unwanted write
can cause performance issues in some case (see odoo/odoo#63865).
Then remove the `readonly=False` of some related fields
(where it is useless):
- In 'mrp.workorder' (mrp): `working_state` and `production_date`
should be readonly.
- In 'purchase.order' (purchase): `product_id` should be readonly.
- In 'purchase.order.line' (purchase): `state` should be readonly.
- In 'product.supplierinfo' (purchase_requisition):
`purchase_requisition_id` should be readonly.
- In 'purchase.requisition' (purchase_requisition):
`product_id` should be readonly.
- In 'product.template' (stock):
`route_from_categ_ids` should be readonly.
- In 'stock.move.line' (stock):
`is_initial_demand_editable` should be readonly.
- In 'stock.move' (stock):
`product_tmpl_id` should be readonly.
- In 'stock.production.lot' (stock):
`product_uom_id` should be readonly.
- In 'stock.quant' (stock):
`product_tmpl_id` should be readonly.
- In 'stock.rule' (stock):
`route_sequence` should be readonly.
- In 'stock.change.product.qty' (stock):
`product_variant_count` should be readonly.
- In 'stock.return.picking.line' (stock):
`uom_id` should be readonly and also because it
is forced by `_prepare_stock_return_picking_line_vals_from_move`,
it should be related to the product uom not the one on the move.
task-2424248
Some added readonly attributes in the unbuild form view were overriding
the `states={'done': [('readonly', True)]}` attributes in the models'
fields. So we add the readonly when state='done' to the view as well.
Note that same issue exists in saas-12.3 and 13.0, but only for 2 of the
4 fields fixed in this commit (i.e. it probably isn't a big deal for
these older versions.)
Discovered during task: 2033341
closesodoo/odoo#64815
X-original-commit: 8bfa9efd989f4123b021c47f13cfe324eeb14013
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Before this commit 'product_qty' had a width of 0 because
the 'product_uom_id' field took 100% as width on mobile.
This rule has been added by the 'oe_inline' css class.
To fix this we simply removed this class as we don't need it
on desktop: rules have been overridden by another
selector for this case.
Steps to reproduce:
- Manufacturing
- Manufacturing Orders
- Create
- Quantity field with UOM active.
Related to task ID: 1929043
When using the route `/report/barcode/...` in a report, wkhtmltopdf
makes htpps requests on the server to retrieve the barcode image.
If a lot of barcodes have to be printed, this can overload the server
with too much requests and makes wkhtml crashes.
With this commit, the qweb barcode widget is used to include the barcode
as an img tag with inline barcode image as base64 data.
closesodoo/odoo#64211
Related: odoo/enterprise#15619
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
When running the scheduler, if one of the concerned product is a
kit, it will always generate a RfQ for the components, even if there
are already enough of them.
To reproduce the error:
(Need purchase)
1. Create 2 products P and P_compo
- Both must be storable products
- P_compo must have at least one vendor
2. Go on P-product page
3. Add a reordering rule (e.g., min: 5 and max: 10)
4. Add a BoM
- Must be a Kit
- Add P_compo to components
5. Inventory > Operations > Run Scheduler
6. Go to Purchase, find the generated RfQ
7. Confirm the order, Receive Products, Validate
8. Go on P-product's page
- As you can see, you have enough P-products on hand
9. Repeat steps 5-6
=> You should not find any RfQ since you already have enough P-products.
When checking the P-product's page, you can see the correct quantity on
hand because it uses the `_compute_quantities` method and this one has been
overridden in the mrp-module so a kit will be correctly computed.
However, when running the scheduler, it uses another method to get the
current quantities: `_compute_quantities_dict`. Since this method has
not been overridden in mrp-module, it will use the basic implementation
and this one does not consider the possibility for a product to be a
kit.
This fix creates an override of `_compute_quantities_dict` so it can
compute the correct quantities of products with 'phantom' as BoM type.
Moreover, for the code to be simpler and clearer, thix fix also merges
`_compute_quantities` and the new `_compute_quantities_dict`.
OPW-2421841
closesodoo/odoo#64326
X-original-commit: 609e2f4427082431b56aa8f999d74ed9d39db653
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
- make `bom_id` required. No sense to have a operation without BoM
- `company_id` of operation is now related
- Clean the multiple `allowed_operation_ids` into related
fields instead.
task-2373638
In order to have always a picking_type_id on a stock move (and
consistent with his parent model), make it compute store.
Then clean the call of picking_type_id without change the behavior
(/!\ `move.picking_id.picking_type_id != move.picking_type_id` because
of mrp). Fix some test where the location(_dest) was unset in moves.
Also:
- Clean the mess in the create of `stock.picking` about that
and add a onchange to keep location(_dest) consistent with moves.
- The move `description_picking` is set when the `picking_type_id`
change, not only at the create method.
task-2373638
Behavior prior to this commit:
- normally when editing the Scheduled Date on a MO, the date on the
related stock moves is updated. However this does not happen once the
MO is planned
- if the date is edited and the MO is planned, the MO is automatically
unplanned, but the date on the stock moves is not automatically updated
Behavior after this commit:
- when the date is updated on the MO and it is planned, the dates on the
stock moves will automatically update, so that the behavior is
consistent with how it would work if you clicked Unplan first then
updated the date.
Note:
- this commit is forward ported from 14.0. Only the unit test was
ported, as the behavior had already been modified to match the
expectation.
opw-2417108
closesodoo/odoo#64006
X-original-commit: 97f79960dbb3aa371378f576cfdce9670ca8ccce
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
We add a index on the workcenter_id and workorder_id, both
have a One2many related to (`time_ids` of workcenter and workorder)
and both is in the some search domain in python (also in search view).
(Also change the `readonly='True'` into correct form `readonly=True`
of `production_id`, and remove duplicate fields `workcenter_id` in view)
task-2389380
closesodoo/odoo#63500
Related: odoo/upgrade#2042
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
The `bom_id` field has a One2many inverse `byproduct_ids`
then it should by index to avoid bottleneck if byproduct is
highly used by a lot of different BoM
Performance improvements:
When there is 20K of Byproduct line, read a BoM is x1.8 faster.
task-2389380
Remove index on fields `date_start` and `date_finished`. Both
has not used expected in the gantt view `view_production_gantt`
which not used anymore (and have no sense because it should use
`date_planned_start` and `date_planned_finished` instead.
Remove this old gantt view too.
task-2389380
The state of `mrp.unbuild` is a boolean value (`draft` or `done`) which
is already quite useless in the most of the case. Also this state is
never used explicitly in the code (in a search), then it seems legit to
remove it.
task-2389380
Indexed of boolean values is quite useless and the one of `priority`
(MO/Pickings) can be only used in filter search view (`starred`).
Then remove priority indexes from `stock_move`, `stock_picking` and
`mrp_production`.
task-2389380
- Create a new MO
- Remove the company name
The user see a traceback
This occur because the compute method does not check if the company is
set
opw-2422441
closesodoo/odoo#63917
X-original-commit: b7fa0cfad03a8319f03c1aa89eb67635e1200f67
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
`product_tmpl_id` of BoM line should be readonly,
there is no sense to change the product template from
the BoM line model. Also it avoids useless write on product
and inverse recomputation.
opw-2420830
closes#63631closesodoo/odoo#63890
Issue: odoo/odoo#63631
X-original-commit: 5a4746141670bdd241d85c7908a57ee9efa56c3f
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
With this commit, all instances of errors being raised inside
`BaseModel.unlink` overrides are moved into methods decorated with
`api.ondelete` which is safer.
revert of commit 2027721601890870e14b396ae4bb8b6c6dea1ac0
I tried to remove the BoM feature since mrp refactoring it would
probably create some issue and I thought that the feature was not
used. However it seems that it's write in the documentation and
some people realy use it so.
opw-2393302
closesodoo/odoo#62830
X-original-commit: 65a63216a3522922348cd57396db7de36c24a893
Related: odoo/enterprise#15137
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Currently stock moves are auto-assigned (i.e. reserve free stock) both
when the scheduler is run and when a corresponding stock move that can
assign a move is completed. This strictness was causing issues for
prioritization of moves to assign, for example a picking with a
scheduled_date far in the future could automatically reserve all stock
if it was created before another picking that an immediate
scheduled_date. To ease this, an extra setting has been added to
stock.picking.type to let users choose how reservations should occur for
moves assigned to that picking_type (or picking with that picking_type):
1. 'at_confirm' = automatically when:
- stock is available when the move's associated picking/MO is
confirmed,
- when new stock becomes available,
- when the scheduler is triggered (+ stock available).
2. 'manual' = user must always manually click "Check Availability"
button (scheduler will no longer reserve).
3. 'by_date' = automatically when within the move's reservation_date
and:
- stock is available when the move's associated picking/MO is
confirmed,
- new stock becomes available when move is already confirmed, or
- the scheduler is run (+ stock is available).
'by_date' has an extra option of # days before the move's scheduled
date that affects the move.reservation_date.
Task: 2359317
Upgrade PR: odoo/upgrade#1868
ENT PR: odoo/enterprise#15050
Steps to reproduce the bug:
- Create a BOM kit K with two components C1 and C2
Bug:
It was possible to set an operation on K
PS: Operation is not supported on BOM kit
opw:2393302
closesodoo/odoo#62455
X-original-commit: 2027721601890870e14b396ae4bb8b6c6dea1ac0
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
- Create Product A with UOM of type Unit
- Create Product B with UOM of type Unit
- Create BOM of type Kit on Product A with Product B as a component
with UOM of type Unit
- After saving BOM, change the UOM of Product B with UOM from another
categories (e.g. kg) and save the product
- Try to access product list
A warning appears and prevent showing the products in any way.
It is caused by the call to `_compute_quantities`.
In this case, it is ok to skip the error. Indeed, it will raise later on
when trying to use the kit. But at least, it gives the possibility to
the user to access the product list.
opw-2393711
closesodoo/odoo#62537
X-original-commit: 6de2537ac82d9dad3cb3f56a7b9b35856681a6ad
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Behavior prior to this commit:
- when the warehouse uses a 3-step manufacturing process, if I create a
Sales Order, the MO generated does not show the SO# as "Source", instead
it shows the MO#
Behavior after this commit:
- the MO source shows the SO# (similar to how it works when using the
2-step or the 1-step manufacturing process)
- the origins are assigned thus:
- Delivery Picking = SO name
- Post-prod Picking = SO name
- MO = SO name
- Pre-prod Picking = MO name
Note:
- there is no implementation change in this commit - we just ported the
test from the original commit in 13.0 (the behavior in 14.0 was already
OK)
opw-2380717
closesodoo/odoo#62512
X-original-commit: 0281dee6da75e68403772ebd368d57c1feb98c37
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
The 'On Hand' button triggers action_open_quants on product model. It
do not explode the kit into its component
closesodoo/odoo#62390
X-original-commit: 49b965eb1ec6a7ec6c07fa643cc6ae35ee8b5d91
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
What are the steps to reproduce your issue ?
1. Install 'Manufacture' and enable 'Work Order' in settings
2. Create product 'ProductA', enable 'Manufacture' in 'Inventory' tab
3. Create a BOM for 'ProductA'
4. For that BOM, create a new operation called 'OperationA' with PDF worksheet but don't attach any PDF
4. Go to 'Manufacture' and create a MO with 'ProductA', the 'OperationA' is automatically set in 'Work Orders'
5. Start the work order
What is currently happening ?
When you try to pause, an error is raised.
'TypeError: Cannot read property 'pdfViewer' of undefined'
What are you expecting to happen ?
Start and pause the work order even without attached PDF.
Why is this happening ?
'this.pdfViewer = existing.data('PDFViewerApplication').pdfViewer'
When there is no pdf attached. The data 'PDFViewerApplication' does not exist.
How to fix the bug ?
Change worksheet default value to text, and make the field mandatory in case of a PDF type
opw-2387428
closesodoo/odoo#62350
X-original-commit: 8597aada3d9bacc3cff4707bb78a7bc48d723cfb
Related: odoo/enterprise#14992
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
One can set a Unit of Measure precision rounding more
precise than the overall Decimal Accuracy. This can trigger the error
'It is not possible to unreserve more products', as there will be
inconsistencies on reserved quantities due to decimal roundings.
We add 2 warnings on Units of Measure and Decimal Accuracy.
Therefore, users are warned when their UOM/decimal changes can
cause inconsistencies in quants reservation.
Also, we want to prevent the issue at the root by ensuring that both the move
and the quant have the same reserved quantity.
The contrary can happen e.g. when a product is defined in Liters (rounding .001)
but used in an operation in ml (rounding .01, so e.g. 187.5ml).
The conversions between the 2 UOM can cause the differences of reservations.
In _prepare_move_line_vals we make sure uom_quantity_back_to_product_uom
is not more precise than the overall Decimal Accuracy. That way, if
the reserved quantity changes between UOM conversions, the move line created
is in the quant/product UOM, and we do not have move line's reserved quantity >
quantity in stock.
We do the same for _update_reserved_quantity (stock.move), when updating
a move line.
In _update_move_lines, because of UOM conversions, new_quantity_done
can differ from ml.product_uom_qty, which triggers the creation of an extra
move line, leading to reserved quantity > quantity in stock. To prevent
that, we compare the reserved quantities in the product UOM.
opw 2206902 (Example 1)
opw 2171541
opw 2221227
opw 2233937
opw 2198775
and many more
closesodoo/odoo#62279
X-original-commit: 478a42beb5876171afeab7df27fa69548edbf849
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This commit makes it so a note is logged when an unbuild order is linked
to a manufacturing order is completed.
closesodoo/odoo#62012
Task: 2378831
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
- Create product FP product to manufacture
- Create BoM:
- 10 units of FP
- Product CP (component)
- two operations.
- Create MO for FP and plan.
- Complete operation 1 for the 10 units
- Complete operation 2 for 4 units only
- Mark MO as done for 4 units
- Click Create Backorder
- Check backorder MO
Operation 1 is present, marked todo for 6 units,
but it was completed for all 10 units.
With this commit the quantity todo for the corresponding operation in
the backorder is updated to match the qty already produced
Removing `qty_producing` as it is computed according to
https://github.com/odoo/odoo/blob/ff648a0ace9cf72274211662707e7ee33fc73252/addons/mrp/models/mrp_workorder.py#L50
opw-2374640
closesodoo/odoo#61841
X-original-commit: a32bdf257d7a960fcd96cf6d32443bfe0295a296
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
`do_unreserve` is a action that can be made in the tree view of
`stock.picking` but it was very slow and not batched.
For 80 picking with -/+ 10 `stock.move.line` related each
(calculate on 5 sample of 80 pickings):
It took 17947 +- 2741 SQL requests, 7.37 +- 1.09 sec of SQL
and 8.13 +- 1.31 sec of python execution (+- 15.5 sec in total)
Make some change to speed up the unreservation of
multiple picking/move:
- Batch the call of `_do_unreserve` of move in picking
- Use OrderedSet instead of RecordSet to reduce the complexity of
`_do_unreserve`. (Become significant when len(recordset) > 1000)
- Add `.with_prefetch()` in the unlink of stock move line
to patch issue with prefetching + unlink + cache.
- Batch `_recompute_state`
- Also batch the `do_unreserve` of MO
Result after change in the same samples:
It take now 1438 +- 20 SQL requests, 0.45 +- 0.02 sec of SQL
and 0.68 +- 0.02 sec of python execution (+- 1.13 sec in total,
13 times faster). Note that the gain increase proportionally.
task-2383111
closesodoo/odoo#62083
X-original-commit: e7a43655448db161150d0c62efa14c54ade0a2f6
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Otherwise, they may crash or be incorrectly verified when
creating/updating recordsets containing multiple records.
Also improve the constraint error messages to be more detailed.
When possible, use a sql constraint instead to speed up the records
validation.
Task Id: 2328664
COM PR: https://github.com/odoo/odoo/pull/55525
ENT PR: https://github.com/odoo/enterprise/pull/12250
Correctly format the `product_uom_qty` with the appropriate widget.
opw-2382517
closesodoo/odoo#62085
X-original-commit: 042298f8c949fba470eda6ad90f94c95ca291030
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, the warehouse settings for MRP ("Manufacture to
Resupply" and manufacture step) wasn't displayed even if multi-step
rules is enabled until the multi-warehouse is enabled.
task-2376352
closesodoo/odoo#61482
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Activate units of measure and workcenters (work operations)
Create Product C, uom Kg
Create Product F, uom Kg
Create BoM for F, 2000g manufactured from 5000g of C
Set 1 operation/work order in the BoM: processing
Create MO to produce 2kg (change the uom in the MO) of Product F
from 5000g Product C
Confirm MO and go to the work order put the quantity of Product F to 1 Kg
then click Record Production/Mark as Done
The manufacturing backorder is automatically created but is not
showing the components.
This occur because of a mismatch between the uoms, `move._split` expect the
parameter `qty` to be based on the product uom, instead it is the quant uom
because the BoM was created using a different UoM than the one defined
in products
opw-2376217
closesodoo/odoo#61782
X-original-commit: 8b32e558fde3cb3aaa1deb40acb07488d04d343e
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Michael Mattiello (mcm)