Purchase
- When a RFQ is in "To Approve" stage, on the printed pdf, keep "Request for Quotation" as a title
- "Send Reminder" action should open the composer when triggered manually.
Inventory
- In tree view of transfer, set date_done optional = hide
- In (mobile) picking view, replace button text with 'add a product'
- fix Vendor Group by in Replenishment report
- Warning message when changing product tracking from untracked to tracked
MRP
- Reporting > Manufacturing Orders : change measure for total quantity grouped by scheduled date = month and by product
- Reporting > Work Orders : change measure for Duration per unit grouped by workcenter and by product & add unit (minutes)
- Reporting > Overall equipment effectiveness : group by loss reason added to the current group by workcenter
closesodoo/odoo#57036
Related: odoo/enterprise#12926
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
The _compute_is_planned() method was only triggered at the workorder
creation and not at the modification of date_planned_start or
date_planned_finished.
This commit change the depends fields to trigger the compute at right
time.
closesodoo/odoo#60620
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
The feature was actually not working as expected. It has been fixed,
and a test now ensures it does work as expected. This commit also fixes
some invalid parameters, hopefully nothing critical.
closesodoo/odoo#60429
X-original-commit: 231bdca3f26d96f578503694e5aec062de2317ed
Related: odoo/enterprise#14285
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before this commit, links to the documentation were referenced the
previous version, 13.0, instead of the current one, 14.0.
Eventhough there is a redirection done by NGINX of a "versionless" URL
to the latest one (e.g. /documentation/user/general/auth/google.html
-> /documentation/user/14.0/general/auth/google.html as of today), the
goal is to keep links owrking for users that will still be using the
14.0 in three years (and should not endup on the 17.0 doc).
closesodoo/odoo#60228
X-original-commit: 7ac08486d91d0ff0151abeeda057ffa6beda72e8
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Behavior before the fix:
- When uploading an office 2007 attachment (.xlsx / .docx) as a regular
(non admin) user, the preview shows it as text, and the download option
by default saves it as a text document (in certain browsers, at least).
This stems from an over-aggressive check on mime type (anything that
contains 'xml' **anywhere** in the mime type is taken to be XML, but the
mime type for an Office document is
`application/vnd.openxmlformats-officedocument.wordprocessingml.document`
so it falls in the XML case.
Behavior after the fix:
- The mime type is preserved
- Mime type for XML-like documents (including HTML and SVG) continues to
be validated
opw-2352712
closesodoo/odoo#60164
X-original-commit: 2820ec7d5763a5856274709a4d2024267313106b
Related: odoo/enterprise#14168
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Nicolas Galler <nicocrm@users.noreply.github.com>
When select a BOM in the field, now we only search by the finished
product name. In this commit, we will also match the reference of the
BOM.
Task 2326786
PR #57945
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Current behavior before PR:
It is possible to create a BOM that has a BOM line that reference the
same product as the BOM itself. This is undesirable as when we create a
manufacturing order for this product we will have an error.
It is a regression bug that was introduced in commit
575353e251a0cce3bbff759edaeb56b5718beb11 between v12 and v13.
Behavior after PR is merged:
When saving a BOM it will validate that no product line references the
same product, or the same product variant, as the BOM itself. Note that
it is allowed to have a BOM for a product variant that references
another variant of the same product.
opw-2347941
closesodoo/odoo#59633
X-original-commit: 917e4c67b4aa14ca71ec6cba4bc6d20a86459f42
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The Duration Per Unit should be averaged, not summed.
opw-2353041
closesodoo/odoo#59446
X-original-commit: 54b40f1eb096ea9531f1f9b0478937536c8292fc
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit makes sure we do not try to update the quantity on a
finished stock move (during record production or confirming the produce
wizard) if there is no finished move available.
Closes#57227closesodoo/odoo#59430
X-original-commit: 141df3b398aee2bac10e3ce94e15bb4bd14d17af
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Before this commit, when copy a workorder, the real duration was copied
too, which is unwanted.
task-2328830
X-original-commit: 6063bf7576a0abf975c2668ebacb6ad68c24315e
Optional hide on `bom_product_template_attribute_value_ids` ("Apply on
Variants") BOM's component lines list.
Optional hide on `lot_ids` field in MO's component lines list.
task-2328830
X-original-commit: 48710bf6f50514aa0c95104989eb44450ce59529
Add a `default_product_tmpl_ids` in the context on the BOM operations
field. The purpose is to have the product set by default when creating a
new operation's step.
Used by 91e53397812e707611d2f430c7d534e215f8fd4f (enterprise)
task-2328830
X-original-commit: 7fe3ce4a1b2c43188b907fdec0553cf995e57bab
Before this commit, there was some bugs with MO by-product moves:
- When creating a new MO, if user deletes the byproduct move(s) then
save, the byproduct moves will be come back.
- With a newly created MO, in edit mode, increase the qty. to produce:
-> Creates a new byproduct move with updated quantity to produce
instead of update the existing one.
These issues was due to the fact when computing the byproduct moves on a
virtual record, the original move in `move_finished_ids` and its
counterpart computed in `move_byproduct_ids` have different virtual id
and so aren't considered as the same move.
X-original-commit: c1768d00e8eb76af32ead10f75ce3d09a5aefac9
Before this commit, Label *Unit Cost* was displayed in the footer for *BoM Structure* report which is not displaying any cost Information.
With this commit we hide *Unit Cost* on *BoM Structure* report.
closesodoo/odoo#59356
X-original-commit: 9ec465e7d3937450bad795cdb69eae52b540b994
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
And other reported English mistakes in source string
Courtesy of Transifex translators
And remove leftover from gengo
closesodoo/odoo#59022
X-original-commit: 26efc84c5cac47a2cc83d7b084f8b71528fec6c7
Related: odoo/enterprise#13781
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Including demo data this time
closesodoo/odoo#58862
X-original-commit: 575abde110acb3d12b25f177a863374becef0894
Related: odoo/enterprise#13705
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Like was done in 8d62eacfff for the
picking model, we remove the `components_availability`
and `components_availability_state` which
can leads to performance issue in case there are a lot of
productions/stock move. Replace by the old reservation_state field.
A performance quantification is required to reintroduced
these fields in views (task-2348553).
Also a fix is done in the stock_picking computation
of `products_availability` and `products_availability_state`
(same nature than these in `mrp.production`).
closesodoo/odoo#58856
X-original-commit: 0a19921e3a50faa8175e973a1edb49100826a9d9
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
This commit change the _split method to return new move values instead
of create it and confirm it.
This allow multi creation and multi confirmation when every move of the
recordset are split
Task : 2076873
closesodoo/odoo#58594
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
- On `mrp.production`, remove `workorder_done_count`
unused since mrp v14
- On `mrp.workorder`, remove `use_create_components_lots`,
unused since ed7012e8fd
Co-authored-by: Feyensv <vfe@odoo.com>
It appears that if you update a record more than once in the same
PostgreSQL transaction, PostgreSQL is going to re-check all the
constraints on the table.
** THIS IS THE PART WHERE THE BLACK MAGIC HAPPENS **
We combine the setting of the default value of stock.move.unit_factor in
the same UPDATE query to avoid the constraint re-check; it saves
approximately 60% of the SQL running time in my case.
** ... AND NOW YOU CAN SAY: WHAT THE F...?! **
Thanks to @rco-odoo for the tip; he knows it from the wise @nseinlet.
X-original-commit: 8e47e2f605309c8ed0d5509f7bb070528d8f32c4
Before this commit, installation of MRP in a database with 4.8M
stock.move + 4.8M stock.move.line was not possible at all.
The process lasted for a very long time (>90 min in our tests) then
eventually failed after using the whole RAM of your server.
This commit allows installing MRP in databases with large stock.move /
stock.move.line tables by bootstrapping the slow parts in SQL.
A more general fix regarding the time complexity of some parts of the
prefetching algorithm is coming later in 13.0-init-computed-fields-rco
opw-2281585
X-original-commit: 549de5601efdad3ebdb03feb8beb1e898f80113a
Usecase to reproduce:
- Launch 2 procurements for 2 manufactured products.
Only the last MO created has finished moves.
It happens since the list is wipped at each iteration.
closesodoo/odoo#57972
X-original-commit: d654c05f3e06898a5de025c1b830ba29c039f781
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Add back the default filters when opening the WO view from the work
center kanban views.
opw-2329401
closesodoo/odoo#57813
X-original-commit: 15ed2b92b83929becfd50334c7a31282c46d44d6
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Remove the json_forecast of the sale order line,
it was a duplicate of information with the qty_at_date_widget.
But improve this one:
- Use the forecasted move information in case of confirmed SO.
- Change the icon (i) to chart.
- Link to the forcasted change to target new forcasted report
(Unfortunately we loose the feature to see components product forcasted
of a kit)
- Change information print in the popover in case of confirmed SO.
Also refactor the json_forcasted of `stock.move` into multiple fields
to avoid to dump/loads for other model who needed the forcasted data.
task-2324039
closesodoo/odoo#56425closesodoo/odoo#57526
Related: odoo/enterprise#13063
Related: odoo/enterprise#13160
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
- Add a minus before quanity if it describes a output move.
- Remove intermediate section "Pending Incoming Documents" and
"Pending Outgoing Documents". Change other label to be more descriptive.
- "Current Stock" in "Inventory On hand".
- Add line "Inventory On Hand - 0" If no other line
specific it explicitly.
task-2324039
date_deadline of the stock move has been reviewed:
- Now, it represents the datetime when the operation must
be done to be in time for the uppest document (SO/PO/MO/RR).
- At the creation of stock move the date_deadline is computed in
the same way than the sheduled date expected that it is not include
security days (inverse the logic for PO).
- When we update the delivery date (or lead time) of SO (or PO).
The deadline of related stock move is updated and the delta is propagate
between origin and dest moves.
task-2324039
Was not super visible, especially without HR as the dialog immediately
closes (limitation of the web client), or when an administrator user
massively disables totp.
Show a toast notification indicating the success of the action.
Also fix the logging of `totp_disable` so it correctly handles being
called on more than one record, and change the logging data to
<browse_record> (<logins>) across the board.
Also add a way to provide an action to execute after a notification:
by default nothing happens, which leads to dialogs not closing and
forms not reloading, and there is no good way to show a notification
and/then do some other thing, which is inconvenient.
This commit does 3 things:
1. When 'action_confirm' is triggered in a manufacturing order, any
'move_raw_ids' (components) that are unable to be fully reserved
when `action_assign` is triggered will be checked for an automatic
reordering rule (RR). If a rule exists it will be auto-triggered.
This includes subcontractor manufacturing orders. Relevant test
updated to match this.
2. When a MO is completed, auto check if there are corresponding
confirmed stock moves that can be populated by the completed products
and trigger their 'action_assign' to reserve the completed products.
3. If a new move line is added to an already confirmed MO, then do same
auto-RR check/trigger. (note will occur for pickings without extra
code since `stock_picking.action_confirm` is triggered again in this
case.)
This reuses similar logic as odoo/odoo#52433 from task 2244230.
Originally this was done in the `action_assign`, but has been moved to
`action_confirm` so as to imitate the now archived MTO process with RR.
Overlapping logic has been moved into stock_move for easier reusability.
Note that this now means editing existing moves' `product_uom_qty` (i.e.
Demand) will not have a flow to auto-trigger their RR.
Subcontracting test updated to match + new mrp test added for this new
feature.
closesodoo/odoo#57334
Task: 2322496
X-original-commit: 2688cd1bae489b1dec8862f4de727ac20514844c
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
In case of manufacturing a product tracked by serial number,
there is no reason to be able to make it with a different UoM of
the product (which lead to rouding issue).
Then when we confirm the MO in this case, the UoM and quantity
will be converted to product UoM.
PR #56000closesodoo/odoo#57333
X-original-commit: f0da27e7eb474e6db4cd999306c420804aaa6f9b
Related: odoo/enterprise#13059
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Change the default rouning digits of all UoMs to be two, also change the
decimal.precision of UoM to be two. Adapt all the tests.
Also to avoid hardcoded digits in `should_consume_qty` widget.
PR #56000
X-original-commit: 460ec0402a2352a5b179d81935f7230f6bc97cb7
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#57325
X-original-commit: 74b762da63e159b1965428b2bcb972293c4efea6
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Co-authored-by: Florent de Labarre <florent.mirieu@gmail.com>
Mainly transifex issues but also some errors found through 'grep' checks.
Fix typos and obscure english strings in xml contents, fields strings/helps, some docstrings, ...
ensuring correct translations base (and fallback when translations isn't available).
closesodoo/odoo#57276
X-original-commit: 4214f05d454bca2b60fda3a288d529c098e84f77
Related: odoo/enterprise#13053
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Currently on branch saas-13.5
Without demo data
closesodoo/odoo#57168
X-original-commit: 32f752b486053b19a8c6167efb5ca0813f2bf3f8
Related: odoo/enterprise#12997
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
tracked
On production order view, dot not show the Serial Numbers column
when in draft or when no component tracked by serial number
closesodoo/odoo#56889
X-original-commit: 4fc8374ee4470a05b27216999e341418e72f28ea
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
When a user is accessing a work order in state ready, we are updating it and
rewriting date_planned_start field. We also update accordingly the associated
slot of the workcenter calendar (leave_id), but if the ressource of this slot
is linked to another user, a record rule on resource.calendar.leaves is preventing
the update, which should occur without error, even if the user does not have
Time Off / All Approver rights.
closesodoo/odoo#57120
X-original-commit: 790fb1820fbd49d07206963077216cc304ed2b0a
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
Various attributes use state field to control display of nodes: like the
'states' (visibility), statusbar_visible (available status in status bar).
In this commit we fix various incorrect state values as those are either
typos, either references to dead or removed status.
An heuristic to detect invalid state for conditions will land soon in master.
As this commit targets a stable version only view fixes are provided.
Task ID-2329114
PR odoo/odoo#56946
X-original-commit: b4e1e9f3ae86e6b5e7015c0241791f733ee942f4
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>
Martin Trigaux