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>
Revision on [1].
Commit above made changes to test helper `nextTick()`, so that it
waits for `window.nextAnimationFrame()` (shorten, 'rAF'). This was
useful to wait for OWL rendering, since OWL renders on next animation
frame.
From a theoretical standpoint, the helper should wait at least as
much time as before, as it adds either no slowdown (rAF is readily
available), or a few milliseconds wait (rAF waits for next available
animation frame).
However, some old tests show non-deterministic behaviours, resulting
to crashes [2]. It suggested, for some reasons, that `nextTick()` did
not wait long enough for re-render... Which is surprising considering
explanation above!
Some of these tests have been fixed, assuming it was caused by un-
guaranteed order of successive `setTimeout(0)` [3]. Unfortunately,
this does not explain why it never crashed before the change on
`nextTick()`...
After investigation, we think that this behaviour comes from rAFs
having their own task queue, which no longer guarantees that queued
tasks happen after queued micro-tasks:
When the requested next animation frame is readily available, the
callback of `requestAnimationFrame()` is immediately called and waits
for `setTimeout(0)`. The `setTimeout(0)` await is resolved before any
other queued async micro-tasks, so that `nextTick()` is resolved
sooner than expected. This would explain how `nextTick()` does not
wait long enough for rendering from the loads of resolved Promises,
even though there is a promise resolution after `setTimeout(0)`.
This commit fixes the issue by moving the await `setTimeout(0)`
before the rAF call, so that it correctly waits render from chain of
resolved promises (since the `setTimeout(0)` is awaited in the same
main task queue).
[1] https://github.com/odoo/odoo/commit/b0941d19a07b08fabc64a284b58e57edc46203dd
[2] http://runbot.odoo.com/runbot/build/771505 and http://runbot.odoo.com/runbot/build/752855
[3] https://github.com/odoo/odoo/commit/6cbfdbce2d0f1b567b6a6d6f637fe2a476980accclosesodoo/odoo#42123
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.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>
Removing the test "field changes are correctly debounced in text fields"
because it doesn't represent the reality that fields are not debounced
anymore in production code.
This test was nondeterministic.
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>
Update of Chart.js library to the latest version.
Before this commit, we weren't able to see all
x-axis dates labels like in Accounting Overview.
Tick label rotation on mobile has been fixed in
https://github.com/chartjs/Chart.js/pull/5961.
closesodoo/odoo#41582
X-original-commit: 24d8ae59e08143dc0ca7e05be37a3cd607d58a4a
Signed-off-by: Adrien Dieudonné (adr) <adr@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>
This commit adds mixin to manage file uploads in view controllers and to
display progress bars.
The first motivation and use case is to allow MRP to manage and display
uploads like in Documents.
closes odoo/odoo#38397
Task: #2074822
Related: odoo/enterprise#5887
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Task 2046908
Instead of having all the fields duplicated with second_*, we have now a
o2m allowing us to
* have more than 2 lines
* reduce duplicated code
* fix bugs and add features at only one place
We also remove the computation of writeoff and suggestions from the
client side as some code was 4-upled before (twice in in client and
twice in server side). The logic is now only at one place.
closesodoo/odoo#38119
Related: odoo/enterprise#6324
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Before this fix, a QUnit test was wrong (didn't parse)
After this fix, the test actually works and tests something.
closesodoo/odoo#41257
X-original-commit: 3818a7f0df754717a7379dc8341729b508a166be
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Reproduce the issue
- Load Arabic language
- Install Accounting
- Create an invoice & add credit note
- Switch to arabic
- Click on the "(i)" icon near the total price
The popover is displayed at the other side of the screen
Cause
- RTLcss was reversing the "left: 0" css property to "right: 0"
- The popover configuration was not adapted for RTL
This commit ignore RTL for the popover css "left" property and
configure correctly the JS side
OPW-2146210
closesodoo/odoo#41200
X-original-commit: 88f03f0444a2533b1f6085369af431131da42b54
Signed-off-by: Jason Van Malder <jasonvanmalder@users.noreply.github.com>
Reproduce the issue
- Load Arabic language
- Install Sales
- Report > Sales
- Switch to arabic
- Click on the pivot view to display the dropdown
The dropdown position is incorrect
Cause
The calculations are based on a `left` value who is weird.
This commit use the mouse X position to compute the `left` value.
OPW-2146210
X-original-commit: d021f4257c87863b75f148c4809f5e2797a1e99f
* web, mass_mailing, website
Introduced a new sub-widget for snippet options: we-colorpicker. This
allows to retrieve a color value (either a normalized css color or a
theme color name) to be used for a snippet option method.
This commit replaces the old 'colorpicker' snippet option whose behavior
is now simply achieved by defining an xml option using a we-colorpicker
widget in combination with the 'selectStyle' standard method.
This commit also adds the possibility to control the border-color of
elements alongside their border-width. Again, just a we-colorpicker
widget in combination with the 'selectStyle' standard method.
Note: this commit reviewed what the colorpalette palette widget
notifies. This is not a cssColor and a 'isClass' flag to say if it is
a css class or not. The colorpalette always returns a color string which
can be the name of a color like 'alpha'. This is up to the caller to
check if the color string is a css color or not with isCSSColor. In the
case it is not, the related code can read the actual color by reading
the related css variable.
Part of https://github.com/odoo/odoo/pull/40282
In preparation of task-2122935 and other tasks
* website
Review colorpicker methods to always allow to use normalized colors.
Also factorize some code in the color palette widget.
Part of https://github.com/odoo/odoo/pull/40282
In preparation of task-2122935 and other tasks
Fixes the way record end hours are computed in calendar views.
Before this commit: objects `record start` and `record end` properties being copied by reference
and being incorrectly rewritten by other functions.
This caused incorrect end hour computations (and a SQL crash in the Planning app).
Now, objects are copied by value and don't interfere with each other.
Task 2072961
closesodoo/odoo#37690
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Adapt calendar highlight option (that "highlight" event linked to the
record we come from) to current JS framework data structures.
note: this changeset also fixes the original `_compute_is_highlighted`
that was would trigger CacheMiss errors, and also adds back the CSS for
highlighting that was lost between 12.0 and 13.0 version.
opw-2131494
closes#40791closesodoo/odoo#41077
X-original-commit: da56e3e7036ecdb3905f4152778e853e080e0163
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
- Set the computer TZ so that it is UTC day + 1. For example, set to
'Australia/Adelaide' and perform the tests after 3:00 pm
- Go to Account > Customers > Invoices
- Set the Invice Date to today in the TZ
You receive the warning 'This date is on the future...'
The comparison of a UTC date without time `currentDate` is inconsistent
with `moment()`, which is not UTC and has a time set.
After playing around with `.utc()` and `startOf('d')` with no luck, we
decided to give up the idea of making `getTZOffset()` enter the game and
simply compare the string formatted values.
opw-2093186
closesodoo/odoo#40984
X-original-commit: f9eec97cb128f71796fca0116841453555ab4684
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
`name` field can be required and falsy `data.name` should not be
added as default in context or it warns for missing required field.
Task-2052536
closesodoo/odoo#35880
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
On mobile, there was no way to create a new column in the kanban view. This
was specifically annoying in the Project app (the user was able to
create the project but couldn't set its stages).
This commit enables this feature by adding a `+` icon at the end of the
tabs. This button opens a quick-create column widget.
If there is no existing column (for example in a newly created project),
this quick-create column widget is opened by default.
Finally, this commit improves the processing needed for the swipe
animation between the columns.
Task ID: 1893137
closesodoo/odoo#40722
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
Co-authored-by: Ankit Sathvara <asa@odoo.com>
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Co-authored-by: Romain Estievenart <res@odoo.com>
Before this commit, with a time range activated in a pivot view,
click on a non empty cell would not always give the right list of
records because of a bad action domain.
The reason is that the headers domain or comparisonDomain were
not always set when appropriate:
- for the headers 'Total', the corresponding group obtained
by read_group does not contain the key __domain. For that
reason both the key domain and comparisonDomain were left
undefined.
- for headers that correspond to groups not present in the two
periods compared, one of the key was left undefined.
With the present commit, we correctly set the domain and
comparisonDomain keys everytime they are useful.
closesodoo/odoo#40713
X-original-commit: 2f89820faa5966b8321d6681e9745a4e938e2bec
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Conditional expressions were already parsed, but there was no support
for executing them (or stringifying them back though I'm not sure when
that's used).
closesodoo/odoo#40502
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Jason Van Malder