Currently the `not like` and `not ilike` operators are available for the Odoo domain in Python but not in JS.
This commit adds these two operators in the JS Odoo domain too for better code clarity. For instance:
`[('fiscal_country_codes', 'not like', 'AR')]`
instead of
`['|', ('fiscal_country_codes', 'like', 'AR')]`
Part-of: odoo/odoo#106221
This commit adds the ability to enable spellcheck on input/textarea only
if they are in focus. This avoids the UI to be bloated with unwanted
underlined text on unfocused elements. It is especially useful in a context
of form view in always edit mode.
A core hook has been introduced to allow other components to use the same
behavior without reimplementing it. It is currently used by the TextField.
It means it is also used in the HtmlField. Tests have been written, both for
the field component, and the core hook.
task #2861428
Part-of: odoo/odoo#106866
Pressing `<space>` in browsers results in a ` ` event key.
We don't want this event key as ` ` is not recognized and not
whitelisted in the hotkey service.
Instead we want to use `space` because it is more readable in the
codebase.
Part-of: odoo/odoo#99050
Previously, when calling error handlers, we would give them a new error
created by the error service, as well as an `originalError` which is the
error that was caught by the error service. In some cases, this error is
part of an error chain, eg: errors that happen in the owl lifecycle are
wrapped in an `OwlError`, so that when an error occurs in a callback
passed to a lifecycle hook, the position where the hook was called to
register the offending callback is part of the stack trace.
In practice, most error handlers only care about the error that caused
the entire error chain (the root) when deciding whether they should
handle the error or not, eg: an RPCError should be handled by the rpc
error handler, regardless of whether it occured in an event handler or
in a component's willStart. It already reads the traceback to display on
the UncaughtError provided by the error service as this traceback
contains the entire error chain stack information and is annotated with
source maps by the error service.
This commit makes it so that the `originalError` passed to handlers is
now the root of the error chain, it also sets the `cause` of the
UncaughtError which is passed to handlers as the error that was caught
by the error service, so that if a handler needs to inspect the error
chain to know whether it can handle the error or not, it can still do
that.
related to OPW-3069633
closesodoo/odoo#106720
X-original-commit: dd6f103b1635868e03a7aa40eb7186861d22d377
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
**Before this commit**
When a popover is shown and then repositioned to a different placement
(i.e. due to window scrolling or resize), its arrow is misplaced.
This is due to the fact that classnames added in order to correctly place
its arrow are just added to the previous ones instead of replacing all
the needed classnames.
**After this commit**
The classnames are now properly replaced instead of just being appended.
closesodoo/odoo#106495
X-original-commit: c54cc2f87930147b5addb6f447574c677ef3504d
Signed-off-by: Luca Vitali <luvi@odoo.com>
Some missing aria attributes from 14.0 are reintroduced.
They are required for screen reader users to be able to know if menus
are opened and if menuitems are checked (e.g. if a filter is applied).
closesodoo/odoo#106277
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Co-authored-by: Luis González <lgonzalez@vauxoo.com>
Dropdown menus/items were refactored and moved to OWL when migrating to
15.0. Now, the focus is always on the dropdown button, which captures
and handles all keyboard events, to be able to move over the menus.
Currently-selected item is highlighted by toggling classes.
However, since the focus is always on the dropdown button, screen
reader users are no longer able to know what menu item is being
selected, as it's only a visual change (in previous versions, the focus
actually moved to the selected element).
The above is fixed by making the activeElement follow the visual change.
Part-of: odoo/odoo#106277
Co-authored-by: Luis González <lgonzalez@vauxoo.com>
Since odoo/odoo#99660
the `depends` field attribute is no longer passed
from the server to the web client.
Because of this, the "Set Defaults" feature
of the debug menu is completely unusable,
as the list of fields on which to set a default is empty because of it.
The use of this `depends` field attribute has been introduced in
revision odoo/odoo@ce9bbf6c10
In the commit description, we can read that setting a default
on computed fields having depends has been disabled
because the defaults set were being overwritten by the call to onchange.
Note that only the fact the field has depends is required,
the actual list of field names is not used, just the fact the list is
not empty.
However, since revision
odoo/odoo@488e334fc8,
available since Odoo 14.0,
this is no longer the case, the defaults are no longer being overwritten
by the call to `onchange`, since the `default_get` has been integrated
into the `onchange`.
A video attached to the pull request of this revision
shows the behavior difference.
Hence, setting a default on a computed fields having depends
(with an inverse method, hence not readonly)
can be allowed again in this "Set defaults" debug feature,
therefore avoiding to have to send back the `depends` field attributes
to the web client.
opw-3031290
opw-3038711
opw-3055292
X-original-commit: 48ac799288e76a0256b9ce0712a70ed5abc0f62e
Part-of: odoo/odoo#105251
This commit adds the isAvailable option to the command. If you set this
option, then it determines if the command should be displayed or not
in the command palette.
Why add this option?
We want to allow a component to define a command that will be displayed
according to the internal state of the component
Part-of: odoo/odoo#91821
Before this commit, performing a search in a m2o can block your ui
despite the result already being displayed.
Why?
When you perform your search in a m2o, a set of RPC queries are made
with the different search values (name_search). If the last search value
(the one that will be used by the m2o in its autocomplete) has already
been resolved, but one of the other RPCs has still not been resolved,
then the screen will remain blocked until all the rpc's have been resolved.
Solution:
Since we are only interested in the last rpc, we will cancel all the
others. So with each new rpc, we will cancel the previous one.
How to reproduce:
- Go to a form view with a m2o field
- Edit this field +- slowly (several rpc will be done with different values)
- Receive the result of the search. (The autocomplete is displayed with
the right values)
Before this commit:
If one of the other rpc's is not yet resolved, the ui will block
until all rpc's are resolved.
After this commit:
The ui will not block.
closesodoo/odoo#105269
X-original-commit: 9917d841fa38ccc1e6d67875a665494dc22ef92f
Signed-off-by: Samuel Degueldre <sad@odoo.com>
... when re-opening the dropdown.
Before this commit, in an autocomplete component with an async
source, when:
- clicking on the input to open the dropdown,
- then typing something to filter the results
- then selecting one of them (which closes the dropdown)
- and finally re-opening the dropdown:
the previously displayed (and filtered) results were briefly
displayed, while the source was being fetched again. It thus
produced a weird and annoying flickering.
This commit fixes the issue by reseting the source before fetching
it.
closesodoo/odoo#105539
X-original-commit: 83769b00837f4eea29586f53709d65d3078ddce3
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the drag & drop feature for the Project "Tasks"
kanban view did not work if the drag sequence was initiated from the
title of the card.
This was due to the "o_kanban_record_headings" class having the CSS rule
`overflow: hidden`, because of a well known 6 year-long-and-counting
bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1352061
Namely: mouse enter|leave events won't fire on anything underneath
elements having `overflow: hidden`.
This commit solves this issue by introducing a dedicated class name
'o_dragged' to all elements dragged using the `draggable_hook_builder`,
and defining on it the CSS attributes that were assigned in JS before,
as well as `pointer-events: none` on itself and all its children to
avoid the issue mentioned above.
Also in this commit: fixed a syntax error in a CSS rule in project's
"task_name_with_subtask_count_char_field" widget.
closesodoo/odoo#105353
Related: odoo/enterprise#33774
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Unused catch block arguments are now forbidden even when prefixed with an
underscore: if the argument on the catch block is not needed, the use of the
optional catch binding is enforced.
Part-of: odoo/odoo#105433
The Race concurrency promise never settles if the first settled promise
rejects and therefore you can't catch the rejected promise.
closesodoo/odoo#104733
X-original-commit: 24cc8cdb440a5af944d82a25d98b0239e72e2625
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
removeContextUserInfo was a Spreadsheet asset, which is not a dependency of
Knowledge.
In order to make this feature available for all modules, it is moved in web as
an object util, that needs to be used alongside the user service in order to
dynamically remove user context information (no hardcoding).
Task-3017349
closesodoo/odoo#104304
X-original-commit: fd88fc1bbad4c0cdb44cf634b6a5621eb7597e0d
Related: odoo/enterprise#33322
Signed-off-by: David Beguin (dbe) <dbe@odoo.com>
*: base_automation, lunch, mail, mrp, project, web_editor, website
This commit adds a warning if the props validation is not set for a
component.
The props validation is important to tell how a component should be
used, by looking at its code, it's a good documentation of the component.
It's also critical, to test if the component is correctly used, if all
the obligatory props are passed and that there are of the correct type.
For more information, see: https://github.com/odoo/owl/blob/master/doc/reference/props.md#props-validationclosesodoo/odoo#103723
Related: odoo/enterprise#33044
Signed-off-by: Géry Debongnie <ged@odoo.com>
The web client exposes an utility function that converts the tokens
of a luxon's DateTime format into a moment.js format.
While this function is not false (still it is uncomplete), the strategy
of using it to convert a luxon's DateTime object into a moment.js moment
is not good.
The daterange field make use of this bad strategy.
Because of the differences between luxon and moment.js locale handling.
Luxon relies on the native JavaScript Intl API.
Moment has its own implementation of locale handling.
So having to pass through formatters/parsers may yield to unexpected
results. For instance, when a locale does not have the same way (in
moment.js and Intl) to express i.e. months and we try to convert a
luxon's DateTime into a moment by formatting the first and then
parsing into the second, the second will be invalid. This is the same
the other way around.
This was in fact encountered with some locales, i.e.
- syrian arabic (ar-SY)
- albanian shqip (sq-AL)
This commit brings an alternative strategy by providing other utility
functions to directly convert a moment into a luxon's DateTime
and vice versa.
This is a better strategy for various reasons:
- it abstracts the way the conversions are done
- no need to play with timezone's offsets
- probably all libs that has moment as a dependency accept a moment
object in their options, that may not be the case for formats
- The daterange field now use the new strategy
- The datepicker component now use the new utility functions as it had
implemented locally something similar.
closesodoo/odoo#104138
X-original-commit: 9dedfcaa4ad1fb5ea24f604b40df1bf0830617cb
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Before this commit, multi clicking quickly on the "Ok" or "Cancel"
buttons of a ConfirmationDialog would call the confirm/cancel
callbacks multiple times. For instance, in "Mass mailing", create
a new mailing and click "Send". In the confirm dialog, clicking
quickly multiple times on "Ok" would call the "Send" button action
multiple times.
This commit also ensures that we wait for the promise of the
confirm callback before closing the dialog. This highlighted an
issue in the ORMBatcher, as we didn't reject the promise when
the batched rpc failed. As a consequence, the confirmation dialog
never closed itself. This has been spotted by an existing test.
Fixing #74647 (from 16.0 to master)
closesodoo/odoo#103572
X-original-commit: 95f8266a5b84f5faa59a713019ab713392b3ef78
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Take a PyDateTime representing the moment "2022-10-17 00:00:00" in
the timezone of Brussels. Trying to get the related utc moment through
to_utc gives wrongly "2022-10-16 23:00:00". This happens because the
months are not numbered in the same way in Date or PyDateTime, so that
in October for example, the offset applied was that of November which is
-60 instead of -120 (summer/winter change). We fix that problem.
closesodoo/odoo#103561
X-original-commit: a11e1fb5f702400fe51938362fe3f24570977ba9
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
**Before**
A traceback is raised when pressing shift-tab on the first column of
the first row in a focused list field as shown in the vid:
https://youtu.be/g97ZTp1QdBE
**After**
shift-tab on the first column of first row will now unselect the list field
and immediately focuses on the previous field.
**Additional change**
We now allow skipping focus on the dropdown toggler by introducing new
props.
closesodoo/odoo#103485
X-original-commit: 9ba9977e42d201035b5299bc13ba03211cddbc1f
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Before, even if the checkbox is deactivated, clicking on it
cause an `onChange`.
This caused unexpected behavior, the form view changed to a dirty
mode even if the checkbox was in read-only mode and nothing
was modified.
Now, the checkbox does not call `onChange` when deactivated.
closesodoo/odoo#103429
X-original-commit: 4802c2528cfa23c5981fa30fa69cfa23f28faf05
Signed-off-by: Luca Vitali <luvi@odoo.com>
Add missing feature of the ModelFieldSelector popover :
* keyboard navigation
* additional debug value
* add default value page ( for dynamic placeholder)
* add validate callback
Migrate dynamic placeholder to be compatible with new OWL field.
task-2978722
X-original-commit: 929108e29168058fad5da85e0ff9c66d2c5b2525
Part-of: odoo/odoo#102603
Before this commit, it was not possible to edit the path via the
model field selector popover input (visible in debug mode). We fix that.
closesodoo/odoo#102462
X-original-commit: 084af201f1f4f4cb3476ab34d3dcd649a71a4254
Signed-off-by: Luca Vitali <luvi@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
There was an option in the legacy ModelFieldSelector
that could be used to prevent following the relations.
This option was lost since the widget has been
converted. This commit simply reintroduces the option.
closesodoo/odoo#102308
X-original-commit: 673faab4dec7a0df434cf0575303df97a36db0f1
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Click on the back button in the model field selector popover used to
often remove too many names in the path created via the selector. For
example, starting with "partner_id.name" and clicking on the back button
in the opened popover would give the invalid path "" instead of
"partner_id". We fix that problem.
closesodoo/odoo#102156
X-original-commit: e4a7b63c68a87d7afef987e8d036d7ba9c5b6f96
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
In a domain selector, have a selection field and the operator "is set"
selected, then change the operator to be "=". A crash occurs. This
happens because the category of operator change and thus the function
onDidTypeChange of DomainSelectorSelectionField is called with no
parameter. The same problem can happen with DomainSelectorDateTimeField.
We fix that by calling component.onDidTypeChange with the right
parameter in any case.
X-original-commit: a01c2473d93d0d123391ba0131ad505775b3c50b
Part-of: odoo/odoo#102156
A new useDraggable hook is introduced and used in the various components that
use the feature.
It relies on the draggable hook builder which is a generic way to prepare
specific drag and drop features.
X-original-commit: cb1cfe5f5efe1b683d7fdffde3718bd8bf1bcd86
Part-of: odoo/odoo#102153
The event listeners were added to the upload object instead of the xhr
object making them being called before they were supposed to.
closesodoo/odoo#102061
X-original-commit: 804467d7b0a583ab36a47212d482b41d29ca2203
Related: odoo/enterprise#32247
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Have a many2one field in a form view, and try to quick create a
record. If the name_create returns an error (e.g. ValidationError
in the model), the many2one field opens a form in a dialog (aka the
slow create). It thus properly handle the error.
However, before this commit, the error returned by the RPC was also
displayed in its own dialog (behind the form dialog).
This was due to a mistake in the Mutex, which forks the promise
returned by the registered action. When that promise was rejected,
the forked one was thus rejected as well, and it wasn't caught.
That later promise is only used to unlock the mutex, so we can
safely catch it.
closesodoo/odoo#101549
X-original-commit: fe9e044b9e03ac7fff5d314e6e207921a15c8965
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit moves the inline handlers of the `useSortable` hook
calls in the list and kanban renderers to proper class methods.
This allows said handlers to be overridden in child classes.
closesodoo/odoo#100986
X-original-commit: ec5ab1d389a0bdfb37c8b2c6766b6be1330085a7
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The useChildRef (used with the useForwardRefToParent hook) allows
to retrieve, from a parent component, a t-ref from a child.
Consider the following scenario:
- have a parent calling useChildRef
- have a conditional (with t-if) child calling useForwardRefToParent
- in the initial rendering, the child is displayed
-> ref.el points to the correct html element
- re-render s.t. the child is no longer displayed
-> ref.el is null, because the referenced element doesn't exist
- re-render s.t. the child is displayed again
Before this commit, at this point, ref.el will always be null,
even though the corresponding element comes back into the DOM. This
commit fixes the issue by correctly updating the ref, each time the
useForwardRefToParent hook is called.
closesodoo/odoo#100937
X-original-commit: 78d39c79993d1d63c189164f8104e5a3c90f2efd
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The purpose of this commit is to improve the domain selector UX with
multiple little changes:
- The model field selector popover is now autofocused when opened
- Removal of a div that appeared during a hover on "add leaf" and
"ellipsis button"
- Caret icon next to the root node selector
- Minor CSS changes
task-2861497
closesodoo/odoo#99321
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before, the small "caret" to the right of the dropdown was only
displayed if the current Dropdown was a child of another Dropdown.
It is sometimes necessary to display this caret in a parent
`Dropdown` in order to make the user understand that there is a
dropdown if he clicks on the text.
Now, it is possible thanks to a props to display manually this carret
if desired.
Part-of: odoo/odoo#99321
"Notebook" component had to be adapted to make the use of tabs
more consistent trough the app. The component now allows a use of
default tabs style in a vertical display
task-2950591
Part-of: odoo/odoo#98706
XML files are now declared in python module manifests. During the qweb
't-call-asset' directive, assetbundle will fetch the declared xml files,
apply the inheritance (t-inherit) and create a javascript service (for
eg: 'web.assets_backend.bundle.xml') which is added at the end of the
*.js mimifier file.
When the debug mode is activated, comments are added in the template
indicating which file the template comes from as well as the
inheritances applied to it.
****
JavaScript:
assets.js (module @web/core/assets) takes care of loading libraries,
javascripts and styles.
`loadJS(url)` (loads the javascript and returns a resolved promise when
the templates are also loaded via the '*.bundle.xml' service)
`loadCSS(url)` (loads the style a resolved promise when the file is
loaded)
`loadXML(xml, app=assets.defaultApp)` (load template into
application/owl, used by the `*.bundle.xml` services)
`getBundle(bundleName)` (get the bundle descriptor)
`loadBundle(desc)` (load the files and bundle from a descriptor)
templates (XML element content all owl templates)
A new `ready(serviceName)` method on boot.js lets you know when a
service is loaded are the require.
The xmlDependencies attribute no longer exists.
Python:
The xmls taken into account by assetbundle.py, applying `t-inherit`
inheritances and adding an `name_of_the_bundle.bundle.xml` service in
the generated JavaScript file.
****
Every manifest changes is into the next commit, except 'web_tour' in
this current commit as example.
Part-of: odoo/odoo#95500
This views has multiple custom features such as file upload, attachment
viewer and download.
A lot of files have been rendered obsolete and have been deleted,
notably `file_upload_mixin` which has been replaced by the
file_upload service and hooks.
closesodoo/odoo#99769
Related: odoo/enterprise#31145
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Since owl now uses error chains/causes when errors happen in the owl
lifecycle, when an error happens in the owl lifecycle, the displayed
tracebacks generally only contain the stack trace of where owl called
the corresponding lifecycle hook.
This commit modifies the error service and the error utils so that now,
when completing/annotating a traceback, we also add the tracebacks
(annotated when appropriate) of the error cause chain, as it contains
valuable debugging information.
This commit also makes it so that the QUnit suite logs the source of
each test failure (which may be an error with a chained stack trace)
closesodoo/odoo#98157
Signed-off-by: Géry Debongnie <ged@odoo.com>
Have a form view with a notebook.
In the notebook a page has autofocus, and is also invisible in some
circumstances.
Before this commit, the default page was always displayed, even if invisible,
its anchor was not selected though.
After this commit:
- if the default page is visible, display it.
- if the default page is not visible, select the first visible page
- if the default page was visible and the page has changed, don't select the default page at next render
- if the default page was not visible and becomes visible, select it at next render
closesodoo/odoo#97742
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- Name of the test
"utils > dates > parse smart date input"
- Before this commit
The test makes a comparison between the result of parse utils,
which yields luxon's DateTime objects in the user's local TZ
(patched by default to UTC+1 in the testing env), and locally
created DateTime objects in UTC.
This has no sense to compare a date in UTC with another in UTC+1.
The test was thus failing when ran between 11pm and 0am.
- After this commit
The test has been refactored.
Also, even if it has no impact on the parsing result, the local function
parseSmartDateInput now use a DateTime object in local TZ.
This has been done in order to avoid future confusion.
If you're wondering why it has no impact, it is because this function is
used in parseDate(Time), which always sets the local TZ at the end:
```
const a = {
foo: luxon.DateTime.local(),
bar: luxon.DateTime.utc(),
};
a.foo.equals(a.bar.setZone("default")); // true
```
closesodoo/odoo#99616
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Connect in your browser to a db on runbot with mail installed and wait
until the runbot put to sleep the db. After a while, a new request to
get im_status will be sent and nginx responds to it with an error 404
and an invalid JSON response. A traceback with a particularly bad
message is then shown. Here we improve the traceback message.
closesodoo/odoo#99430
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commits fixes the behavior of the confirmation dialog.
When a user dismiss a dialog using the close button or the
ESCAPE key, it should expect to execute the cancel action,
if any had been given to the dialog.
The behavior was missing, and the dialog was simply closed.
Tests have also been added, since this core component didn't
have any test since its introduction.
closesodoo/odoo#99418
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
On Chrome, have a field that supports autofill (you have to have set up an adress in Chrome first).
Click on that field, and apply the autofill proposition.
Before this commit, there was multiple crashes, roughly one for every handler of event `keydown`.
This was caused by the fact that the autofill feature triggers keydown events without the field `key`.
(https://bugs.chromium.org/p/chromium/issues/detail?id=581537, I could not find a better ticket).
This seems to be a bug on Chrome's side, since the spec doesn't mention that field may be unset (https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/key).
After this commit, there is no crash.
closesodoo/odoo#99348
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
The goal is to improve the dates utility functions (parse/format) by removing the timezone option, which is difficult to understand and has proven to be error prone.
- Rationale
When manipulating DateTime objects on the JS side, associated timezones
must be always coherent.
Until now, there were several code parts that had to check the DateTime
timezone and handle things differently in a case or another.
This sometimes lead to wrong code.
E.g. there was a bug in the DatePicker component because the DateTime
object it receives in props is in local timezone, but once it updates it
through the parse utility, the new object is in UTC.
- After this commit
The DateTime objects you'll get through deserialization or parsing are
always set in the user's local timezone.
The formatted strings you'll get through formatDate and formatDateTime
utils will always be expressed in the user's local timezone.
The formatted strings you'll get through serialization utils will always
be expressed in UTC.
- serializeDate and serializeDateTime
- expected input: a DateTime object (its timezone does not matter)
- outputs: a string formatted for the server expressed in UTC
- formatDate and formatDateTime
- expected input: a DateTime object (its timezone does not matter)
- outputs: a string formatted for the user, expressed in the user's TZ
- deserializeDate and deserializeDateTime
- expected input: a date(time) string provided by the server, in UTC
- outputs: a DateTime object in user's TZ
- parseDate and parseDateTime
- expected input: a date(time) string provided by the user, in its TZ
- outputs: a DateTime object in user's TZ
- Other changes in this commit
As the timezone option has been removed from parsing/formatting utils,
all their usage had been adapted in the codebase.
The large diff in dates_tests.js is because some tests were reorganized,
others were removed/adapted/joined.
A test has been removed from daterange_field_tests.js, because it has
no sense: it displays a date field as a datetime, but a date field does
not have any time information.
Part-of: odoo/odoo#98980
Co-authored-by: Julien Mougenot <jum@odoo.com>
Have a date picker component in a dropdown (like in Add Custom Filter),
open the related bootstrap datepicker by clicking on the date picker
input and select a date: the dropdown closes. In this fix, we make the
dropdown stay open in that situation.
closesodoo/odoo#99345
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Setting [(1, "=", 1)] as domain in the debug text area would make crash
the DomainSelector component because the sub component ModelFieldSelector
would not accept 1 as a fieldName prop due to its props validation. We
fix that by converting 1 to a string.
Part-of: odoo/odoo#99207
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
This commit standardizes the API of orm service functions by adding
a "kwargs" parameter, s.t. one can always use those functions even
if the target model overrides the corresponding method to add the
support of a given kwargs. Furthermore, to simplify those function
API, and to close the gap between the js and python APIs, we moved
the "context" argument inside the kwargs.
closesodoo/odoo#99018
Related: odoo/enterprise#30830
Signed-off-by: Samuel Degueldre <sad@odoo.com>
This commit changes the API of the "create" function of the orm
service to better reflect the API of the corresponding method in
models.py, which takes a list of record values in argument.
Before this commit, a call to "create" only allowed to create a
single record.
Part-of: odoo/odoo#99018
Ricardo Gomes Rodrigues (rigr)