PURPOSE
Lessen use of mail-specific calls and variables
SPECIFICATIONS
Use mail_new_test_user tool in tests, lessening use of mail-specific context
keys in tests.
LINKS
Task ID-2326281 (context keys use cleaning)
PR odoo/odoo#56631
PR odoo/enterprise#12707
X-original-commit: 910559c092dc7dfa00b91339a5423e16cd4668e1
Renames the "Table (MTO)" into "Table" and adds it a reordering rules
with 0 as min and max qty.
X-original-commit: b96b72c24aa80b9cdcfc2ebaf54438f3af6b1d9e
- Adds a MO for Table Top (2 units) to have a link between a consuming
and a replenishing MO in the new product forecast report.
- Generates finished moves for the demo data MO, so they can be retrived
by the forecast report.
- Changes date planned for the Table MO, so it will be planned after the
Table Top MO.
- Calls the `action_confirm` on the MOs in batch.
task-2058495
X-original-commit: d6b0c3dcfb2f9f926cef1d22c96e4f09afe0d6c8
If there is no `date_end`, sorting will crash.
opw-2326262
closesodoo/odoo#56603
X-original-commit: e981c17dd93c756a5cf0384ab2dcc25ef58cb1b1
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In case `date_planned_finished` is `False`.
opw-2326088
closesodoo/odoo#56578
X-original-commit: 5c7c6b42cc0e0fa5bdd78aeca48cdf4ba9f78cad
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
TL;DR
=====
Improve performances with nearly a factor of 2. Use case, call action_validate on hr.leave for 100 employees
- 1987 requests -> 844 requests
- 1300 ms -> 700 ms
Purpose
=======
The first purpose of this commit is to add a test ensuring the number of request while creating
a company leave for 100 employees, if 15 of them already have a leave during that period.
It includes, the mass leave generation, and the conflicts resolutions. (Cancelling/Splitting the
already existing one and adapting the dates accordingly).
The second one is to reduce the number of request for this test.
In term of requests, currently we have:
- 5154 requests without bypassing the mail tracking + the activities management
- 1987 requests when bypassing the mail post-process (this is the current value, the bypassing was
already done several month ago)
- 844 requests with all the optimization done in resource/calendar/hr_holidays
In terms of execution time, we have a reduction from +- 1300 ms to call the method action_validate
to +- 700 ms
As the performances issues severity increases with the number of leaves to create and the real time access
to the database, on the production base, we reduced the execution time to generate more than 500 hr.leaves
from several minutes to 21 seconds. A fix to avoid deadlock was already made at
https://github.com/odoo/enterprise/pull/10740/files
Some contortions were made to avoid changing a signature method in a stable release and thus
introducing for each method a second one, with the "batched" implementation, to keep a retro-compatibility
for the existing custom code.
But surely this could be cleaned in the master version. The old one will be deprecated while waiting to be
removed in a few versions.
closesodoo/odoo#56534
Taskid: 2256705
X-original-commit: 8c96a887d3f05680c923dcd44f9c70c0e5e0bd32
Related: odoo/enterprise#12670
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit makes use of _origin.id instead of .id into
mrp.workorder.name_get(). name_get() can be called from a compute method
(via _plan_workorders) which implies virtual ids. Searching amongst real
ids with a virtual one was not possible back then.
Task : 2278147
closesodoo/odoo#56469
X-original-commit: 346ecc3a52a7d1c3a2c6409a6799f6b013c3b6da
Related: odoo/enterprise#12641
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
- Go to Manufacturing > Configuration and activate Work Orders
- Create a Product (i.e. Product X) and create a Bill of Materials for it (with a Routing)
- Go to Manufacturing > Operations > Manufacturing Orders and create one for Product X
- Mark as Todo and Plan
- Go to Manufacturing > Operations > Work Orders and open the created one
- In Time Tracking tab, edit Planned Start Date or Expected Duration
The Planned End Date is computed without using the working calendar of the work center.
The working calendar should be used as it was at creation.
opw-2314555
closesodoo/odoo#56290
X-original-commit: 7b70da788d3a222467d88b06324a41e6c6efe605
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Field `workorder_ids` occurs twice in production form view.
Field `production_id` should not be in subview of `workorder_ids`.
closesodoo/odoo#55995
Related: odoo/enterprise#12452
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
- Refactor `order_finished_lot_ids` compute, to be linked to the `lot_producing_id`
the the related production (less boiler plate). We can't remove it because
it is used in mrp_subcontracting, and keep the Many2Many, for the tag widget.
Remove the second field compute by this method, `finished_lots_exist` (never used).
- Remove unused field `needs_lots` (also it is a duplication
with `has_tracking` info) from `stock.move` (mrp)
- Remove unused field `done_move` from `stock.move.line` (mrp).
- Remove unused methods `_strict_consumption_check` and `_update_raw_move`.
- Remove unused variables.
odoo/upgrade#1594closesodoo/odoo#54996
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Issue: when we created a new operation from the MO form,
the default of the expected_duration wasn't take in account and
override to 0.0.
Fix: in `_get_duration_expected` If there isn't workcenter is set,
instead of return False, return the `duration_expected`
closesodoo/odoo#56127
Related: odoo/enterprise#12517
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
It was impossible to add a workorder after a finished one
due to a constraint in the write (can't change next_work_order_id).
Remove this obselete constraint.
task-2278147
Steps to reproduce:
- Let's consider a product.template TP with a kit
- Let's consider the variants V1, the only variant of TP with a kit
- The virtual_availalbe of V1 is 100 (smart button Forecasted in the form view)
Bug:
The virtual_available of TP was 0 instead of 100
The virtaul_available of a product.template must be the sum of virtual_available of all its
variants with kit
PS: This commit changes the available quantity of product_product_table_kit in demo data.
As this quantity was not equal to 0, the type of the product could not be changed.
opw:2297226
closesodoo/odoo#55707
X-original-commit: 4df4ad023b9dd24edf75e8993d1d31c73ce26bc0
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Co-authored-by: Florent de Labarre <florent.mirieu@gmail.com>
This doesn't make sense anymore: when we record production on a WO, in
any cases everything is processed as we make backorders.
Part of: https://github.com/odoo/odoo/pull/54283
task-2278147
Allow to add serial numbers as tags on the move in production order and
stock picking. The purpose is to earn time for database with
only tracking installed.
Also when only create_lots is checked on picking type. New lots
could select existing lot and an onchange trigger a warning if
it's used.
closesodoo/odoo#55883
Task: 2280985
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
- Avoid to truncate the hour/min/sec in the computation of the
effective date which is related to the `date_done`
of the first incoming picking.
- With manufacturing in 3-step (pbm_sam), the store picking
had a source document == "New". It was the case because
the `_get_move_finished_values` was call before the create
and the name is set only on create.
To fix this issue, during the `create` set the origin of all move.
- To avoid to maintain old views unused,
remove unused view of stock move.
- The computation of the products_availability json is too expensive
to be in tree view (2.5 times long with it) of picking.
It will be hard to optimize because the half the time
is due to _get_report_lines method - already in batch (on 80 records).
- Review buttons of the replenishment list to be more Odooer.
- In some cases the delay alert date was wrongly compute:
- If we new dest_move_ids of a existant move, the delay alert date
won't be compute.
- If the state (to done) and the date are save in same write call
the alert date of next move won't be reset.
To avoids these issues, refactor the alert date to be a compute stored
fields.
- To avoid any confusion between date expected in the replenishement
(in date) and the purchase order receipt date (datetime),
we put the receipt date at the middle of the day.
Also On-Time Delivery Rate computation counts
only when date are bigger effective date trunced to date.
Also used the timezone of the company by default (if not user timezone)
task-2246665
closesodoo/odoo#55379
Related: odoo/upgrade#1586
Related: odoo/enterprise#12309
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
- The deadline of MO generated via procurements is calculated differently.
Now, it doesn't take anymore in account the manufacturing_lead
of the company (Security Lead Time of MO). The computation of planned date remains unchanged.
- The date_expected fields was duplicated with the date fields
except when the move was done. Merge both fields.
The only information lost is: we can't know what was the
scheduled date before processing move (`state` == done).
Indeed, the date becomes the actual move processing datetime.
- The `date` in `stock.picking` field contained the time of
(purchase) order `date_order` (`purchase.order`).
This field is was wrongly used in the kanban view where we
expected to see date_planned instead. Also, the `_order` used
this date instead of date_planned too.
- The `delay_alert` is activate independently of stock rules.
Then it is now activate in all case.
- Remove the auto-reschedulting process of stock move via
the stock rule (`propagate_date` and `propagate_date_minimum_delta`).
Replace it by a automatic deadline date (`date_deadline`) propagation.
The deadline is the promise done to/by vendor/client (SO/PO)
then it is a readonly fields on picking/move and MO.
- Now the Scheduled date (`date`) of stock move is never propagate
and it is only related to the Scheduled date of
related document (MO or picking).
- Now when a move is created from procurement (sale),
`date_planned` = `date_deadline` - `security_lead`.
- The `delivery_date` of sale is no editable after confirmation
and propagate as the deadline to related stock move linked to order_line
- Adapt filter and decoration of MO and picking.
- Because we are the client in case of purchase (PO), the promise of vendor
can be not respected. Then we add the lead security to the deadline
(inverse the sale order logic) of PO picking (promise reciept date
+ security lead) to match with the replenishment.
task-2246665
- MO/picking/PO/stock.move have now the "same" `priority` fields
(Boolean logic: Normal or Urgent).
These models are now sort by priority first. Note that the priority field of
stock move is a technical one.
- For MO and picking, the set of `priority` field change priority of
the related stock move. The prioriry field on stock move is
used by the scheduler for reservation ('Urgent' before 'Normal')
- The Stock Replenishment Report also take in account the priority
to be consistent with the reservation.
task-2246665
Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
The purpose of this task is to improve the UI of the 'Apps', by
improving the clarity of the kanban, sequencing the apps and
simplifying the app categories in the searchpanel
So in this commit, Added the new sequences for ir.module.module
and ir.module.category records.
TaskID: 2240257
Related Enterprise: https://github.com/odoo/enterprise/pull/12413Closes: #55907
Replace wrong usages of any(list|recordset), by any(generator)
to speed up computations, avoiding list creations and/or looping twice on a recordset
for nothing.
any([generator]) => any(generator)
any(filtered) => any(generator)
closesodoo/odoo#55768
Related: odoo/enterprise#12360
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
PURPOSE
Review the tips and digest layout design to make sure they have a WOW effect
and increase trial conversion/retention.
SPECIFICATIONS
“Use tablets in shop to control manufacturing”
See code for specifications.
LINKS
Task ID-2274264
COM PR: odoo/odoo#53580
ENT PR: odoo/enterprise#1139
X-original-commit: 40100145e5bc8b2588b04b849a2c2cc306e126d3
In stock:
1. remove string of action_show_details button, only show icon
2. late filer have been megered with planning issues filer,
update the name. (also in mrp)
3. add width to json_lead_days_popover field to show it properly
4. change inventory adjustment empty screen image.
In purchase:
1. in reminder mail, show "undefined" when no date. This will
only be shown in preview. When no date, we won't send reminder mail to
the vendor.
2. remove old book icon for document in setting.
3. check if there is date_planned when craete a confirm date url
4. RFQs late filter now show all late RFQs with in state "draft",
"sent", and "to approve".
5. improve the the words in KIP and empty screen and list view
Task 2298950
PR #55155closesodoo/odoo#55740
Related: odoo/enterprise#12344
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Case:
- create a MO for 3 units
- produce only one but with more than a third of the components
- the flexible consumption wizard is triggered, accept and make the
backorder.
- Mark as done the backorder, the immediate production wizard is
triggered, accept it.
-> the flexible wizard is triggered again as the components quantity do
not respect the BoM. In this specific case, we want to consume all the
remaining component so we would like to avoid the flexible warning.
Task : 2278147
Commit 47e40e7f6a set a default value for
the stock moves initial demand (default_product_uom_qty). The issue is
the stock_move_line models also have a product_uom_qty field. This field
on the line is also st to 1 in the default get. Which is non desired side
effect.
This commit adds another default_product_uom_qty equals to 0 for the
stock move lines.
Task : 2278147
Starting a workorder should update the scheduled date only if the production
is started sooner than expected. In this case we want to clear the
calendar for the other production. If the production is started later
than expected, updating the calendar has no effect. We leave the
scheduled date unchanged to keep the information
Task : 2278147
This commit:
- Show 'Plan' button even in to_close state
- Move UoM column after quantity done one (like in stock)
- Hide lot_producing field in state draft
- Hide production locations if multi location groups is not set
Task : 2278147
With this commit, the move raw refresher onchange is bypassed in case of
empty BoM. As the manufacturing user can adds some components on the fly
to create a non manufactured product, changing the quantity to produce
or the unit of measur will erase all the move raw and recreate them from
the BoM lines. As no boms are set, the components are just deleted.
Task : 2278147
The _plan_workorder function is callable for the production order list
view. Calling it on production without workorder make no sense and can
even crash.
This commit bypass it in those case
Task : 2278147
Updating the quantity to produce on a production order will recompute
the expected production duration. This can be counter productive on
prototyping production when no BoM are given. The default expected batch
duration is set to 60 minutes. Setting the actual production time then
updating the quantity to produce will naively change the duration to
60 x the new quantity.
This commit compute the duration pro rata in case of 'no BoM' production
and recompute everything in case of BoM production.
Task : 2278147
Before this commit, only the moves raw were copied on production
duplication. As the finished move is created normally in an onchange,
this means a production order duplicated have not any move finished.
Task : 2278147
Changing the Bom on a production order will erase all the raw moves to
recreate the new ones. This commit make sure the finished product are
erased as well.
Before this commit, if the product was changed with the BoM. The first
finished product became a byproduct for the second one.
Task : 2278147
On a production, additional are supposed to be linked to the current
lot/serial number and not to the total production like the raw component
on the BoM.
This commit do not split stock move for those product anymore at the
backorder creation.
Task : 2278147
In a scenario parent mo <-> child mo, delaying the production start on
the child mo will delay the parent start but not the parent's workorders
This commit will replan the workorders each time a planned production is
delayed.
Task : 2278147
This commit introduce the immediate production mechanism. As it works on
stock.picking, marking a (some) production(s) as done without consuming
anything will pop a wizard allowing the user to transfer all the reserve
component quantities as done quantities.
Task : 2278147
- Default quantity on MO is 1.0
- Default quantity to consume on move is 1.0
- No open on the company_id from BoM form
- Optional=Hide for product, qty on BoM form
- Backorder button renamed to Validate
- Date deadline and origin to Miscellaneous tab
- Be able to remove stock_move when the MO is draft
- Some renaming in the menu and run scheduler under planning item
[FIX] mrp: fail to create stock.move after MO confirmation
Since the product_id on stock.move is readonly once it is set and the
MO is confirmed, it's not send to the server and the create crash
since product_id is NULL.
closesodoo/odoo#55270
Related: odoo/enterprise#12148
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Martin Trigaux