Before this commit, the style of the pager in a grouped list was a little off.
- The colors of the previous/next buttons were too dark in enterprise (because of: odoo/enterprise@f26203eb24)
- The pager's input lost its alignment.
After this commit, the situation is much better, colors are okay and the pager's
input doesn't jump randomly somewhere else.
closesodoo/odoo#80007
X-original-commit: 9da7620dd42f0ba940477cd4d05e6ac179ce2095
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
This commit moves the ZXing library (used for QR/Barcode decoding) from
`web_enterprise` to `web` so it can be reused in other modules.
Change motivated by odoo/odoo#78204closesodoo/odoo#80014
X-original-commit: 8c81e2f7c614c55247138278ffdf914e2866ec41
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
This commit fixes some issues happening when scrolling
with an anchor in Odoo. When the anchor was contained inside
of a notebook and no scrollable was found, a crash happens.
This fix improves the behavior in notebooks by showing the
correct pane before scrolling in form renderer. The scrollTo
util has been improved to remove duplicate lines and handle
multiple situations (0, one or more scrollables). Tests haven
been written to test such behaviors.
closesodoo/odoo#79935
X-original-commit: 4c2b807d1cb32e52a1b1fb5e6c80fb7e933940bc
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, `_super` was set like this
`this._super = patchFn.bind(this);`
this triggered an update in owl reactivity.
To prevent the update, we use Object.defineProperty
`Object.defineProperty(this, "_super", { value: patchFn.bind(this) })`
closesodoo/odoo#79893
X-original-commit: a7a2b3022c88d1fbf9c242ad3668db35fc704c13
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Before this commit, the FieldDomain (using the DomainSelector)
didn't work well for manual edition of large domains (i.e. via the
"code editor"). For instance:
- the editor was an input, so limitated to 1 line
- the user friendly representation of the domain was redrawn each
time the input was blured (we don't need this, and it flickers)
- the count (search_count rpc) was recomputed at blur as well
(could thus freeze the interface)
This commit fixes those issues as follows:
- use a (automatically resizable) textarea instead of the input
- do not format the content of the textarea when it is blured
- do not update the user friendly part of the widget when the
textarea is blured
- do not recompute the count when the textarea is blured
- add a button to allow to manually re-compute the count
For both debug and non-debug mode, we also no longer wait for the
count to be fetched to render the widget. We display a spinner
until the rpc is done.
Task 2619505
closesodoo/odoo#79886
X-original-commit: f4e3a754a1b66dd95fa3bfb50ec1fb8ac98864ed
Related: odoo/enterprise#22295
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In a list view in multicompany:
- select all records with the main checkbox above the list
- click on "Select All" to select every record for that domain
- open the "Actions" dropdown and try to do an action
Before this commit, there may be a fail on some records due to some
records not belonging to the right company.
This was because when fetching the active_ids from the server,
the context, and hence the allowed companies, was not passed to the RPC.
After this commit, the call to retrieve active_ids contains the allowed companies
and the correct records are returned and treated.
opw-2669292
closesodoo/odoo#79795
X-original-commit: 894430076423c81ec0804158249c354115030e9e
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Achraf <abz@odoo.com>
The error "ResizeObserver loop limit exceeded" was catch by the browser error
global listener. this error was wrongly flagged as a CORS error.
This error is well known to be useless and can safely be ignored.
We do so.
Task-2670745
closesodoo/odoo#79645
X-original-commit: 1c21e2d6fa3c25d2a920902ebecd19f6229b56d8
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet <age@odoo.com>
Before this commit, luxon wasn't configured with respect to the
user lang, meaning that months weren't translated (for instance,
in the filter menu, date(time) filter options, or in the datepicker
displayed in the "Add custom filter" sub-drodown).
closesodoo/odoo#79644
X-original-commit: 9530b0a2462aca0938ce315cee262b147b7a5634
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, automated actions could not raise "normal"
errors anymore (e.g. UserError). Indeed, since the wowl refactoring,
it always shows the custom BaseAutomationErrorDialog when an error
is thrown in an automated action, even if it is a standard error
well-known by the framework. Before the wowl refactoring, those
errors were handled normally if possible, and when it wasn't the
case, the custom BaseAutomationErrorDialog was used.
This commit restores that behavior.
Complete steps to reproduce:
- Install base_automation module
- Install an app for the base_automation to trigger (e.g. Sales)
- Turn on debug mode
- Go to Automated Actions
- Create an action with Action To Do is Execute Python Code and the Trigger is On Creation & Update
- Set the model to your app (e.g. SalesOrder)
- Put `raise UserError('Test')` in Python Code section
- Go back to the app, try to create a new record in the model you set for the automated action to trigger
- Compare the result with 14.0
closesodoo/odoo#79611
X-original-commit: d65d742de1b30a00b3ffd872c042e002736f7f6b
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Report client action can need context data to be properly be
displayed. But because all the required data is not put in the url,
reloading didn't work.
However, there is the current action data kept in the session storage
which is a solution to avoid the described problem. But it didn't
work because of the implementation of the report client action execution.
It was in reality executing two actions: one for the report, gathering
the data and fallbacking to a client action. By doing this, the
session storage would not have the necessary data kept for reloading the
page.
The fix is simply to duplicate the code of the client action execution
instead of calling doAction again.
closesodoo/odoo#79567
X-original-commit: 3fc095c57888e5f69729e1a5a6edea97c4c098b6
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit:
Some navbar app sections items were
not properly indented in dropdowns.
After this commit:
The indentation is restored, leading to
a clearer usage of the navbar menus.
closesodoo/odoo#79545
X-original-commit: e8fad2c01b627b9cf0b696d68a59ec773015d6cf
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit normalizes the different feature/browser detection modules'
implementations to avoid difference between "newer" implementation and
legacy ones.
Its main goal is to ease future maintainability by having only one
single source of truth for feature detection and, also ensure fixes
applied to one version are applied everywhere.
closesodoo/odoo#79499
X-original-commit: 3b90e15983edcb79e6bd6e45685926cd4dfaae6b
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Following commit odoo/odoo@ce4e6bd4b1 ,
the DateTimePicker design was revamped but not the DateRangePicker.
This commit adapts the DateRangePicker's styling to match the
DateTimePicker's design.
closesodoo/odoo#79497
X-original-commit: c5c944f4240dba8f8b100d73ef1a9c8870c705a7
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
By being lazy loaded, the DateRangePicker library's CSS files where
loaded after the Odoo specific customizations (bundled in the common
assets), resulting in some CSS rules being overridden by the one from
the library.
This commit fixes it by removing the lazy loading of the library's
(S)CSS to be able to handle their loading order. Also as our
customizations requires SCSS pre-processing, they can't be lazy-loaded.
Note: the library's JS assets are stil lazy loaded to minimize the
performance impact of this change.
X-original-commit: 4436411b6fd898d1fa32a9149b7dc12efe3ef9f8
Part-of: odoo/odoo#79497
Following commit odoo/odoo@8c55713dcc ,
the DateTimePicker (TempusDominus) library's SCSS file was pushed so low
in the (S)CSS assets loading order that it overrides the Odoo specific
customizations (done in `datepicker.scss` file).
This commit restores the correct loading order, also taking into account the
changes (i.e. variables) introduced in the afore mentionned commit and
fixing necessary CSS rules (cf. selected day's color) to keep the same
styling.
X-original-commit: 7fd486cd93154d680cb69e3f34aa04478bc62a63
Part-of: odoo/odoo#79497
Reproduce :
(With timezone GMT+3)
- Create any record R1 with previous day's date and time after 21:00.
- Create any record R2 with today's date and time after 21:00.
- Create a filter to show all todays records (Date is between "<TODAY'S DATE> 00:00:00 and <TODAY'S DATE> 23:59:59".
Result :
Even though R1 is in yesterday's date, it will show in the list.
R2 will not show in this list.
Explanation :
This behaviour has been observed in several modules, for any timezone but UTC & only with custom filters default datetime values.
The search was applied on [datetime(UTC) + 2 * offset] because the timezone wasn't correctly set.
Solution :
Timezone is now correctly set on default datetime values.
closesodoo/odoo#79516
X-original-commit: 6fd105b89ea30695d6a324a5aa0b2004987c2e47
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Onockx Audric (auon) <auon@odoo.com>
This commit fixes a bug when you clicked on a link related to an anchor.
e.g. an <a> tag with an href="#anchor". The scroll to the element
with id="anchor" didn't happen because the position was not found correctly.
The fix uses getBoundingCLientRect to get more precise positions
of the element with the anchor and the scrollable area.
A test is introduced to check scrolling for multiple anchors in a template
with a more complex structure (Note: the test fails without the fix).
The scroll behaves differently depending if the target is an anchor or
an element. An other test has been added for the command palette about this
behavior.
closesodoo/odoo#79310
X-original-commit: b0da44d62f85d6530f8e568025f7fea25c5454c5
Signed-off-by: FrancoisGe <fge@odoo.com>
Before this commit, when the value is null in the pivot view on a float
field, we format the value before displaying it. The problem is the
formatFloat method does not check if the value is null and used the
`toFixed` method to fixed the number of digits to display for the value.
This commit uses the value if it is not value otherwise use 0 to fixed
the number of digits. That is, when the value is null, the formatter
will return "0.00" (if the number of digits expected is 2) instead of
raise an error.
Steps to reproduce:
==================
1) Go to the helpdesk App > Reporting > Tickets Analysis.
2) Go to pivot view of this report.
3) Add the measure called "Rating (/5)"
Expected behaviour:
==================
Show the pivot with empty cells or 0.00 if the average of this measure
has no values.
Actual behaviour:
================
Traceback shown because it cannot read 'toFixed' property of null.
task-2665899
closes#79034
X-original-commit: d142705d9262dfa5fb489611ae0b5a2a04ff6fab
Part-of: odoo/odoo#79291
Steps to follow
Edit the account.move view (with studio for example)
Set the lines readonly property to [["partner_id","=",False]]
Create a new move
Add a partner
Add a product
Remove the partner
-> A traceback appears: widget.$el is undefined
Cause of the issue
widget.$el is used after the widget has been destroyed
The fix was already present in 14.0 (3fd7b2009e)
but we still need to keep the test
opw-2557142
closesodoo/odoo#79261
X-original-commit: 71e6d7e510ff9d44fe8deb16f29d50b021709074
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
This commit adds "unique" array utility function which
returns a copy of the given array but without any duplicates.
closesodoo/odoo#76472
Related: odoo/enterprise#20833
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, useAutofocus hook used the effect dependency
to check if the target is in dom but this dependency is computed
in onWillPatch and can be outdated when checking it in onPatched.
Now, the target isn't a dependency anymore and is computed just
before the check.
Part-of: odoo/odoo#76472
This commit adds touch events helper for tests and new util used
to constrain a number between two values. The purpose of
the commit is to introduce the ActionSwiper component using those
functionnalities.
closesodoo/odoo#78426
Related: odoo/enterprise#21712
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Following-up to previous commit, this one makes the
`get_translations_for_webclient()` more defensive with regards to the
absence of a `lang` key in the context, rather than relying on callers
to protect it. The rest of the logic was already fine with this.
This allows simplification of the `session_info` logic and removal of
the conditional for `translation_hash`.
Further cleanups in `session_info()`:
- removed a duplicate calls to `session.get_context()`
- removed duplicated resolutions of `request.session.uid`
closesodoo/odoo#79182
X-original-commit: 3eca1a2e58b8c644c0701d33d0c9d0330bdc234f
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Since [1] and [2], the mobile app gets this error when trying to login
on v15, while it was working fine in v14 with TOTP enabled.
The 'authenticate' JSON-RPC route tries to authenticate the user and
then call `session_info()`. As no UID is defined, some methods in
`session_info()` raise an exception and an unexpected error is sent:
* `_is_public()` -> "Expected singleton: res.users()"
* `get_web_translations_hash()` -> "lang"
In this fix, this exception is avoided and the proper result is sent,
allowing the authentication process to continue.
Steps to reproduce:
* Try to connect to an account with TOTP on the mobile app (v15+) => BUG
Refs:
[1] odoo/odoo@80d74e7ee0
[2] odoo/odoo@401fc7efe9
X-original-commit: 65dca67ecdcc2228d90781a9f5ccd99f290ada6c
Part-of: odoo/odoo#79182
Before this commit, if you create a new app with a custom icon with
studio and you open the command palette with the namespace "/", then
you will have an error message.
We have this error because the home_menu does not support custom menu
icons.
closesodoo/odoo#79158
X-original-commit: c5f5b1de07ee6b8b09ae1821c4c0debc0d09f55e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the router didn't considered as equal an
integer value given as an integer or as a string (e.g. "1" or 1),
whereas form the url point of view, it's exactly the same, and the
information is lost anyway.
As a consequence, pushing something like { id: "1" } in the url
that already contained id=1 created a new entry in the history,
which isn't what we want as the url is the same.
This commit fixes the issue by converting string values into
numbers when it is possible.
This commit also changes the way the action service pushes the id
and active_id in the url, as there's no need to pass string values
anymore (this was the case in the early days of the wowl branch).
closesodoo/odoo#79132
X-original-commit: e576155fc55e0493a1d1236960dd1c7a36db9e8c
Related: odoo/enterprise#21948
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The show_effect was either "True" or false which is inconsistent.
This was caused by the fact that the string value came from the backend
and the boolean came from the default value of get_param.
By wrapping the result of get_param in a bool constructor, we make sure
the type is always consistent.
closesodoo/odoo#78742
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
A stat button set as disabled was used to just show some statistics
without an action on click. However, on tasks executed by the Form,
all the buttons would be temporarly set as disabled then set back to
enabled. This would lose the original state of the button and make them
all clickable.
The way it worked before v14.5 was most likely because the action
manager would not throw an error on an action with those "invalid"
arguments.
Also, a button without a type and name will now be set the disabled
attribute automatically.
closesodoo/odoo#78839
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In https://github.com/odoo/odoo/pull/78652 a fix was made in the layout
designer guaranteeing that the company_details field followed the correct
address format set by the company. However, this fix didn't take into account
all company data, making some `format_address`es raise a `KeyError`. This PR
fixes that by using the company_date defined in `_display_address`.
Fixes https://github.com/odoo/odoo/issues/78942closesodoo/odoo#79097
X-original-commit: 3cdc770c4966cef88362f8119a96de5501d21b18
Signed-off-by: Leonardo Pavan Rocha <lpr@odoo.com>
This fix adresses an issue when editing the control panel from Owl based views.
Currently, if you don't have a custom search to an Owl view, the template editor will appear blank as the component misses its searchViewId value from its props.
The commit also introduce a test when clicking the edit ControlPanel button in that case.
With the fix, you can edit the search template and get the default template
closesodoo/odoo#79023
X-original-commit: f5c8e855f07d68a34dccd9977b53999911a66f62
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
before this commit: applying readonly attribute on toggle_button doesn't work,
toggle_button still clickable and value is still changed even though widget is
readonly, there is no effect of readonly attribute on toggle_button widget.
after this commit: if toggle_button widget has readonly attribute then it will
not be clickable, button of toggle_button will be disabled so that user can
easily understand that element is not clickable.
task-2339995
closesodoo/odoo#79012
X-original-commit: 74d42d4a328c517d0ced56d9e437fb40b00a14d0
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
ISSUE:
The width of menu items is computed (in 'initAutoMoreMenu')
to check for overflow and fold extra items in a "+" dropdown.
[1] When the page is not in cache yet, the width is computed
while font is not loaded yet and the value obtained is not
the same when font is already available [2] (e.g. if we go
to another page).
This explains why we get an additional folded item comparing
[1] and [2].
The goal of this commit is to fix this behaviour by recomputing
the width after font loading.
IMPORTANT REMARK:
When the code was overridden on 'initAutoMoreMenu', the idea
was to update the menu as soon as the DOM is available and add
adjustments after in this order:
[A]- _adapt();
[B]- await _afterImagesLoading(...);
_adapt();
But since it's not possible to prevent the changes in menu
width after images are loaded, we remove the first update
in [A] (This update has no effect in current code because
it was placed after the "await..." in [B]).
And we still start the updates on menu after image loading.
task-2618929
closesodoo/odoo#78959
X-original-commit: 69b97d8e95da3efa62882228e79dc357e19e0fe6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The current code in 'initAutoMoreMenu' doesn't work properly
on navbar after the update on dropdown in [1]. Small tweaks
were added in this commit to fix that.
[1]: 84715436d87bb05b421bc9ccaacda67d07571690
task-2618929
X-original-commit: 29b9280c44534d2f210dbcea83e0049365949f48
Part-of: odoo/odoo#78959
* remove `component_extension_tests`, that's a test from web and
already tested by web, no idea why it's rerunning in POS
* remove all failfast specs, after discussion with ged, seb, and
xdo it was considered not useful: it's mostly for the runbot but
turns out to be pretty minor as far as positives go, and it makes
fixing errors much harder
Part-of: odoo/odoo#77735
By delaying the check of `didLogInfo` until run end, it becomes
possible for the test suite to start running before all the test
modules have loaded, which leads to some of the modules loading after
the test suite "ends" and start running at that point, leading to
multiple teardowns of the test suite.
This would occur in the POS test suite, leading to the `QUnit.done`
callbacks running multiple times, and multiple `"test successful"` to
be emitted.
This has historically not been an issue (hence having remained
undiscovered), but with the "success state" being a `Future` it now
breaks the corresponding test, as a resolved future can not be
re-resolved.
Part-of: odoo/odoo#77735
The new handler changes the behavior of `wait_ready`: before it would
wait for the `ready_code` to be `true` *or a settled promise*.
Now it waits for `wait_ready` to resolve to true, whether it's a
promise or not.
Part-of: odoo/odoo#77735
When a componentes is in a modal and uses the positioning hook (filter dropdown in the Search More modal for example), it will shifted from the toggler button.
This is due to a `-webkit-transform: translate3d (0, 0, 0);` applied on the `modal-body`
which influences the `position: fixed` attribute of `.o-popper-position` in the `dropdown-menu`
"It is positioned relative to the initial containing block established by the viewport,
except when one of its ancestors has a transform, perspective,
or filter property set to something other than none (see the CSS Transforms Spec),
in which case that ancestor behaves as the containing block. "
See: https://developer.mozilla.org/en-US/docs/Web/CSS/position
the translate3d was applied with https://github.com/odoo/odoo/pull/20314
As the bug is no longer exists, we can remove this style.
opw-2668638
closesodoo/odoo#78775
X-original-commit: 1f86e285aeb69578378cc89771cd090cc29ccc7d
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Achraf <abz@odoo.com>
The commit 6135b04 forgot to remove from the assets_frontend bundle
the DebugMenu which depends from the @web/core/commands/... features.
closesodoo/odoo#78863
X-original-commit: 60f000a3d538cbc64f86aeef8aae66149d60ff7c
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bruno Boi <brboi@users.noreply.github.com>
Lucas Perais (lpe)