*: crm, digest, hr_expense, im_livechat, mrp, purchase, sale_management,
website
The images in the digest email are updated to have the look of the new
"Milk" Ui. We want to keep names unique, as they target different
versions. That way we can keep a v15 oriented gif for people using tips
in v15 for example.
The mobile phone image is hosted on odoo.com.
task-3338467
X-original-commit: odoo/odoo@3711d2b61b
Part-of: odoo/odoo#158351
A subcontracting BoM sometimes shows negative values in Overview, if
components are available in subcontractor's location.
closesodoo/odoo#144702
Task: 3607854
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Commit [1] moved (almost all of) the code of formatFloat from
views/fields/formatters.js to core/utils/numbers, to make it
accessible in the frontend. A formatFloat function was kept in
formatters.js to handle the false case, which makes no sense in
number utils, but is useful for fields. However, a lot of imports
have been updated to use the numbers.js instead of formatters.js
(i.e. they no longer benefit from the support of false), whereas
they are actually formatting field values, so they should have
kept using the formatFloat from formatters.js
This commit adapts the places where the formatFloat to use must
come from formatters.js, not numbers.js.
[1] https://github.com/odoo/odoo/commit/054ca0a19aaf297f420a1b478b93ae26f1b943b8
task 3722043
closesodoo/odoo#152810
Related: odoo/enterprise#55919
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Have a product template with bom
Ensure the product variant has not the same id of the template
(Add and remove a template variant)
In the product page > Hit "forecasted" smart button > "Manufacturing Forecast"
Error will raise:
Missing record
Record does not exist or has been deleted.
This occurs because when opening the Manufacturing Forecast from the
template product we are searching the variant using the id of the
template product
opw-3636661
closesodoo/odoo#151776
X-original-commit: df7b80f24bc6ef20d3aea25e9597807f5a6a0195
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
This reverts the following commits : https://github.com/odoo/odoo/commit/fe508c6b2cb1b92d7b063cc194a3dad37f4eb255
The behavior for tracked products is different; the quantity is modified
in a wizard by adding other `stock.move.line`, which does not trigger
the change of the 'picked' field to true and makes the behavior
different from non-tracked products.
We prefer to remove this fix and keep the same behavior for all types
of products. The user can manually select the checkbox for the 'picked'
field.
Update the optional show for the field “picked” in the MO form
closesodoo/odoo#147695
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Does 2 things:
- ensure that the "free_qty" doesn't display a negative value (=>
consistent with MO overview + avoids neg "Ready to Produce" values)
- ensure that showOptions.availabilities is always a Boolean and never
"undefined" (=> avoid traceback when opening overview while in debug
mode)
closesodoo/odoo#140767
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Previous to this commit, the qty reserved was only considering the
currently reserved quantities in the MO, not the ones calculated and
displayed in the MO Overview (i.e. including the quantities reserved in
the picking during 2 step mrp). This would lead to showing reserved
quantities but a "Not Ready" status, which is confusing and
inconsistent.
Now we pass the calculated component quantities to the method that
calculates this state and ensure the calculation is consistent.
Steps to reproduce:
- enable 2 or 3 step mrp
- create an MO with a component that is in stock at the stock loc
- confirm MO and open "Overview"
Also change "Quantity" back to "Reserved" in the pdf version of the MO
Overview. This was a mistake change since this column name already
exists and "Reserved" will be hopefully less confusing for users.
Part-of: odoo/odoo#140767
This commit fixes:
- hide `read_duration` and `expected_duration` in MO list view.
- hide `component availability` byt default in bom overview,
unless if coming from mrp forecast.
task-3547356
closesodoo/odoo#140244
Related: odoo/enterprise#49802
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Commit a97b352e761b421f6205b03a9b87c79358c128cd removed MrpProductionComponentsX2ManyField
to use MrpProductionComponentsListRenderer for coloring quantity cells
for manual consumption. Correctly extend StockMoveX2ManyField in this
commit.
closesodoo/odoo#140141
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
The rational is:
Currently we have 2 columns. One for reservation, the other
for quantity picked.
However in real time, either you follow the reservation and everything
goes well. Otherwise you pick something else. In the case where you
pick somewhere else than reserved, you would like to modify the
reservation to have something similar and free the quantity you
didn't pick and expect the system to not suggest the ones you took.
In other hand, we always want to have the reserve quantity similar to
the done.
On top, having two columns could be confusing for the end user.
The cons:
-The qty_done column could be use during the picking, to
remember if something has been pick or still to pick.
- For some flow (put in pack), it's easier to write a part of the quantity to pack
and still want to reserve the full amount of product.
We goes back and choose a ligther interface over complex feature.
Changes:
Qty done and reserved qty are merged into a single column.
A new checkbox on the move exists to mark it as picked or not
Since the reservation always follow the quantity, it's now possible
to have more reserved quantity than stock. However the system will
never propose it and the inventory showing reserved > quantity should
be a warning.
The system should never modify a move that has been picked. We don't
want to overide the user action.
Regression:
Not able to pick a single stock.move.line
closesodoo/odoo#137864
Related: odoo/enterprise#48709
Related: odoo/upgrade#5310
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
The point of the MO Overview is to be a single place where you can
quickly get all info for a single Manufacturing Order.
Since we have all data the cost_analysis is already fetching, we add
those data in the report when the production is done.
Also use the Stock Valuation Layers when available for component costs
to better reflect the real cost of production.
Task-3251506
Part-of: odoo/odoo#114536
Have the "MO Cost" column mean the expected costs following *this*
Manufacturing Order.
Rename "Product Cost" into "Real Cost" and have it represent what where
the actual registred costs for this MO.
This allows for a quick comparison against what was expected and what it
really cost.
Part of task-3251506
Part-of: odoo/odoo#114536
Adds the `By-Products` section in the MO Overview as done in the BoM
Overview. This allows to correctly factor in the cost share of the
production's byproducts.
Part of task-3251506
Part-of: odoo/odoo#114536
The aim of this commit is to improve the impact and rendering of app
icons in bright and dark mode. It also reduces the size of svg files.
To achieve that, this commit updates the colors to flat colors. This
change will make the icons stand out and improve their readability.
task-3072562
X-original-commit: 667a19162b74fb6554a2389ba9c6e69de4ff5113
Part-of: odoo/odoo#138279
To reproduce:
1. Open the shop floor
2. Open assembly station 1
Current behavior:
The MRP timer immediately causes a traceback when being rendered in the
shop floor.
After the changes in [1], the duration was changed to a property on the
timer component.
However, the duration is set on multiple occasions, including in the
onWillStart function of the timer component, resulting in the traceback.
Expected behavior:
This commit addresses this by reverting the changes from [1] for the
duration on the mrp timer, and using useRecordObserver instead of
onWillUpdateProps.
[1] https://github.com/odoo/odoo/pull/135842
Community PR: https://github.com/odoo/odoo/pull/137561closesodoo/odoo#137561
Signed-off-by: Steve Van Essche <svs@odoo.com>
Before this commit, owl was in the linter's accepted global variables.
This allowed direct access to owl global object.
For instance, to use xml from owl, you could do :
`const { xml } = owl;`
or you could use it directly:
`owl.xml`
Now, owl is not accepted on linter's global variables anymore, so to
import xml, now you need to use a proper import:
`import { xml } from "@odoo/owl";`
task-id 3498859
closesodoo/odoo#137517
Related: odoo/enterprise#48364
Related: odoo/design-themes#709
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Steps to reproduce:
- Create a two-layers Bill of Material (BoM and child BoM).
- Create a Manufacturing Order with the top-level BoM and open the
Overview.
- Click 'Unfold', then hit the 'Replenish' button on the component.
- Select 'Manufacture' as preferred route and confirm.
Issue:
The newly created Manufacturing Order is correctly added in the report
but already unfolded, which can greatly change the visibility of the
report if it has lots of components.
This is due to an `undefined` value in the ComponentsBlock fold indexes
as they were not updated after the new props update.
closesodoo/odoo#137613
X-original-commit: 9dc2425dc69c1797cb85ecd794019ea44c541334
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Commit 4da8c6ebca change the way the
detailled operation of a stock move is openned. This has been done only
for the picking. This commit adapts the
MrpProductionComponentsX2ManyField widget to act also as the stock move
widget used in the stock pickings.
Part-of: odoo/odoo#136067
Since the new model (PR: odoo/odoo#114024), updating a record no longer
triggers a deep render and therefore no longer triggers the onWillUpdateProps
for Field components.
The goal of this commit is to adapt the usage of onWillUpdateProps
in Field composents in order to fix the bugs introduced by the RelationalModel
closesodoo/odoo#135842
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In DocumentViewer, we need to generate google slide urls.
In this commit, we're going to create the getGoogleSlideUrl utility that
generates a google slide url.
closesodoo/odoo#135851
Related: odoo/enterprise#47573
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit
==================
Currently, There is no way to know how many qty users can produce with the current stock.
After this commit
=================
With this commit, In the MO Overview report, the following stages are added:
'Ready', 'Not Ready', and '{X} Ready'. the Ready to Produce qty is based on
the component reserved quantity + component free quantity. Furthermore, the
table header in the MO status overview report has been slightly highlighted for
improved visibility.
task-3356499
closesodoo/odoo#124474
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
* = account, base_iban, bus, calendar, crm_livechat, hr, hr_holidays,
im_livechat, mrp, project, sms, snailmail, test_mail,
test_mail_full, web, website_livechat, website_slides
Add support in `contains` for most operations that we use in tests.
Remove return value from `contains`.
Move into `web` module.
Remove import/export chains, directly import from correct module.
closesodoo/odoo#134652
Related: odoo/enterprise#47064
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, formatters like `formatMonetary` and `formatFloat`
weren't loaded in the assets front-end.
This commit introduces `formatAmount` ( `formatMonetary` calls
`formatAmount` but makes some prior processing to deduce the currency
from the field) and makes `formatAmount` and `formatFloat` accessible
from any front-end application.
Note: The currencies were added in the front-end session info because
they are needed in `formatAmount`.
closesodoo/odoo#133824
Related: odoo/enterprise#46658
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
* = calendar, hr, im_livechat, mrp, project_todo, sms, snailmail,
test_mail
The parameter is too often specified with its default value to be worth
being a positional parameter.
Part-of: odoo/odoo#133717
* = account, calendar, im_livechat, mrp, project_todo, sms, snailmail,
test_mail, web, website_livechat
`contains` is more efficient than `afterNextRender` as it does not wait
for several extra animation frames, and it is functionally more
meaningful.
closesodoo/odoo#130451
Related: odoo/enterprise#44999
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
`QUnit` tests require at least one `assert`. This change allows to write
tests that only contain `waitUntil` without extra `assert` in the test.
`waitUntil` is more efficient than `afterNextRender` as it does not wait
for several extra animation frames, and it is functionally more
meaningful.
Currently existing tests that contain `waitUntil` have been adapted
accordingly. More and more tests should make use of it in the future.
Part-of: odoo/odoo#130451
In this commit, all usages of env._t() are replaced by _t().
In templates files, env._t() didn't work because terms used
in attributes where not extracted into the translation files.
Only string are exported from .xml files to translation files.
So, to make it works, we set a variable that is then used
in attributes.
For example :
<t t-set="string_to_translate">String to translate</t>
<Dialog title="string_to_translate>...</Dialog>
task-3292454
closesodoo/odoo#131390
Related: odoo/enterprise#45631
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
This commit fixes the layout of the BOM control panel.
task-3419079
Part of task-3326263
closesodoo/odoo#132025
X-original-commit: c0fac4b7b8b66315a553337956999d8eb602ac13
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
As all the templates are now imported in the owl app, there is not need
anymore to specify the owl="1" attribute in the templates.
Part of task~3443861
Part-of: odoo/odoo#130467
**Sum of timesheets time different than what the timer displays**
Steps to reproduce:
1. Start a workorder timesheet, then stop it
2. Repeat the process multiple times.
Current behavior:
The error is based on a microsecond precision so you could need
to try multiple times before reaching the problem.
- The time displayed on the timer widget does not display the same as
the sum in the timesheet list.
- The difference between the start date and end date of a timesheet
is not always equal to its duration.
Expected behavior:
- The sum of duration should be the same as the one displayed on the
timer widget.
- The difference between the start and end date of a timesheet
should be equal to it's duration.
The computation of the duration of a timesheet will take microseconds
into account. It's not useful in the timsheets to save microseconds
as the precision is too high and as the user cannot change it manually
anyway.
Removing this precision (i.e. setting microseconds to 0) solve this
problem as it does not trigger rounding errors in a single timesheet
and thus in the total computation of duration of a workorder.
Also, there was a precision rounding error on the timer widget.
Time is saved as minutes in db, and displayed as seconds.
So 2s is 1/30 of min => 0,0333... min.
As multiplying this by 60 will return 1,99999 and as the timer was flooring the result,
there was some difference between the time recorded and the value displayed in the
widget.
enterprise : https://github.com/odoo/enterprise/pull/41727
opw-3241156
closesodoo/odoo#130618
X-original-commit: 0172395fa60c94150609bbbfe174d5eee44525fe
Related: odoo/enterprise#45109
Signed-off-by: Tiffany Chang <tic@odoo.com>
In the commit [1], the patch has been refactored to support the
native keyword `super`. The current commit just adapts the codebase
to that change.
task 3410198
[1]: 19ea1ac08043e22a811630968e44715cc3bfc495
Part-of: odoo/odoo#125716
In a previous commit 8bfa76a, _lt() returns _t().
So, in this commit, all usages of _lt() are replaced by _t().
task-3292454
closesodoo/odoo#130179
Related: odoo/enterprise#44906
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Since the relational model was rewritten (PR 114024), it is now reactive,
so it is no longer necessary to use model.notify() to render the view.
closesodoo/odoo#130058
Related: odoo/enterprise#44781
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit adapts the code in addons w.r.t. the introduction of
the RelationalModel.
Main changes that were requested are:
- record datapoints no longer always have an "id" key in their
data (they still do if the id field is in the view), so we use
record.resId instead
- the new model is based on fined-grained reactivity, so several
components that previously relied on onWillUpdateProps to update
their internal state no longer worked. Typically, using the hook
"observeRecord" is the way to go now.
- specialdata are no longer handled in the model, so the components
needing specialData can use the hook "useSpecialData"
- more generally, all overrides of models (RelationalModel or
KanbanModel) needed to be reworked.
Part of task~3179751
Part-of: odoo/odoo#114024
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: FrancoisGe <fge@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: Pierre Rousseau <pro@odoo.com>
The goal of this commit is to prepare ground to remove
lazytranslate function _lt() and keep only _t()
for a better understanding of the use of the translation function.
In this commit,
the translate function _t() has been updated to return the translation
if they are loaded. If not, it throws an error.
the lazytranslate function _lt() returns _t() function.
Corollaries :
Steps in test tours are now a function that returns an array of steps
to avoid any interpolation of _t in this ones before translations has
been loaded.
Example :
registry.category("web_tour.tours").add("example", {
test: true,
steps: () => [
{...},
{...},
],
});
task-3292454
closesodoo/odoo#124157
Related: odoo/enterprise#43153
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
If you are using a locale that uses "," as decimal_point and "." as
thousand_seps the parseFloat around formatFloat is not parsing correctly
the float because the parseFloat is not locale-based but uses always the
"." as decimal point. example: in Italy the thousand separator is ".".
parseFloat("3.000,00000") returns "3" as result but the correct result
is "3000" . It is not necessary to use formatFloat but it is needed
closesodoo/odoo#123711
X-original-commit: 48dd3d189a50b4b2a25ce0c3cf6dca0f744fd928
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the bug:
- Create a storable product with BoM:
- add any product as component
- save
- Click on the BoM overview widget
- Change the quantity of a BOM with a number that has a decimal
value.
Problem:
The quantity is converted to an integer because this input does not
accept a decimal value.
opw-3288403
closesodoo/odoo#123024
X-original-commit: de5087df501bffdaa14ca6a8b7a19da802f4e016
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When overviewing a BoM with a "kit" type and with no route,
the availability was always unavailable, wich is wrong if all the parts
are in stock or can be replenished.
Task-3184663
closesodoo/odoo#121783
X-original-commit: f13b4d1ae8c12a1668222e6994dea26a27c6f5d4
Related: odoo/enterprise#41248
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Added the possibility to search among variants in the BoM Overview view
Task-3184663
X-original-commit: 1c636b5119a40fc9e92174027495b63fa1cafa31
Part-of: odoo/odoo#121783
To reproduce this bug, you need to create a RFQ, add a product with
variants and click on the button to view the quantity forecast.
Then, click on Manufacturing forecast. The BoM overview does not
have the correct variant selected in the Select.
To fix this, simply added an active_product_id to the context, used it
to get the correct BoM data ans then display it in the select.
Task-3184663
X-original-commit: a4ab49d5e41debfe6b2d46840dfffe1008f0f1ec
Part-of: odoo/odoo#121783
Elisabeth Dickinson