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
Since the attachement viewer was moved to core, this renames it to file
viewer to decouple it from the Attachment model/concept from the mail
module.
Part-of: odoo/odoo#119625
The `mail` module's `attachment_viewer` is useful for more than `mail`
alone. In order to be able to use it in the `web_editor` module (which
doesn't depend on `mail`), we move it to the `web` module.
task-3109331
Part-of: odoo/odoo#119625
This issue only occurs on Firefox because ´has´ is not supported
and the following rule is not applied:
https://github.com/odoo/odoo/commit/2cd0106e63785dd34553c2b4747d72b93b9a7afd
Anyway, there is an existing css rule that is applied if the field
class is correclty added.
Steps to reproduce:
- Open Sale
- Add some content in the sale order line
opw-3201461
opw-3285854
opw-3266130
opw-3244581
closesodoo/odoo#121979
X-original-commit: add1df806157c074fd1a3224d1d8bdf1922481fb
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Prior to this commit, the SVG's viewBox attribute was missing, which
prevented svgs from being scaled.
This commit fixes this issue.
task-3326633
Part of task-3326263
X-original-commit: 30300c373ad1c63a6cf8b035cae0785a09c6933f
Part-of: odoo/odoo#121886
Steps to reproduce:
1- Create a BOM for a product, define an Operation on the product
2- Link a Google Slides document to the Operation as the Operation Worksheet.
3- Define an instruction on the Operation
4- Set Step Document to Specific Page of Operation Worksheet and define a page.
Issue: The step will not load the document.
Cause: tablet.js passes the wrong value to let know the viewer is a google slide url. Also when the good
value is passed the viewer always show the first page. That's because the SlideViewer has the page set in the
setup() method so it never change despite we change the step in the same document.
opw-3165142
closesodoo/odoo#121477
X-original-commit: 2160115647932ef86db3afc59b7f193075c94fd0
Related: odoo/enterprise#41098
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Djoumatchoua Eteil Junior (etdj) <etdj@odoo.com>
This commit adapts the directional icons to improve the usability and
maintain consistency with the ui icons library.
task-2818586
Part-of: odoo/odoo#116641
*: hr_holidays, stock, sale, product, web, sale, purchase, stock,
website, survey
Adapt some custom control panels (mainly for custom reports) to the
milk controlpanel.
hr_holidays:
Move the buttons to create a new time off or a new allocation to the
"create button" slot and transform it into a dropdown (creating
allocation requests is clearly a secondary action, not a primary one)
stock:
3 lines does not fit, must be on 2 lines
Part-of: odoo/odoo#116641
This commit brings the ControlPanel into a single line with 3 main
sections:
- buttons & breadcrumb
- layout related actions (ie. the SearchBar in multirecord view or
ButtonBox in formView)
- navigation (pager, switch view...)
Add new search bar menu, this is a merge of the following components
into one big component display in column:
* comparison_menu
* favorite_menu
* filter_menu
* group_by_menu
Also adapt navigation hook.
Part-of: odoo/odoo#116641
On the manufacturing order, modifying the timer value does save it's value
in db but does not actualise it in the front.
The "rerun" condition is already checked in MrpTimer and does not need
to be checked in MrpTimerField
closesodoo/odoo#120385
X-original-commit: a8cfa1d26ef84aa6690d3cfa8b98b6cecf4f27d9
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce the bug:
- Go to Decimal accuracy:
- Select the “Product Unit of Measure”
- Set the Value to “4”
- Create a storable product with BoM:
- add any product as component
- save
- Click on the BoM overview widget
Problem:
The “Product UoM” precision is not used
opw-3288403
closesodoo/odoo#120296
X-original-commit: 837a6ca90d6944f9faf4b28e69703f5310c6ec6a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
When a reception picking was created to resupply a component (without
using a purchase order), the picking was correctly linked in the MO
Overview, but the date was set as "Not available" as the planned date of
the picking wasn't read.
Also adds the color scheme for pickings states for the Overview.
Part of task-3217757
closesodoo/odoo#118023
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When opened from the MO Overview, the uom in the wizard is the one from
the product's form.
The problem is that the quantity given to it is in the overview's line
uom. So instead we add an already converted quantity to the `to_order`
lines.
Part of task-3217757
Part-of: odoo/odoo#118023
Product availabilities and their related replenishments are no longer
relevant when displaying a completed MO. Therefore, those columns are
disabled in the Overview when the the MO is either done or cancelled.
Part of task-3217757
Part-of: odoo/odoo#118023
Before this commit, the field node id (`field_id`) uses the field name
for the first occurrence on the arch, and add an underscore and a number
for the rest of the occurrences. This can create inconsistencies when
sombody assumes that the field_id is equal to the name, and don't take
into account the possibility of multiple occurrences.
Now, a unique id is created since the first occurrence, this remove all
ambiguity between the id and the name.
Part-of task-id 3179751
closesodoo/odoo#117799
Related: odoo/enterprise#39511
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Following 873d6d9, the forecast would now redirect correctly to the
corresponding bom when a `product.product` was used.
The issue is that `bom_variant_ids` doesn't exist on `product.template`,
raising a traceback when the forecast was accessed through the product
themselves instead of their variants
closesodoo/odoo#115776
X-original-commit: 93f6bf8dc5319082579a2b4ecbc48b482b81cc9d
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
The value of the timer was wrong when timesheeting with multiple employees
at the same time.
The problem was that the compute duration already takes the current timesheets
into account. So the problem was that we added some time
that was already in the duration
task id : 3216277
closesodoo/odoo#114901
Related: odoo/enterprise#38007
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Jorge Pinna Puissant