* = 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>
Stpes to reproduce the bug:
- Create a storable product “P1” with 2 variants:
- Color: Red and blue in this order
- Create a BoM for each variant
- Create a SO:
- select the product “P1 - blue” → the second variant
- Click on the forecast button → manufacturing forecast
Problem:
The BoM overview is showing the wrong product variation because it pulls
the default BoM of the base product (always the first variant from the
list)
opw-3166074
closesodoo/odoo#115421
X-original-commit: 873d6d921c3955b707d10826a898ae405f296531
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
* The tours are now run by the `MacroEngine` defined in `macro.js`.
* This is accomplished by converting (at runtime) the user-defined tours to
`Macro`s. See `tour_compilers.js` for the step (and tour-to-macro) compilation.
* API is kept the same as much as possible. Basically, declaring tours stayed
the same with some exceptions:
* `allowInvisible` can be provided in a step to allow consuming the trigger
element even if it is invisible.
* `isCheck` can now be used to replace the no operation `run` that is
traditionally signals the runner to only perform a check.
* Before, multiple `run`s can be called simultaneously. Now, each `run` method
is awaited before proceeding to the next step.
* If the trigger element is `disabled`, the tour runner will *not* proceed on
calling the `run` method and the runner will stay on current step until the
trigger element becomes `enabled`.
* However, the tour runner is okay with `disabled` trigger element if the step
has `isCheck = true`. As long as the trigger element is found for `isCheck`
step, the tour runner will happily move to the next step.
* Some tours are adjusted to properly run with this new tour runner.
* When the tour failed:
* The dom string is not logged anymore.
* However, a warning message containing the relative location of the step will
be logged. This is better in helping the author in locating the failed step.
**Some guidelines learned during the development:**
* Each step may trigger a dom mutation. It's a good practice to insert an
intermediate step that *checks* the existence of an element that result from
the action of the previous step.
* Refrain from using the `run` method for assertions. `run`, in principle, is
provided to perform actions that are not offered by the helper. Use the
`trigger` for assertions.
* During dev, find `SHOW_POINTER_DURATION` and set it to `250`. This will show
the pointer (pointing to the trigger element) for 250ms when watching the
tour.
closesodoo/odoo#107618
Task-id: 3082036
Related: odoo/enterprise#37560
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
This commit, is part of a series of commits that aim to simplifie the
concrete fields API.
In this commit we will remove value prop from concrete fields. Now each
field will directly use this.props.record.data[this.props.name] to
access their value, As a consequence of this, the name props need to be
mandatory.
task-id 3179751
closesodoo/odoo#113495
Related: odoo/enterprise#37464
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
1. Install [Manufacturing] on Apps
2. On [Settings]>[Manufacturing]
- toggle on [Work Orders], [Quality] & [Quality Worksheet]
3. Go to Manufacturing
- Work Centers (a.k.a WC) Overview should be visible
- if no W.C. by default, add from [Configuration]>[Work Centers]
- give tag to each W.C. (lengthy so as to test the overlap)
- click Manufacturing and [Group by] Tag (Custom)
affected branch: 16.0-master
opw-3177656
closesodoo/odoo#114303
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
Adds in a new report that allows the user to monitor the entire
production of a product, including the resupply of the components (i.e.
subassemblies, purchases, ...) in a single view.
Task-3059467
Part-of: odoo/odoo#113394
This main feature of this commit is adding the possibility to login with multiple employees on the list view of workorders.
There is now a button in the header that will allow to log in as an employee in the list view.
The flow is the following :
- The employee logs in
- He becomes the "admin" of the session and his name appears next to the log out button.
- If another employee logs in, he will become admin and the first one will no longer be visible in the header.
- The employee will start timesheeting on the workorder if he press the start button. Notice that the employees working on the workorder will appear in the last column of every work_order record.
- If this second employee logs out, the first one will not become admin automatically. He will first need to click on his name/avatar in the popup and will be asked his pin code (if needed) to log in again.
There is also a way to assign employees to a workorder.
A filter will help retreive the workorder on wich the admin of the session has been assigned.
In addition, a new button in the header allows to mark as done multiple workorders at once.
The timer component has been updated to avoid wrong values if the computer goes to sleep mode.
The wizard of the workorders allowing to see the time traking has also be modified (switching tabs).
From a more technical point of vue, the employees and admin will be saved in the session.
The employees working on a workorder will be saved on the record.
related : https://github.com/odoo/enterprise/pull/34786
Part-of: odoo/odoo#107473
This commit, is part of a series of commits that aim to simplifie the
concrete fields API.
In this commit we will remove setDirty prop from concrete fields. Now if
needed the fields can declare itself dirty using triggering
"FIELD_IS_DIRTY" on the model's bus.
Note that this PR partially revert [1] and completely revert [2]
task-id 3179751
[1] : 89c2a3978e
[2]: c79bb3c9c6closesodoo/odoo#114124
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Previously we set a component on MO to be manual consumption by comparing
the To Consume and Consumed, if they are not the same, we consider it a
manual consumption. Now if any input activity in the Consumed cell, we
will consider it a manual consumption.
Note that in the code, we make the css class change happended in the
list renderer instead of the field widget. We do that because we want to
change the background color of the whole cell not just the text of the
field.
Task-3116125
Part-of: odoo/odoo#113538
**Before this commit**
- The optional "class" attribute set on the root node of a view arch
is ignored, except for the kanban view which has a custom
way of using it.
- The optional "js_class" attribute set on the root node of a view arch
does not have any impact on the class names passed to its controller.
**After this commit**
The content of the optional attribute "class" set on the root node of an
arch like in
<list class="o_custom_class">
...
</list>
as well as an additionnal class derived [1] from the value of the
"js_class" attribute set on the root node of an arch like in
<list js_class="extended_list">
...
</list>
will both be found in the prop "className" of any view controller.
[1] a js_class value of "xyz" yields to the class "o_xyz_view"
**Note on this commit**
The kanban view was already appending the root node class attribute
to its renderer element. This is no longer the case and some styling
rules has been adapted.
closesodoo/odoo#113014
Related: odoo/enterprise#37265
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
This commit acts as a setup that allows the newly converted gantt view
extensions in enterprise to work properly.
Part-of: odoo/odoo#112756
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Sébastien Theys