If we have a many2many_tags widget that is writable then becomes
readonly, we can have in the code this chain of event:
- get list of widgets we need to reset some data for
- apply modifiers
- reset the widgets
but applying modifiers can delete a widget (eg. an editable field that
becomes readonly), so when resetting we could call code on a deleted
widget which caused an error.
For example, if we have an attribute:
`<field widget="many2many_tags" attrs="{'readonly': 'condition'}"/>`
if the field goes from editable to readonly and is affected by an
onchange, we will call `setIDForLabel` on the deleted instance of the
widget which will cause an error.
Added test without fix fails with error:
TypeError: Cannot read property 'attr' of undefined
at Class.setIDForLabel (/web/static/src/js/fields/abstract_field.js:324:35)
because as said, the function is called on the editable widget that is
removed and replaced with readonly widget at that point.
opw-2154471
closes#43137closesodoo/odoo#43244
X-original-commit: 6f5ca16524be7c5bb45b03e7421154a20edc4cf6
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
d06e67e748 introduces tools to use owl renderer
for a view. However, on_attach_callback and on_detach_callback were not
called on super (AbstractController), so not applied to the controlPanel
and searchPanel.
This commit fixes this issue
Task-ID 2171436
closesodoo/odoo#43165
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
d06e67e748 introduces tools to use owl
renderer in a view. However, this owl renderer is never destroyed.
This commit fixes this issue.
Task-ID 2171436
Issue
- Install eCommerce
- Select Zap theme
- Go on a product in the shop
The quantity is hidden behind the buttons
The quantity height is not the same than the buttons
Cause
By default, there is a max width of 125px on the div containing
the buttons and the quantity label. As this theme increase the
button size, the quantity is hidden.
The quantity label has `.form-control` class who override
his height, so it's not using flex anymore.
More details from QSM in design-themes closed PR #199:
Bootstrap is not correct about input-group form-control height
-> bootstrap_review.scss fix for the height of input-group
form-controls
Our max-width on css_quantity is not right, it should be a
max-width on the internal input
Solution
Restore the initial height in bootstrap_review for input-group form
control
Set the max-width only on the internal input.
OPW-2166311
closesodoo/odoo#43099
X-original-commit: 81e06ec43fdf90758556a654cedd75001ff654c1
Signed-off-by: Jason Van Malder <jvm-odoo@users.noreply.github.com>
This commit adds "Next Activities" on kanban card of partners,
like on the app Contact.
Task-Id 2152180
closesodoo/odoo#41793
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit: all dialogs would go through the static method (OwlDialog.hide)
when destroyed, regardless of wether they had been opened or not.
Now, only dialogs having an 'el' property set (= having been opened) will use
the 'hide' method.
Task 2170705
closesodoo/odoo#43124
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
When accessing stock_barcode module to validate pickings, is not
possible to add floating point quantities for any localizaton which uses
',' as decimal separator.
The numeric field is now defined via browser tags <input="numeric"> to
make the numeric keyboard popup automatically on mobile devices
(commit 8f5840369b28962ab2be9edfce7331a836c3df22)
Adding the override to avoid further processing when the input
is already anumber
opw-2154657
closesodoo/odoo#42748
X-original-commit: 1ccc60deeb067f8d461d48cbf51719317c22cb90
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
This commit reverts a previous fix because we found a better one
in enterprise.
So we don't need this line anymore.
opw-2071605
Task ID: 2152160
closesodoo/odoo#43102
Related: odoo/enterprise#7647
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Issue
- Install planning
- Go on a planning view where you have 2 filters (employee/roles)
- Unselect all items of one filter
All the filters disappear.
Cause
By doing this:
```
if (!_.find(options.filters, function (f) {return f.display == null || f.display;})) {
return;
}
```
We break the function's recursion:
```
return self._renderFiltersOneByOne(filterIndex + 1);
```
So the others filters are not rendered.
Solution
Return the next filter rendering instead of nothing.
OPW-2166932
closes#42703, closes#42433closesodoo/odoo#43025
X-original-commit: dbab68a92ec48b2bb6f21244af1de56691cb43f1
Signed-off-by: Jason Van Malder <jvm-odoo@users.noreply.github.com>
New component: the custom file input. Its purpose is to define a input of type file
with a custom trigger (button, link, etc.).
Its construction is the following:
- attributes: behaviour of the actual input (route to call, multifile, allowed
extensions etc.)
- inner template: the trigger that will fire the upload prompt when clicked
Once a file has been uploaded, the component will emit a 'uploaded' custom event
containing the files.
closesodoo/odoo#38423
Related: odoo/enterprise#6031
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
New Owl component: Dialog. It does not rely on Bootstrap but behaves the same
and does not conflict with legacy dialogs.
To call this component, you need to define it in the XML parent template instead
of calling it in the JS file, and put a flag in the parent state to toggle the dialog.
Old dialog file has also been slightly updated to ensure compatibility between both
versions.
This commit also updates a list view test which did not wait for click events to
properly trigger and would cause the new dialog system to crash.
Added a new custom hooks: useFocusOnUpdate.
This hook returns a function taking a DOM selector as an argument.
That function will focus the first matching element on the next repaint of
the component.
Fix an error which occurs during an attempt to access the string
attribute of a non existing measure
If a pivot view is defined with a "string" attribute of a field of
type "row", e.g.
<field name="stage_id" string="Stage" type="row"/>
an error was raised "TypeError: measures[name] is undefined"
closesodoo/odoo#42971
X-original-commit: de1dbc9bfba3ec205c75590d3e38b20d30b39c39
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Reversal of ef46378cd3
The bug we tried to fix with the reverted commit was fixed by 3023cd24af
but it was causing other issues, like the text field translate button
badly positionned
closesodoo/odoo#42953
X-original-commit: d98dde0704f04e1e929bc689fe00814142a9cd40
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Issue
- Take a v13 runbot
- Open survey's app
- Open one of the surveys
- Click on edit
- Click on a question
- Open 'option tab'
- Make sur the field 'mandatory answer' is true
- Try to translate field 'error message'
-> Error
Cause
this occur because because we try to update the model survey.question
from the list coming from survey.survey which mean that the
record.viewType is list and not form.
Solution
As we are looking for the field name we can simply use
ev.data.fieldName.
Another solution should be to use this.viewType instead of the record
one.
OPW-2157631
closesodoo/odoo#42952
X-original-commit: ad115d2710aec2b4ff7d4077714a1816cdfb433e
Signed-off-by: Jason Van Malder <jvm-odoo@users.noreply.github.com>
Let's assume a many2many_checkboxes widget in a form view with a
dynamic domain (depending on another field in the view). At first
rendering, the widget contains a checkbox for each value matching
the domain.
Before this rev., if the user changed the value of the field used
in the domain, the many2many_checkboxes wasn't redrawn, so it still
displayed the values matching the previous version of the domain.
Closes#38509Closes#40173closesodoo/odoo#42867
X-original-commit: 1ace56f9a8cb56fb39235468dd13447bcbbee40a
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Before this commit, pointer events were prevented on all checkboxes in readonly
list views. That meant that the boolean_toggle widget for instance could not be
properly toggled in a non-editable list (which was the purpose of such a widget).
Now, pointer events are enabled only if the checkbox :
- is in a selected row AND does not have a readonly modifier
OR
- has a widget applied on the field.
Also ensured that the field widgets in the list view multi edition confirmation
modal are not interactive.
We cannot test the `pointer-events` property interactions as it does not affect
manual event triggering used in tests.
Task 2154055
closesodoo/odoo#42848
X-original-commit: c7ee164d572e01fcb565001fd5e62fe1278b5cd8
Signed-off-by: Julien Mougenot (JUM) <Arcasias@users.noreply.github.com>
Before this commit, negative numbers are never rendered as human readable (e.g. 34000 -> 34k).
closesodoo/odoo#42789
Taskid: 2160790
X-original-commit: b51877c4c4c9d8cd873dd0205954fd807d62ee01
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Previously it was always possible to create within the calendar view.
For some modules this did not make sense and lead to confusing behavior,
for example: a new model instance created in the calendar view that was
not viewable in the calendar view, but was viewable in other views. By
adding a 'create' attribute (to be used in view xml), we allow users to
choose whether or not they want a calendar view to be able to create.
Note that this change does not affect the edit ability of calendar views
for existing instances.
Part of
Task: 2126530
Before this change, fields.Reference displayed into the popover of
a calendar view was always empty. This was because the popover view
generated from a double click on an element in the calendar view
creates its own recordModel in JS and the function to create this
record did not handle the reference field case.
This commit detects if a reference field is defined into the record
and adds the necessary processing to process its value and creates
the corresponding dataPoint.
opw 2151635
Closes#41262closesodoo/odoo#42707
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Rev. bc131c0cfb aimed to handle the case of several
(conditional and exclusive) <label> tags for a same field.
The idea was to wrap those <label> tags into a div with
className 'o_td_label' (typically set by the framework), and
let the framework move it to the td wrapping the div.
However, it causes an css issue (only in community), as the
presence of two o_td_label classnames (one on the td, and
one on the div), produces two right borders.
This commit fixes the issue by removing the classname on
the div (we simply 'transfer' it to the td).
Closes#42589closesodoo/odoo#42667
X-original-commit: f71979a681d95d98db19a80feb59fdf684ec361f
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce:
1. Open 'Project' on mobile
2. You can scroll x while the content fit the screen.
This issue occured because of negative margins on
'o_kanban_manage_toggle_button' class.
In general, using negative margins should be avoided.
So in this commit we simply avoid to have negative margins by
removing unwanted borders. It keeps the same design.
Similar issue:
https://github.com/odoo/enterprise/commit/805ab4d4a329c0fdf7d1cade6c5d7e8428f3a634closesodoo/odoo#42518
X-original-commit: 38702215e6dff4e562a389ec03cdeb8683cd111c
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Purpose of the task is, in mobile view when you click on my profile button it
open profile in back ground and menu(burger menu) will stay open.
so close the burger menu in mobile when clicks on my Profile or Preferences.
Task: 2152160
Closes: #41899
Enterprise PR: https://github.com/odoo/enterprise/pull/7275
Related: odoo/enterprise#7275
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Issue
- Install CRM & Studio
- Edit CRM kanban view
- Add tags > select "tags"
Traceback
Cause
_render is called multiple times, there is one case where
`this.$el` is undefined.
Solution
Checking if `this.$el` exists before using it.
OPW-2156964
closesodoo/odoo#42382
X-original-commit: 05f31289c1bb1d8c4b8e1f72f519e8e35e5ecb8c
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
While x_name has long been automatically supported as an equivalent
of name, x_active was not.
This commit adds this behaviour OoB, both in the ORM and the web client.
On the ORM-side, a new `_active_name` attribute is supported on models.
This attribute specifies the field that should behave as an active marker
for records of the model. It is supported the same way `active` has been
until now (filtering by the `active_test` context key and toggled by the
`action_archive`, `action_unarchive` and `toggle_active` methods).
Although no check has been added on the field's type, it is assumed to
be a boolean field (the same way no check is present on the `(x_)name`
field).
On the client-side, the list view and form view now both support
detecting the presence of either `active` or `x_active` on records,
automatically adding an '(Un)Archive' button in the Action menu if such
a field is detected.
Note that the ORM implementation does actually need the field to be named
in any specific way, but since the web client has no mechanism to load
information regarding a model (the lifecycle of an action loading
includes loading the action, view and record(s) but no generic
information about the model itself besides what is included in the
views), we restrict the field's name to `(x_)active` to avoid confusion
as any other name would work at the ORM-level but not in the client.
In the future, the client might be able to more elegantly get
information about models, but this was not the scope of this change and
this solution should cover most cases.
Note that the `active` field will always takes precedence over the
`x_active` field to avoid confusing the polarity, even if both fields
are present on the model.
In the case of a custom field, it might be slightly annoying that the
default value of a Boolean field is `False`, which means that upon
adding the column, all existing records are automatically archived. This
can easily be worked around using an `ir.default` record for that
particular field and an update of existing records (e.g. through the
list view). The goal of this change was not to make it easy to add
support for custom active fields, but to make it possible - we have
therefore kept this implementation which introduces few changes while
adding enough flexibility for developers.
See https://twitter.com/zubair_shafiq/status/1202587553871880192?s=20
for more info regarding supporting any `_active_name` in the web client.
Co-authored-by: Raphael Collet <rco@odoo.com>
The `color` attribute allows specifying a field by which the calendar
view will color the event entries in the view.
In views where this attribute is not defined, the event was instead
given the `text-white` class, which rendered the event invisible in the
calendar, save for a slight left-border.
This commit just use the 1st color class by default in such cases,
ensuring all events are visible.
opw-2145652
closesodoo/odoo#42200
X-original-commit: 375b34be6ef198753f52a650159edee4d1883006
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Before this commit, users encountered some difficulties to tap/click
on the "optional columns" dropdown in list views.
This issue only occured on Chrome: rather annoying to use the mobile app.
"width: 10px" was used in inline list view but didn't have any sense
in the other case. Worse still, Chrome miscalculated the size of the
clickable area by a smaller one.
This is due to the fact that we add some padding that exceed 10px.
See:
https://github.com/odoo/enterprise/commit/2f1320557ec67a741201d73a23a9782ec8f9b3bb#
opw-2071605
closesodoo/odoo#42210
X-original-commit: 28b6e9c99c77230dc19808718cd6f6f8aec0db5d
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
The attribute "groups" on filters and fields in a search view arch was not taken
into account anymore.
Now items that should be invisible are not anymore available for selection
in the interface (as expected) but are still activable as search defaults
(and the corresponding facets appear if needed).
Task ID: 2081450
closesodoo/odoo#42125
X-original-commit: ca2514a9fbcd693752367cb566d5c11165b40bd4
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Without this commit the multi-company dropdown breaks the page on mobile
closesodoo/odoo#42080
X-original-commit: e074dca861bedb89952d3788e711e261ce903295
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Steps to produce:
1. Go to 'Contacts'
2. Select a contact
3. Click on "More" stat button
To fix this, we need to force the padding to avoid touch_device rules.
closesodoo/odoo#42033
X-original-commit: 2761fec0e152c08dcd2d63bf5dbce94fee2b6a7b
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This commit introcudes two changes to the multi edition in list views:
1. Editing one record does not require confirmation through a dialog
2. Successfully saving multiple records unselects all currently checked records
Task 2146429closesodoo/odoo#41099
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Prior to this commit, there was no clean way to have a button
triggering asynchronous work (like asking user for confirmaton
for example) and close or not close the modal according to the
user choice. Your options were:
1. Swallow the pill and just accept that the modal will close
even if the user chose not to undertake the action.
2. Set the `close` parameter of the button to false and handle
the conditional closing by yourself from outside the dialog.
This commit introduces a way to tell the form view dialog that
the action has not been processed correctly and that the modal
should not be closed by returning a rejected promise. Prior
behavior can still be obtained (close no matter the result)
by having the handler not returning a promise at all.
closesodoo/odoo#33837
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this rev., this._super wasn't correctly reset after being
called. It means that it was sometimes wrongly set, for instance
in the following scenario:
utils.patch(SomeComponent, {
x: function () {
this.y();
this._super(...arguments); // this._super was still y
},
y: function () {
this._super(...arguments);
},
});
closesodoo/odoo#41691
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
During the fix of the click_all test in community in 0f2a500f0e,
I have overlooked that enterprise used this code and removed a bit too much.
Restore the start flag in enterprise.
closesodoo/odoo#41784
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The `text` attribute is not translatable, so we support the `title`
attribute which is.
Fixes#38568
opw-2148416
X-original-commit: 21203ec63db6702529a791f5abab317c6d4fb8af
Before this commit, after the introduction of OWL, for some reason,
maybe because the session is ready earlier or later, the webclient is
opening the first app sightly earlier than before, making it too early.
The click_all failed actually because, in the initialization of the
webclient, it does a read on read user, protected by a drop_previous
it tries to start the first applictaion, when this happens, the hash
changes
==> because the hash changes, it tries to open an application, with is
also protected by the same drop previous, this discarding the result of
the read and preventing the then callbacks of the read to happen.
After this commit, we are declaring that the client is ready after the
actual load of an application.
closesodoo/odoo#41695
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The format of `many2one_reference` was not introduced when the new field type
was created, which leads to empty values when the web client is trying to
display the value of such fields in form views.
Since the value of this field is an ID, it is decided to display it like an
integer, which is consistent with previous behavior: the fields that are now
`many2one_reference` are still stored as integer and they were already displayed
as integer before.
This was fixed in list views in commit d0c852f50e
and the current commit fixes it for form views.
opw-2127010
closes#38009closesodoo/odoo#41666
X-original-commit: c37a16c9dfd09038925034b90ab49e1ab674e714
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The date filters sent to servers were being computed in current locale,
so in arabic we would get things like this:
- "٢٠١٩-١٢-٠٩" instead of "2019-12-09"
- "٢٠١٩-١٢-٠٩ ١٦:١٦:١٥" instead of "2019-12-09 16:16:15"
which would cause a traceback in backend.
opw-2122333
closes#41570closesodoo/odoo#41596
X-original-commit: da778afc24b048244467649dfa4af4e6f4a78e44
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Sometimes, it might be useful for an action (e.g. a client action,
although this may be used by standard views as well) to include custom
values in its state. Since the state of a 'fullscreen' action is pushed
in the URL, this means that it is possible for the action to resume its
state properly upon refresh of the page (before this commit, only some
standard information were pushed to the state - action_id, menu_id, etc.
for window actions and action's name, active_id, active_ids for client
actions).
By implementing the `getState` method, an extension of the action mixin
can thus push any state it wishes to the URL.
closesodoo/odoo#39529
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Because the webclient and other higher level components such as the
actionManager are not yet rewritten in OWL, we cannot make a complete
migration of the controller and the model to a more OWL-ish code.
We have rewritten the renderer completely in OWL, it uses more
extensively a template and manages its own state and its sub-components.
We did not rewrite the controller, however we have made it inherit from
`web.ControllerAdapter` which is a thin compatibility layer used when a
odoo controller uses a OWL renderer.
In the tests, the only changes are that all the events triggered by the
test and handled by OWL must be triggered on DOM nodes directly and not
on JQuery elements.
closesodoo/odoo#39491
Related: odoo/enterprise#7135
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Co-authored-by: VincentSchippefilt <vsc@odoo.com>
Co-authored-by: pro-odoo <pro@odoo.com>
Add a base class for a complete OWL renderer
Add a compatibility layer for a Odoo controller that uses a OWL renderer.
Co-authored-by: Pierre Rousseau <pro@odoo.com>
In this commit:
- transformed test_utils helpers to always trigger native events
- introduced new test_utils_create helper: prepareTarget
- updated qunit asserts to support Owl Components
- updated all misused helpers that would crash with the updated test_utils
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Pierre Rousseau <pro@odoo.com>
With this commit, we properly introduce the Owl library into our beloved
codebase. More information on the Owl library can be found in the project
repository: https://github.com/odoo/owl/
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Nicolas Lempereur