Before this commit, User can select Cancelled MO before selecting Product.
but it is already blocking since we already have constrains to not allow ubnuilding
Cancelled MO.
With this commit, We are always showing Done MO.
closesodoo/odoo#70316
X-original-commit: 48c0efcc97e35e00ec5803235a89a2c18e821990
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Before this commit, It was always showing all
Unit of Measures in By Product lines.
With this commit, We are showing UoMs based on Category
of Selected Product's UoM.
closesodoo/odoo#70367
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Before this commit there would be trackback (TypeError: unsupported operand type(s) for -: 'datetime.datetime' and 'NoneType') when you will try to remove field Start date as we are using the field to compute duration.
With this commit, we compute duration when Both fields are present.
closesodoo/odoo#70482
X-original-commit: f29597fce37350f1c05d98341b959809bbb160b2
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Before this commit, Creating Unbuild order using
Unbuild Button was resetting Bom as it was calling
`_onchange_product_id` after setting `mo_id` which was
resetting Bom on Unbuild order.
To Fix Issue, We setting `default_product_id` so It would not
reset `bom_id` when `_onchange_product_id` is called.
Fixes: #70216
Odoo Ticket: 2521788
closesodoo/odoo#70304
X-original-commit: 4de0ae434d1adc97fc1077b8d0f23c7e800ec161
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Since df312153d4,
the `worksheet_type` default become 'text' instead of PDF. Then,
update the demo operation to show pdf instead of empty text.
task-2523601
closesodoo/odoo#70463
X-original-commit: 722fba2313bae3f2825492a3822111bbb25332b7
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Commit 044c5c2c81 removed the context key
`variant` of the bom structure report. This implies to always print
every variant in case a BoM has no product_id.
This commit fix this issue to print only the variant selected in the
report. It also adds a new button to print the report with all variants
in case for some customers this behavior was "not a bug but a feature".
Task : 2504524
closesodoo/odoo#70444
X-original-commit: 8da349e785b5b461ea19874df9686f8cd26af8ad
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Without this commit, User was not allowed to create Unbuild Order
for the product without BoMs from Unbuild Orders menu.
But User was able to create Unbuild Order using 'Unbuild Order' button
on MO.
With this commit, We are allowing user to select Products without BoMs
to make this behavior consistent so user can create Unbuild Order from
Unbuild Orders menu.
closesodoo/odoo#70246
X-original-commit: eb332de42a36b7235d5578d39d345a5ff1df7759
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Before this commit, if any workorder is stared to produce, qty
producing was 0. After this commit, if product tracking is none
then system will suggest the remaining qty of workorder to produce
when user is start it.
TaskId - 2480775
closesodoo/odoo#70207
X-original-commit: 5bbc234d43a415be18fcfa42dad33b1577644719
Related: odoo/enterprise#18086
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
To display an aggregate in a list view, the field format method is used.
But since mrp_time_counter that extend float_time has no format method,
you would see eg. 2.07 as aggregate and 2:04 on the line which is a
little confusing.
opw-2514634
closesodoo/odoo#69795
X-original-commit: 020958f55d384e546eb61c98763d45b5db1ed206
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
previous implementation works slowly for products with many variants.
Performance Test
================
* ~5 K product.template
* ~14 K product.variants
* ~12 K mrp.bom
* ~414 K mrp.bom.line
Reading time for the field on a product with ~1000 variants
Measuring total request time:
* Before 9,5 sec
* After:
** without module upgrade 1,5 sec
** with module upgrade 0,3 sec
Measuring query execution in psql:
* Before 7,2 sec
* After:
** without module upgrade 0,7 sec
** with module upgrade 0,001 sec
---
opw-2494423
closesodoo/odoo#69293
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Method `_onchange_workorder_ids` will create workorder_ids
for the the selected bom but it was not re-setting it on removing
BoM.
It was causing issue on `_action_confirm` as Bom for the selected
WO will not be found.
closes odoo/odoo#69662
Fixes: #68261
X-original-commit: 13832912daafad7c472d7414eaacede9e302e787
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Usecase to reproduce:
- BOM PROD 1 -> No operation -> KIT COMP 1
- BOM KIT COMP 1 -> at lease one operation
Create a MO and confirm it -> Traceback.
It happens because workorders_by_bom[production.bom_id] will try to
find the bom related to production order. However they don't exist but
it will create the entry [BOM PROD 1] = mrp.workorder()
The [0] will be call on each values of the list afterward and raise
the traceback
opw-2477269
closesodoo/odoo#69651
X-original-commit: edabb86a306c4dda088b39f163de5668b5d90392
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Before this commit,
It was always displaying `BoM Structure & Cost` for BoM Structure and
BoM Structure & Cost report.
With this commit, we are displaying correct report name based on report type.
closesodoo/odoo#69595
X-original-commit: e47f7db5ead8719d76f5fe1afd451f0ce113864b
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Steps to reproduce the bug:
- Install manufacturing app
- Create a product A
- Create a Bill of Materials for product A
- Archive Product A (Only the final product not any of the components)
- Print BOM or Print BOM Structure & Cost
Bug:
A traceback was raised
opw:2447514
closesodoo/odoo#68116
X-original-commit: 81ee677bd52db388e29c26e255ccab27a286cf94
Related: odoo/enterprise#17186
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
previous implementation works slowly for products with many variants.
Performance Test
================
* ~5 K product.template
* ~14 K product.variants
* ~12 K mrp.bom
* ~414 K mrp.bom.line
Reading time for field ``used_in_bom_count`` on a product with ~1000 variants
* Before 9,5 sec
* After 1,5 sec
---
opw-2494423
closesodoo/odoo#69341
X-original-commit: a2d63e8ae5d6bc0e822d12d724b5e3ff5a979cad
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Ease bill of material - operation configuration.
- allow to change the BoM of an operation,
- allow to update a BoM by duplicating existing operations(& quality points),
- by extension, changing the operation of a quality point update the products.
closesodoo/odoo#65628
Task: 2413246
Related: odoo/enterprise#16159
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
When we deactivate the work orders in the settings, new MOs still
use operations that were assigned to the BoM, it just does not show the
Operations tab. We fix that by archiving the operations when work orders
are deactivated in the settings.
closesodoo/odoo#66108
Related: odoo/upgrade#2344
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When marking an operation as done, the quantity produced may be zero.
Therefore, the duration computation will not work.
To reproduce the error:
1. In Settings, enable "Work Orders"
2. Create two products P_prod and P_compo
- P_compo is consumable and its cost is 100
3. In Manufacturing, edit/create a Work Center WC
- Cost per hour must be 60
4. Create a Bill of Materials BM
- Product: P_prod
- Component: P_compo
- Operation:
- Work Center: WC
- Duration Computation: Compute based on tracked time
- Based on last 3 work orders
- Default Duration: 10:00
5. In Structure & Cost, notice that BoM Cost is 110
- 100 (P_compo's cost)
- 10 (OP's cost based on default time)
6. Do the following 3 times:
- Create a MO with P_prod using BM, Confirm
- In Work Orders, click on Start, then Done
- Edit the Real Duration of OP: 20:00
- Mark as Done
7. Back to BM, open Structure & Cost again
Error: BoM Cost is 110, this is incorrect: OP's cost is still 10, it
should be 20 (from step 6).
The problem is the quantity produced for each operation. Since this
quantity is never defined, it remains at 0. Therefore, when computing
the duration, since there is no quantity, the module keeps the default
value.
This fix changes the behavior. When the user marks the operation as done
from the form view, the module defines the quantity produced using the
quantity in production (this quantity may have been defined by the user
through the tablet mode). If this value is also 0, the module will use
the quantity expected by the MO.
`('qty_produced', '>', 0)` is added to avoid lines with zero quantity
produced, which was possible before this fix. Otherwise, the duration
calculation will give wrong values.
OPW-2453996
closesodoo/odoo#68917
X-original-commit: 93be6c6cfcfb3c4e52790569632dbdcdb1a3ae54
Related: odoo/enterprise#17540
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
This commit removes stock.inventory(.line) and moves its general
functionality into stock.quant. Some features are lost during this
switch as well.
Feature Additions:
- New single list view for inventory adjustments (no more multiple
inventory adjustment records to keep track of!)
- Improved cyclic counts (annual inventory day setting) + next inventory
dates are immediately viewable in view (vs auto-generated inventories
based only on location)
- Specific quants (i.e. counts) can be assigned to users for more
flexibility (vs only able to restrict by location + product
combinations)
- Counts can be requested (i.e. bulk assigned to user/for a specific
inventory date)
Feature Removals:
- Can no longer look at previous inventory adjustments linked to a
specific record. Each quant has a history button to show inventory
related moves. [relevant account moves are also now harder to see via
stock as well]
Other changes:
- Bulk of changes were for demo/test
- Some changes were done to ensure "Update Quantity"/"Inventory Report"
views still mainly function the same as before with the exception of a
new column added to support updating quant quantities in these views.
Task: 2440026
ENT PR: odoo/enterprise#17329
Upgrade PR: odoo/upgrade#2326closesodoo/odoo#68409
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Conversion of all modules to the new manifest assets declaration.
Part of task: 2352566
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
We introduced new Smart Putaway Rules.
Locations now can have a storage category, on each storage category,
we can specify the amount of products/packages(with certian package
type) that can be stored in the location.
On putaway rules, we can also set a storage category. Now when apply a
putaway rule, we will find a suitable child location of the out
location according to quantity/weight setting on the storage category.
Task 2341820
PR #63516
ENT PR odoo/enterprise#15363
UPG PR odoo/upgrade#2040
To avoid multiple search of the get_warehouse for the same location
and extra SQL request (it happens a lot for complicate flow, e.g.
mrp_mps, replenishment report).
Translate it into a standard compute to use the cache of
the ORM for no-store compute field (`warehouse_id`) and put
some depends to be always correct (even if `warehouse_id` shouldn't
change in the same request).
task-2439019
Some usage of `_bom_find` are performance bottleneck (one request by
product). By example, when the mrp is installed, search products
with fields compute by `_compute_quantities` (e.g. 'Negative forecasted
quantity'). it is due to the override of `_compute_quantities`
in mrp which will make (in the worst case) a `_bom_find` for each
product in the DB.
To avoid this situation the `_bom_find` method become batched
which can handle several products in once. The signature of the method
has changed and uniformize in all module.
Example performance Gain:
------------------------
In a DB with 7000 products (type 'product'), 500 locations, 1800 BoM,
9000 Stock moves, etc. Search in the tree view with filter "Negative
forecasted quantity":
Before: 10879 (nb SQL request) 12.67 +- 0.11 sec (Total RPC Time)
After: 159 (nb SQL request) 1.82 +- 0.03 sec (Total RPC Time)
task-2439019
Considering the MO under consumption situation:
component A, to consume = 2, consumed = 1
Previous, after "mark as done", the MO will have two lines:
component A, to consume = 1, consumed = 1, state done
component A, to consume = 0, consumed = 0, state done
Now, after "mark as done", it will be consistent with picking:
component A, to consume = 1, consumed = 1, state "done"
component A, to consume = 1, consumed = 0, state "concel"
Task 2446915
PR #66583
ENT PR odoo/enterprise#16554
This commit is a revert of revert 561b3461a0
and 97ba860fd38c530d3f3678f676754862afad0f11.
Previously we split moves when no picking, now we consider it
unnecessary.
Task 2446915
COM PR #66583
ENT PR odoo/enterprise#16554
This commit adds 2 small feature additions to reservation logic:
1. Add another # days parameter for reserve "before scheduled date"
option for priority moves (i.e. so they can be marked for reservation
earlier)
2. Add Reserve button in the forecast report
It also cleans up some auto-reserving logic:
- 'at confirm' now has a reservation_date = day of confirmation:
- removes need to check `reservation_method` when doing automated
_action_assign (i.e. in scheduler + completed incoming move).
- allows ordering by reservation_date during automated _action_assign
for more consistent and logical reservations.
Task: 2418907
Upgrade PR: odoo/upgrade#2143
Some documentation was removed to reduce technical debt + they deemed
were self-explainatory. The links to these pages are removed to match.
Some links were also updated/changed to redirect => these links have
been updated to match the new addresses.
closesodoo/odoo#68214
Task: 2457087
X-original-commit: 49cfc4165ff19f6fd293bed2f6867a32cc0b8c5d
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Because kits might never be in stock, it's impossible to fullfil the
quantity of a reordering rule: asking a mini/maxi quantity on a kit
makes no sense.
Odoo will continuously propose to order more to reach the quantity
necessary for the kit, but will never reach the asked qty, as it's a
kit, not a manufactured product.
OPW-2448878
closesodoo/odoo#68362
X-original-commit: c47a9319c081105e46e56f881b25fd6442266089
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Some changes on the MRP workcenter model (`mrp.workcenter`):
- Adds a stat button in the form view to display operations used by
the workcenter;
- Enables the multi-edit on the list view;
- Adds multiple fields in the list view, often as optional;
task-2382256
closesodoo/odoo#62126
Related: odoo/enterprise#17250
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
On the MRP operation model (`mrp.routing.workcenter`):
- Changes the order (ordered by workcenter and BOM in priority);
- Adds computed field, `time_computed_on`, which is only used in list
view (display on how many numbers of work orders the duration is
computed);
- Adds multiple fields in list view (often optional display);
- Adds two groupby (by BOM and by workcenter).
task-2382256
The`picking_type_id` of the stock.rule wasn't take in account in
the search of BoM because the `_get_matching_bom` with a empty `self`.
fix it by call on the current rule.
X-original-commit: d43e9cb9ad8d1c0c020209de0e8f6ffdcbc960a1
The replenishement creation currently calculates the quantity to order
using a default multiple quantity of 1. In case of manufacturing route,
we want to calculate the multiple quantity according to the quantity
produced in the BoMs.
closesodoo/odoo#62766
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Issue:
On DB with a lot of product (e.g. 50K) the MO form is very slow
open/modify. It is due to the `_compute_allowed_product_ids` which
will set the `allowed_product_ids` fields with all product ids possible
(32K), then the `convert_to_record` will take a bunch of time to filter
out no-active product.
Fix:
In your case, to avoid to send bunch of ids to the web framework and
bypass the costly `convert_to_record`, we decided to simply (static) the
domain of `product_id` (`mrp.production`). The flow will be slightly
different (doesn't filter depending of `bom_id`) but still good and
maybe better (we can now modify the product without removing the
BoM/product in the MO form).
Remove `allowed_product_ids`.
opw-2475151
closesodoo/odoo#67753
X-original-commit: a1a4f4548b395127cf7f816379a63f2d47688893
Related: odoo/upgrade#2272
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
If the company uses multi-step routes, when duplicating a MO, if the
user changes the BoM, one stock picking will be missing.
To reproduce the error:
1. In Settings, enable "Multi-Step Routes"
2. Go to Inventory > Configuration > Warehouse Management > Warehouses
3. Edit the warehouse "YourCompany"
4. Set Manufacture to "Pick components, [...] products (3 steps)"
5. Create a storable product SP
6. Create two non-empty BoM (BoM01 and BoM02) for SP
- (Hint: set a different reference for each BoM)
7. Create a MO
- Product: SP
- BoM: BoM01
8. Save, Mark as Todo
- (As you can see, 2 transfers have been created: one from WH/Stock
to WH/Pre-Production, and a second one from from WH/Post-Production to
WH/Stock)
9. Duplicate the MO
10. Set BoM to BoM02
11. Save, Mark as Todo
Error: Only one transfer has been generated. The transfer from WH/Stock
to WH/Pre-Production is missing. (The duplication step is used to
compare the result. If the user saves a new MO, and then edits this MO
to change the BoM, the same problem will occur).
When confirming the MO, the module runs both pull and push rules. When
running the pull rule, the modules assigns a stock picking to a stock
move. To do so, it checks if one stock picking already exists:
https://github.com/odoo/odoo/blob/7d9264c56ac725c8d19aebad55d5668df2a8c814/addons/stock/models/stock_move.py#L863-L873
Since such a stock picking does not exist, the module creates a new one:
https://github.com/odoo/odoo/blob/7d9264c56ac725c8d19aebad55d5668df2a8c814/addons/stock/models/stock_move.py#L887-L900
When changing the BoM, an `onchange` method is raised, deletes the stock
moves linked to the first BoM and creates some new ones. However, since
`group_id` is not a field required by the view
`view_stock_move_raw_tree`, this field will not be included in the
`onchange` response.
As a result, when saving the new MO, the `write` request does not
contain the `group_id` field, so the new stock moves do not have this
information. Therefore, when running `_search_picking_for_assignation`,
the module finds a picking and does not create a new one.
OPW-2444235
closesodoo/odoo#67356
X-original-commit: b810e5ff72b892983c52b24ca7efe5025c8a7142
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Description of the issue/feature this PR addresses:
- Fix tends to hide done/cancel MOs from mrp.production form
- A planned MO is already a confirmed MO
Current behavior before PR:
- To-do filter displays all MOs
Desired behavior after PR is merged:
- To-do filter hides MOs with done/cancel state
Task ID: 2442058
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#67008
X-original-commit: b7064d9a0bf6cc78399b61cdf862db961bbf4d5c
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Noura <nouraellm@users.noreply.github.com>
Generic operations will be applied for every manufactured product passing
through the work center.
An operation linked to a bom will only be applied when the specific manufactured bom is produced
So on a BOM, every operations must be created for this specific BOM
The widget many2many is wrong because it will overwrite the generic operations
opw:2458974
closesodoo/odoo#66888
X-original-commit: a430c06ec6ec286a2d9ef55de6eebec60feeae3f
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Steps to reproduce the bug:
- Go to an existing BOM B
- Edit B and try to add an existing operation O in operations tab
Bug:
It was impossible to add an existing operation
opw:2458974
closesodoo/odoo#66712
X-original-commit: ffab43fbf54b2f914b34c18da2391f3a18b3326c
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
For odoo-master Transifex project, no demo data
closesodoo/odoo#66500
X-original-commit: 813931ac850e5ba4181259a5957ec72226fb670c
Related: odoo/enterprise#16510
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The unlink fail in __init__.py uninstall hook is managed, however
when it fail, the error is catch but the cursor is not rollback and
do not accept additional transaction. That result in a traceback at
uninstall.
opw-2453939
closesodoo/odoo#66309
X-original-commit: 66d9dce9b6e6e65000ba0b62efcb153f2d3eec15
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Add and improve onchange warnings when a duplicate SN is used in
following cases: inventory, picking (any type), manufacturing, scrap,
and "Update Quantity" (i.e. directly edit quants from product form).
Improvement includes:
- include location where the existing SN is
- auto-correct source location when appropriate (e.g. trying to scrap a
SN in the wrong location)
The goal of this is to prevent but not restrict duplicate SNs so users
can have some flexibility (especially if a dupe SN occurs because of an
error such as doing pick-pack-ship out of order.)
closesodoo/odoo#61287
Task: 1924758
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Replenishment is great to replace MTO but misses the direct link between SO and PO (smart buttons on both SO and PO to link to the corresponding PO and SO).
The info is actually there in the forecasted report but it is not accessible directly from the PO and in the case of the SO does not highlight the corresponding line of the SO.
This adds a graph icon in the PO, MO and receipt form to directly access the forecasted report (it already exists for SO and delivery).
The information linked to the SO/PO/MO/receipt/delivery is also sent to the forecasted report to highlight the corresponding line.
Note that in the case of the SO, the information needs to go first through the qty_at_date widget (which contains the link to the forecast report).
The graph icon for the PO, receipts and MO turns red when the forecasted quantity at expected date is negative. This is done using the new 'forecasted_issue' field.
closesodoo/odoo#62264
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When `qty_available` was being called
for a kit and its components at the same time,
e.g.:
- Kit product
- Product 1
- Product 2
The kit product available qty was always computed to `0.0`,
because when computing its component available quantity,
they were computed to `0.0` because they were marked
as `protected` by the ORM when calling the compute method
for these records at the first call.
When the `qty_available` compute method for the kit
then called recursively the `qty_available` compute
method for the component, as the component record
were marked as protected,
the ORM filled their value with the Falsy value `0.0`.
This issue occured particularly in the upgrade integrity unit test
which makes sure the available quantities of the products remain
unchanged after upgrade. This test computes the available
quantities for a bunch of products at the same time,
and its therefore likely a kit product gets its available
quantity computed as the same time than its components.
upg-3185
upg-4215
upg-4228
upg-5558
upg-5745
upg-5856
upg-6012
upg-6064
upg-6076
upg-6306
upg-6514
upg-6588
upg-6729
closesodoo/odoo#65758
X-original-commit: 8e152a567a6003dae4abb3b537b963eec4142d6d
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
This commit makes it so when the bom structure report (Structure & Cost
smartbutton) is opened the product quantity defaults to the BoM's
`product_qty` amount rather than 1.
Steps to reproduce:
- Create/open a BoM
- Set `product_qty` to any value greater than 1
- Click on "Structure & Cost" button.
Expected result: product quantities scaled to the `product_qty`
Actual result: product quantities scaled to Quantity = 1
closesodoo/odoo#65747
Task: 2429885
X-original-commit: 30c05ad99bcf5884e071ebfa41adc6b44f23ba1e
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
* 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
Swapnesh Shah