Use the new Many2OneAvatarUser field widget in some kanban views,
which allows to open a DM chat window with the corresponding user
by clicking on the avatar.
Part of task 2195254
Set the padding on the write for date. Modify the text to be consistent
with the manual and automatic orderpoint. Explains the min, max
and quantity to order mechanism.
closesodoo/odoo#48536
Task: 2161378
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Allow to set a BoM or a vendor on an orderpoint. In this case it's
passed to the values and will be processed by _run_buy and
_run_manufacture to use them.
Task: 2161378
Usabilty. Move the route button under the route params.
People had issue with route and didn't know that this
report exist. We hope that moving it under the route will
help user to configure their route.
Task: 2161378
Set a default route on orderpoint created by the replenishment report.
First it select the first route on the product if it exists (it's
uselss since it's a preferred route on the report but it's used for
clarity). If the product has no route then it tries to guess it
with vendor pricelist or BoM on the product.
Task: 2161378
New report to easily order missing products in each warehouse.
Orderpoint have a new type: 'manual'. Manual orderpoint are not
trigger by the scheduler but the user could create replenishment
from the report directly. The report use the forecast report in
order to detect missing quantity for today (it does not search
depending the lead time for each product warehouse due to lake
of performance). It compares missing quantity with incoming RFQ
and other ongoing orderpoint. If it still missing a new entry
for replenihsment is created (it's also automaticaly deleted if
the replenihsment has been done another way).
Task: 2161378
1. Set Decimal Accuracy of "Product Unit of Measure" to 6
2. Create new Unit of measure: "Thousand(s) of units", with ratio 1000.0
3. Set accuracy for Unit(s), Thousand(s) of units, kg to 0.000001
4. Create two products: "parent" (UoM: Thousand(s)) and "child" (UoM: kg)
5. Create Bill of material: parent needs 0.12 of child
6. Add 10000 of child product to stock
7. Create manufacturing order for 100.123456 of parent product.
8. Click "Produce".
The decoration of the lines is incorrect.
This happens because of Float representation at the JavaScript level,
leading to comparison such as:
`12.014999...8 < 12.015000`
It's not possible to use some kind of rounded comparison. As a
workaround, we change the way the float are compared.
opw-2234824
closesodoo/odoo#49559
X-original-commit: f62c2b33fe834defb2c39988f3c9e90047a56d2c
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a product P using one component C
- The BOM is flexible
- Create a MO for 10 units
- Product 9 units, but use all components
- Post the inventory
The MO is considered as done, while it should remain in progress.
This happens because the MO state is computed based on the move raw
state. In this case, it should compare the quantity produced and the
quantity to produce.
The material availability is set to `False`.
opw-2220855
closesodoo/odoo#49247closesodoo/odoo#49526
X-original-commit: dd7ef482a1c41f271b133fbfcc3d389d16677da1
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When unbuilding a manufacturing order, there are fields in the default
unbuild form that do not make sense to show (i.e. they already
correspond to the manufacturing order that is triggering the unbuild).
Therefore we make a simplified version of this form that is better
suited for a button generated window.
This change includes removing the resetting of 'location_id' and
'location_dest_id' when they correspond to the 'company_id' by onchange
function since this would overwrite any 'default_location_id' and
'location_dest_id' values when calling the view + this seemed like it
would be annoying if someone clicks on the same 'company_id' within the
dropdown and their location values changed.
closesodoo/odoo#49514
Task: 2234872
X-original-commit: d23341a5b4cb82f4a96b55464dec32dc28ce4351
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this, unable to quick create production lot from
produce wizard in components, as default company was not
set correctly.
Fixes-2234784
closesodoo/odoo#49455
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this commit, check availability button was becoming
hidden, even if move is partially available on MO.
Fixed it.
Fixes-2234494
closesodoo/odoo#49381
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
TL;DR: remember `osv` and `except_orm` ? You can forget about them.
* Deprecated `except_orm` dropped.
* `UserError` elevated as super type of all user-related
errors.
* Unused `DeferredException` dropped.
* Unused `QWebException` dropped (real one is in `qweb.py`).
* `MailDeliveryException` made a python exception.
* `name` legacy exception attribute made an alias of the python standard
`args[0]` attribute and deprecated.
* `value` legacy exception attribute dropped.
* `exception_type` RPC error response key dropped.
* Deprecated `osv` module dropped.
* `--osv-memory-age-limit` cli option made an alias of
`--transient-age-limit` and deprecated.
The `odoo.exceptions.Warning` have long been a deprecated alias to
`UserError`. It is going to be removed in a future version but first we
explicitly deprecate it with a warning.
The `odoo.exceptions.DeferredException` was a very old internal
exception, it has been removed without deprecation notice as it is never
raised.
The `odoo.exceptions.except_orm` has been a deprecated exception type
with deprecation warning for 5 years, it has been removed in favor of
UserError which becomes the super class of all user-related errors.
The `odoo.base.models.ir_mail_server.MailDeliveryException` was
inheriting `except_orm`. As it is not related to a user error but is
more of a problem an admin much take care of, the exception has been
made a Python error.
The `exception_type` JSON key in RPC error responses was holding an
hardcoded value derived from the exception type. Its usage has been
dropped in favor of the `name` JSON key that holds the precise exception
name. Again as it was hardly used in the source code (beside the crash
manager) it has been dropped without deprecation warning.
Since we are here trying to clean odoo custom exceptions, we are also
deprecating the `name` exception attribute in favor of the more standard
`args[0]` attribute.
The `name` (along with `value`) were two attributes used to raise
`except_orm` exceptions before the introduction of `UserError`,
`AccessError` and related exceptions. The `name` attribute, at the time,
was holding the exception type/title. Nowadays it contains the error
message. The `value` attribute, at the time, was holding the error
message. Nowadays it is no more used.
The `osv` module contains very old deprecated aliases. There is no
simple way to log a deprecation warning for osv, osv_memory and
osv_abstract but as they have not been in use for ages, they have been
removed too. To be consistent, the `--osv-memory-age-limit` cli option
has been made a deprecated alias to the `--transient-age-limit`.
closesodoo/odoo#45723
Task: 2187728
Related: odoo/enterprise#9162
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Followup of
https://github.com/odoo/odoo/commit/58df6c86e06304b2c5f020e0fb93988e9e388fe0.
By default, the create, when not specified as `api.model`, supports
creation in batch (thus the batching opportunity isn't lost here).
BUT, if a create override isn't specified as `api.model` or
`api.model_create_multi`, it won't be accessible in rpc calls (because
the ORM thinks a record in self is needed).
It doesn't look like somebody can create stock move lines from the web
client itself, but it doesn't cost anything to follow the global api
(and it's clearer to clearly specify the create as create_multi).
closesodoo/odoo#48964
X-original-commit: a4fd8f8062046bcea97d9f7cfe300e19020cdecd
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
For the `mrp.routing.workcenter`, removes the help from the `worksheet`
field to set it into the view.
This way, the tooltip doesn't appear each time the user cursor is placed
in front of the pdf in the workorder tablet view (`mpr_workorder`).
task-2225362
closesodoo/odoo#48903
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Create a MO for a product tracked by S/N
- Perform the MO
- Print the 'Finished Product Label (PDF)'
The barcode printed is `False`.
If the S/N is not set on the `move_line`, we should fall back on
`lot_id.name`.
opw-2228337
closesodoo/odoo#48949
X-original-commit: fb69b5a99becd92ee0ee7698709da05a0b33850f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Go to inventory>product variants (list view), search for
'FURN_78236'.
Set quantity on hand (qty_available) 50
Now, back in list view, adjust your search to FURN_7
QTY on hand for FURN_78236 is 0.
This occur because during the computation of qty_available, the bom
kits (FURN_78236) are calculated first, but the qty_available depends
on the bom lines products, which are calculated only at the end.
Since qty_available became protected by the global environment, it
cannot be recomputed recursively and it is not in cache, thus is 0.
Making the simple products compute first in the _compute_quantity fix
the issue
opw-2226417
closesodoo/odoo#48924
X-original-commit: f41c650f162021bb6c76736c7dcbe4eee059cec1
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
How to reproduce:
- Open PLM app, open an Engineering Change Order;
- Click on "Update Documents";
- Try to upload a document -> Traceback.
As we did not cast res_id as integer, the check method of ir.attachment
crashes when accessing company_id on a malformed recordset of ECO
because the domain generated by _filter_access_rules_python is:
`['|', ('company_id', '=', False), ('company_id', 'in', [2, 1])]`
This route is also used when adding attachment to a `product.product`.
In this case the check didn't work either but somehow passed because no
domain is generated by `_filter_access_rules_python`.
The following snippet shows that if there was one, it would also crash:
```
In [16]: records
Out[16]: product.product('25',)
In [17]: records.stock_move_ids
Out[17]: stock.move()
In [18]: self.env['product.product'].browse(25)
Out[18]: product.product(25,)
In [19]: self.env['product.product'].browse(25).stock_move_ids
Out[19]: stock.move(41, 13)
```
task-2223153
closesodoo/odoo#48515
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
With this commit, Selection fields with `required=True` which are
extended via `selection_add` are given proper ondelete policies to
ensure the cleanup of records containing these extended options during
uninstall of the extending module.
This commit also cleans up leftover uninstall hooks that were being used
to handle the same set of problems prior to the ondelete mechanism being
implemented for Selection fields.
closesodoo/odoo#46325
Related: odoo/enterprise#9117
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Usecase to reproduce:
- Create a MO as draft
- The stock move inside don't have a reference despite the MO name is
already set.
It happens because the reference and the group are set during the
action_confirm. However it's not great if the user takes time before
confirmation or if he cancels the MO. In those case the reference
on the moves remains 'new'.
opw-2201986
closesodoo/odoo#48568
X-original-commit: 1b7e304a907d8a43d5f561226028a4b353902fab
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Steps to reproduce the bug:
- Let consider a user U from a single company C (Multi companies = False)
- Let's consider a BOM B for a finished product FP with product P1 as component and product P2 as byproduct
- Let's consider that P2 is tracked by lot
- Log as U and create a MO for FP
- Produce the MO
Bug:
A widard was opened but it was impossible to create a lot for P2
opw:2216028
closesodoo/odoo#48556
X-original-commit: 30ebdee091362b8c857bdcad2bdf44bd698572c4
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Creation of production order from a bom with 0 quantity to produce will
fail. As there is already a constraint on the quantity to produce on MO,
this commit adds the same constraint on BoM.
closesodoo/odoo#48485
X-original-commit: 1330500885ae096372ab32fba4ffc9db252dd2d4
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Confirms and plans the manufacturing order created for table (MTO) in
demo data to have already a work order.
task-2199747
closesodoo/odoo#46464
Related: odoo/enterprise#8922
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this commit, some tracked product quantities didn't have a SN/LN.
To avoid some issue at the use, it's better all demo data fulfill
requirements like that.
Task #1970460
Demo data product's quantities are no more put in sublocation as by
default, multilocation aren't active.
Also, adapts `test_location_usage` because as we moved quantities from
sublocations to the main stock location, the stock warehouse will have
reserved quantity due to a backorder created by demo data.
In this test, we try to change location as a scrap location, what we
can't do if this location has some reserved quantities.
Task #1970460
Handle missing barcode for 'pick components' and 'store after
manufacturing' picking types
closesodoo/odoo#47201
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Commit abef168389 adds the fields
'product_description_variant' on mrp.production and purchase.requisition
models. This text is taken from the product variant.
This commit make them invisible in case they are empty.
closesodoo/odoo#47716
Related: odoo/upgrade#948
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
When `mrp` or `mrp_subcontracting` are uninstalled, the routes used as
'Picking Before Manufacturing Route' and 'Resupply Subcontractor' are
kept active. When the modules are re-installed, the routes are created
again, and appear duplicated.
The routes should be deleted if they are not used anywhere else.
opw-2222895
closesodoo/odoo#48206
X-original-commit: ce219b8375dc14daf9d380433d254b622a947773
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Purpose of this task is to prevent users from setting portal users on
internal documents by mistake, and preventing noise and performance
issues resulting from loading all the portal users in those fields.
This commit fixes internal many2x fields to res.users which are now
restricted to internal users by setting domain (share=false) on form view.
closesodoo/odoo#47553
Taskid: 2172779
Related: https://github.com/odoo/enterprise/pull/9204
Related: odoo/enterprise#9204
Closes: #47553
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
* remove global assignation in xml, it is a computed field anyway, let the orm compute it
* put all `ir_rule` definition as noupdate in the xml
closesodoo/odoo#47688
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Purpose
=======
The main definition of 'assignation' is the following:
"an appointment to meet someone in secret, typically one made by lovers"
The correct word we should be using is 'assignment':
"the allocation of someone or something as belonging to a particular group or category"
So in this commit change every iteration of the word
'assignation' to 'assignment', across all modules.
closes odoo/odoo#45041
Taskid: 1966215
Closes: #45041
Related: odoo/enterprise#8375
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
- Change the font-awesome icon from fa-book to fa-question.
- Change the icon color to text-secondary (the same than the multi-company
icon).
- Adjust the icon size to the uppercase text size.
closesodoo/odoo#47210
Taskid: 2209062
Related: odoo/enterprise#9116
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- In inventory app, create an attribute that is dynamic
- Create a product with a variant with the dynamic attribute
- Create a bom for the product with some specific component for that variant
- Open structure and cost
A crash occurs.
In this case, the object is a `product.template`, so a condition
product-specific shouldn't be checked.
The template is set at:
https://github.com/odoo/odoo/blob/3588487ab4ef867f7fb981a395deaf298eb4a4e4/addons/mrp/report/mrp_report_bom_structure.py#L107
opw-2198976
closesodoo/odoo#47769
X-original-commit: 3c476dee5d3a0cc0fde0f9c6620507a07929e4fc
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- create product comp1
- create product finished1
- created bom: 1 comp1 for 1 finished1
- activate PBM
- 100 units of comp1 in stock
- create an MO for 5
- on the pbm, deliver 3 and no backorder
- on the mo, check availability, produce 3
- on the pbm, unlock, change delivered qty from 3 to 5
On the mo, the raw move is reserved to 5 units but the 3 units
used in the first produce are removed.
It happens because editing the quantity or initial on a move
will try to reserve the next moves. In order to reserved,
_do_unreserve will destroy the stock.move.line and _action_assign
(call just after) will recreate them in order to regenerate the
reservation. In the process the qty_done on the stock.move.line will
be loss. We want to avoid this behavior in mrp so we call
_decrease_reserved_quantity from mrp that will keep stock.move.line
with quantity done.
opw-2206472
closesodoo/odoo#47617
X-original-commit: c6cf5841015c87163f8ea16dd75232e5cb855df6
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Adaptation of the code throughout all modules to properly instantiate the newly
refactored control panel and update it accordingly.
Part of task 2196029
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
PURPOSE
Keep consistent behavior of the stat buttons and the different stock
reports when archiving a product
SPECIFICATION
Currently, you can archive a product but the behavior of the different
stock reports, stat buttons isn't coherent afterwards. Here are the
different behaviors that should be improved:
1.Keep quantity on hand and forecasted quantity visible (in the stat
button + when opening it)
2.Automatically (un)archive RR and BOM if the product is (un)archived
3.Valuation report: show the archived products without the "archived"
filter (behaves already this way in the inventory and forecast reports)
4.When a product has been archived and still has quantity in stock,
include it in inventory adjustments for which counted quantity = default
to stock on hand (dont do so for archived exhausted products).
Also, revert #47478 since we don't have active field.
LINKS
Task 2178269
PR #45586Fixes#41634
Related: odoo/upgrade#811
Related: odoo/enterprise#8513
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Allow to propagate custom information to upper document. It could be
usefull in many buisness that do custom stuff for people
(t-shirt with user defined text, poster with own pictures...)
The customes values are pass throught procurements'values and are
display on MO or purchase order line.
Task: 1970476
Make it so documents auto-generated by other actions have Odoobot set as
the creator rather than the user triggering the action. This includes
the following documents:
1. Delivery (stock.picking) - generated by Sales orders (including MTO)
2. Purchase orders - generated by dropshipping, manual replenishment,
and run scheduler
3. Manufacturing orders - generated by made to order (MTO)
This is addresses specification 2 of overall usability improvement task.
Task: 2041853
This commit updates product, stock and manufacturing views for improved
usability. Handles view only changes of overall usability improvement
task. Specifically spec numbers:
1. Add "Run Scheduler" (from stock) to the manufacturing app under operations
5. Make "detailed operations" wizard modal have more intitutive footer
buttons (i.e. don't say "Confirm"/"Cancel" when changes aren't
possible.
8. Rearranging of vendor pricelist view
9. Updating of tooltip content for "property_stock_account_input_categ_id"
Task: 2041853
In this commit,Add a attribut "delete" in mrp workorder gantt view
to disable Remove button on "Planning by Workcenter" gantt view.
task-id:2206166
closesodoo/odoo#47064
X-original-commit: 669408f8b1e760a815e212d9e9fab8663e665dd6
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
For stock, purchase, repair and mrp modules, do a small clean of ACL:
Remove duplication and useless line.
Also improve the readability of the stock traceability report.
task-2172399
closesodoo/odoo#45055
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Create a products A
- Create a products B
Tracked by lot
UoM: kg
- Get some quantity in stock for B
- Create a BOM for A: 2g of B to produce A
- Create a MO for A, Produce
In the lot registration wizard, 2kg of B are suggested instead of 2g of
B.
In this case, the UoM of the product is taken instead of the move.
However, it should only be the case if the product is tracked by unique
S/N.
opw-2200263
closesodoo/odoo#47019
X-original-commit: 9d114eb7a48b82b76e9c900cce22dc5022206367
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Purpose:
Modernizes and facilitates files upload in manufacturing app.
In this Commit:
- Show the image in Kanban.
- Allow to access a preview of the file when clicking on it in the
Kanban view.
- Add a 'Edit', 'Delete' and 'Download' in kanban card dropdown menu.
- Add Upload button in control panel to upload document which will
create new record of `mrp.document` and also add a testcase for it.
task-1960733
closesodoo/odoo#42168
Related: odoo/enterprise#8977
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Steps to reproduce the bug:
- Create a MO
- Click on 'MARK AS TODO'
- Update the quantity to produce
- Produce the MO and click on 'MARK AS DONE'
- Unbuild the MO
Bug:
A traceback was raised because finished_move was not a singleton.
opw:2199529
closesodoo/odoo#46765
X-original-commit: a48573f3089bf78892f90df1dc883a257d047312
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Commit a4c0994 uses variable `qty` as input parameter but override it
at each loop iteration. The original value of `qty` is lost after the
the first pass and so give wrong results for all next iterations.
This commit uses another name to never lose the given value.
closesodoo/odoo#46587
X-original-commit: e1c30bceba6d47d8e087e540f995a02086fa6283
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Aaron Bohy