Issue:
Have a grouped list view with several pages, go to the next page,
open a group and click on a record to open it in form view. Click
on the breadcrumb to go back to the list: the offset is lost, and
we're back in page 1.
After this commit, the offset is correctly kept.
opw~3851390
closesodoo/odoo#162969
X-original-commit: 8dbf154fdbbff7790c99b3f91d3c1896d436a346
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, several qunit load state tests sometimes
failed. They all follow the same pattern:
- trigger an "hashchange" event to simulate an update of the url
- wait twice for nextTick
- check the DOM reflects the url change
However, waiting for 2 ticks isn't enough. Indeed, when the url
hash is set, our mock location object dispatches a "real" hashchange
event on window, but it does it after a setTimeout [1]. Then, the
webclient is notified (via the router service) of the url change,
and reacts by loading the appropriate action. This then requires
2 ticks, because we first clear the DOM with the BlankComponent,
and then we mount the requested action/view.
This commit makes those tests more robust by waiting for a
setTimeout before the 2 nextTicks.
[1] https://github.com/odoo/odoo/blob/1882d8f89f760bd1ff8a2bf0ae798939402647a3/addons/web/static/tests/setup.js#L52
Runbot issue~37030
closesodoo/odoo#162939
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
A few x2many list embedded in form views have the "editable" attr
set to "1". Normally, the valid values for this attribute are "top"
and "bottom". Regular list views are validated, but not lists
inside form views.
When set to "1", some features of the model aren't enabled. For
instance, when the current page is full and the user adds a record,
the limit isn't temporarilly increased for the added record to be
displayed on the current page, like it would be in editable="bottom"
lists, so the user doesn't see the record he just added.
The issue can be observed in the stock move form view for instance.
This commit is only good for stable versions: we add a fallback
on "bottom" s.t. if the editable attribute is set, it's always
either "top" or "bottom".
In master, we'll probably rethink the API.
opw~3860903
closesodoo/odoo#162832
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, we didn't correctly detect when to prefix the
value of an url field for the href of its link.
closesodoo/odoo#160916
X-original-commit: 27458e3bdb545f550e60f1bd39addf188151c38b
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Have an x2many with several pages containing a field with a
readonly modifier (in the view, not in the field definition), e.g.
`readonly="1"` in the arch. Have an onchange that returns an
UPDATE command for a record that isn't in page 1 (so a record we
haven't read), with a value for that readonly field. Before this
commit, the value was sent in the UPDATE command, even though
readonly fields shouldn't be sent.
The difficulty here is that we can't always evaluate those readonly
expressions, as they can depend on other fields, which we didn't
read if the record is in a page we didn't browse to yet. However,
"static" expression like `"1"`, or `"context.get('something')"`
can totally be evaluated, and they should. This is what this commit
does.
Steps to reproduce the issue:
- Install mrp
- Go to Manufacturing > Products > Bill of Materials
- New:
- Product: quick create "B1"
- Components: two lines: quick create "C1" and "C2"
- Save
- Manufacturing > Operations > Manufacturing Orders
- New [in that form view, set the limit of the x2many to 1]:
- Product: "B1"
- Save
- Change quantity to 2
- Save
=> Invalid Operation
opw 3819253
closesodoo/odoo#160129
Signed-off-by: Géry Debongnie <ged@odoo.com>
Have a list view with multiple groupbys and a lot of records to
have pagers displayed. Open a group (first level). The pager of the
group uses the number of records instead of number of (inner)
groups as total.
This commit fixes the issue. The pager now correctly allows to
navigate through inner groups.
closesodoo/odoo#157995
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Before this commit, it could happen that the More dropdown was
displayed, but it only contained a single stat button. This isn't
what we want, as that single button could simply be displayed
instead of the More dropdown toggler.
Task 3778382
closesodoo/odoo#156241
Related: odoo/enterprise#58565
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, the changed test sometimes failed because we
expected the image to be set, but it wasn't (yet). This commit
increases the delay.
Runbot error 56099
closesodoo/odoo#157347
X-original-commit: 289e2b20673ba44fb8ce7afe19bae3bfa94e5f8c
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, if a SelectionField was used in a kanban view
alongside the HandleField (enabling re-sequencing, i.e. drag&drop),
the "select" element couldn't be edited. This is because the d&d
feature calls preventDefault on almost all "pointerdown" events
occuring in the card, and the "pointerdown" event is the one that
opens the select.
There's no usecase in 17.0, but there's one in master, in the
product document kanban view.
We fix this in 17.0 which is the version that introduced the kanban
version of the SelectionField.
closesodoo/odoo#155827
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Before this commit, in a grouped kanban view with progressbars
and an aggregate field, after clicking on a bar to filter
records, the aggregate value was always 0 (at least when grouped
by a many2one or date(time) field).
This was due to a mismatch when trying to find the value of the
aggregate in the web_read_group result, as when grouped by a date
or datetime field, the key is `fieldname:granularity`, and we were
looking for the fieldname only. And for the many2one case, we were
comparing a pair [id, display_name] with an id.
This commit fixes the issue. It also fixes the mocked version of
read_progress_bar in the MockServer, s.t. we can correctly
reproduce the scenario in tests, as in the previous version, keys
in the returned object weren't computed the same way as in the real
read_progress_bar (e.g., "14,Mitchel", instead of "Mitchel"). A
similar fix has been done in [1]. This allows us to introduce a
test when grouped by many2one, which doesn't work as of 17.0.
[1] fd759f18d056844c486a68d0c394df5a03e789f0
closesodoo/odoo#155701
X-original-commit: 69b1809ed763d03560983bb0e4c996946dd694c5
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit backports the test introduced in odoo/odoo#155154, as
it is relevant to have it in every versions to ensure that dropdown
menu (i.e. submenus) are correctly tested.
closesodoo/odoo#155218
X-original-commit: 8915c8db63d2ebc697bbfc073e3504589a26b4b8
Signed-off-by: Bastien Fafchamps (bafa) <bafa@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, calling _applyCommands with a lot of commands
DELETE or UNLINK on a StaticList already containing a lot of
commands was very slow. This happened for instance in the Automated
Rule form view, click on "Add an action", and in the dialog form
view, select a "mail" type, e.g. "Add followers". In that form view
there's a many2many field "available_model_ids" which contains at
first almost all models of the database (LINK commands). Switching
to a "mail" model restricts those models to the ones inheriting
from the thread mixin, i.e. it generates a lot of UNLINK commands.
On runbot, in represents 1000+ LINK and UNLINK commands. This
could take several seconds.
With this commit, we no longer iterate over all commands when
applying UPDATE, DELETE or UNLINK commands. Instead, we generate
at first a mapping of record ids to their own commands, and we
then have a quick access, given a record id, to the list of his
commands, which is small in comparison to the whole list of
commands. After iterating over all commands, we generate the new
list of commands and we update this.records and this._currentIds
to do the necessary cleanups (i.e. removing records and ids for
which we received DELETE/UNLINK commands).
task 3599674
closesodoo/odoo#154568
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
This commit follows [1], which attempted to fix CORS errors
occurring when we access the `cssRules` property of stylesheets,
to detect scss compilation errors and display a warning to the
user.
[1] doesn't seem to be enough, as we faced another source of CORS
errors. Indeed, in non-secure http, the error is raised even if the
origin is the same.
We never want this access to crash anyway, as it's a nice to have
feature, and if reading `cssRules` is forbidden, there's nothing
the user can do anyway. For those reasons, we decided to simply
protect the code with a try/catch.
[1] odoo/odoo#152696
opw 3746910
closesodoo/odoo#154347
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Before this commit, to render the table, the project task list
view computed the list of selected records once for each cell,
and then iterated over that selection to check whether selected
tasks were all associated with the same project (to set the
stage_id field readonly if not). However, computing the selection
requires to iterate over all records, so the rendering was O(n^2).
As a consequence, the rendering of (not so) large tables was very
slow (~1s for 80 records).
With this commit, we compute only once for the whole table whether
the selection contains records from different projects.
closesodoo/odoo#153611
Signed-off-by: Géry Debongnie <ged@odoo.com>
Have a grouped list view s.t. there's a group with enough records
to have a pager in the group. Go to the second page of that group.
Then, apply a filter such that there's only a single page remaining
in the group. Before this commit, no record was displayed, because
the previous offset wasn't reset to 0 it should have been. With
this commit, the offset is recursively reset, so we correctly
display the records of the first page after a reload.
closesodoo/odoo#153494
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Commit [1] moved (almost all of) the code of formatFloat from
views/fields/formatters.js to core/utils/numbers, to make it
accessible in the frontend. A formatFloat function was kept in
formatters.js to handle the false case, which makes no sense in
number utils, but is useful for fields. However, a lot of imports
have been updated to use the numbers.js instead of formatters.js
(i.e. they no longer benefit from the support of false), whereas
they are actually formatting field values, so they should have
kept using the formatFloat from formatters.js
This commit adapts the places where the formatFloat to use must
come from formatters.js, not numbers.js.
[1] https://github.com/odoo/odoo/commit/054ca0a19aaf297f420a1b478b93ae26f1b943b8
task 3722043
closesodoo/odoo#152810
Related: odoo/enterprise#55919
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Before this commit, we tried to access in javascript the cssRules
property of some stylesheets, to parse and display to the user
potential css errors, to help him to detect and fix them. [1]
Since a recent change [2], people get tracebacks on website pages
in odoo.com (without being logged in).
The issue comes from the fact that when assets are served via a
CDN (which is the case in odoo.com for not logged users), reading
the cssRules throws a CORS error. This error is logged in the
browser console.
We only spotted the issue since [2], because it delays the moment
we access the cssRules property (we wait for translations). Thanks
to that, the error service is ready and able to handle errors, and
it does display the error in a dialog, which allowed us to detect
the issue.
To fix the issue, we filter out stylesheets with a different
origin.
[1] 5e920db3ee
[2] 332268c724closesodoo/odoo#152696
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Create an automation rule for a field for which there's no onchange
yet. The rule type is "on_change" (on UI change).
This type of automation rule adds an onchange method on the
selected fields, which thus involve the onchange mecanism: the
"on_change" attribute will be set on that field nodes in views,
s.t. when the user changes it, onchange rpcs are done.
However, views are cached, and creating such a rule didn't clear
the cache. So if the view was already in cache, the rule seemed
not to work, because the client still received the old version of
the view, without the "on_change" attribute.
This commit clears the cache when such a rule is created, s.t.
after a client reload, the feature gets enabled as expected.
opw 3701125
closesodoo/odoo#152498
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, there was a race condition with the statusbar
field, and more specifically with useRecordObserver.
The issue could be reproduced in the form view of project.task. In
an existing task, belonging to a project with some stages, change
the project to another project with its own stages. It might happen
that the displayed stages weren't the ones of the newly set project.
If this didn't happen directly, this happened upon saving (i.e. the
correct stages are displayed just after switching the project, but
as soon as the user saves the record, the former stages are back).
This happens because useRecordObserver used an outdated version
of the props to get the domain (i.e. the props of the component
have been updated, but useRecordObserver still used the old version,
in particular the old props.domain).
This commit fixes the issue by ensuring that we always use the last
version of the props.
opw 3693113
closesodoo/odoo#152433
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
In form views, when the user closes the tab while having unsaved
changes, and if those changes are valid, we want to save them
automatically before leaving.
Before this commit, there could be situations where the changes
weren't actually saved. For instance, if they involved an heavy
payload for the write rpc, or if the network connection was poor,
it might happen that the xhr is killed. Or at least, browsers do
not offer any guarantee to wait for those xhr to reach the server.
Instead of a classical xhr, we thus use navigator.sendBeacon which
ensures that the data will be sent reliably [1]. There's a drawback
though, as its payload is limited. When the payload is too heavy,
sendBeacon simply returns false and does nothing. In this case,
we prevent the page from unloading and display a notification
suggesting the user to manually save his changes before leaving.
[1] https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon
Task 3537838
closesodoo/odoo#151834
X-original-commit: 0b53daa60ee5b370def21c8e0e30a6819597a0e4
Related: odoo/enterprise#55457
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Before this commit, when there was an error while compiling scss,
information was added in the compiled css bundle s.t. the client
is aware there was an issue and can indicate it to the end user.
In particular, a dialog was shown with a static message, and
with what should have been the python stack trace. However, the
stack trace was missing.
In addition, a banner should have been displayed in the bottom left
corner the screen, telling that a former version of the bundle was
used as the new one is in error. This banner wasn't displayed
either.
Finaly, forwarporting odoo/odoo#149230 automatically closed the
dialog, as we close all dialogs when executing an action (in this
case the first action when the webclient starts). As a consequence,
the dialog was no longer displayed either.
To sum things up, before this commit, 1) there's no longer a dialog,
even if there were, 2) the dialog doesn't contain the stack trace,
and 3) there's no banner.
To fix 1), we simply display a notification instead. Opening a
dialog for this simply doesn't fit with odoo/odoo#149230, and a
sticky, danger, notification is totally fine for this.
A notification being smaller than a dialog, it says to open the
console to see the stack trace instead of inlining it.
2) has been inadvertendly introduced by [1]: quotes in the error
were doubly escaped (\\"), meaning that they weren't escaped at
all, so the js couldn't properly read the value
And the source of error for 3) was that the last line of the css
bundle (the sourcemap comment line) wasn't valid. It started with
`//*`. As a consequence, the remaining of the file wasn't processed,
and that's exactly where the assets bundle error handling code
inserted the error information.
[1] 64bbef5bc1closesodoo/odoo#149543
Related: odoo/enterprise#55257
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Commit [1] replaced all uses of env._t by calling the _t function
directly, and removed _t from the env. This commit adapts a
forgotten occurrence.
c07181b20b
opw 3664779
closesodoo/odoo#149176
Related: odoo/enterprise#54195
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Before this commit, the StaticList and its Records shared the same
reference to the activeFields. When an x2many record was opened in
form view (and that form view wasn't inline), we altered the active
fields to add the information coming from the form, and we loaded
the corresponding data for the record we open. However, by doing
so, we also altered the active fields of all the other records,
for which we didn't load the corresponding data. From that point,
a rendering of those kanban records could lead to a crash, because
we iterate over active fields and make the assumption that there's
an entry for each of them in data, which isn't the case.
For instance, this happened in a dev branch in project, in mobile:
after opening a sub task in form view, if we switched to another
notebook tab and then switched back, there was a crash.
This commit fixes the issue by creating a copy of activeFields for
each Record, s.t. when a record is opened in a dialog, only its
activeFields (and those of the StaticList) are altered.
Note that activeFields of the StaticList must be altered in this
case to ensure that the onchange spec is properly generated, with
the fields of the form view.
closesodoo/odoo#148351
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Before this commit, the key for the cache of compiled templates
(in the useViewCompiler hook) only relied on the arch, i.e. we had
a cache hit if we had to compile an arch that had already been
compiled before.
However, the Compiler to use might change. When this happens, the
template must be re-compiled, obviously, as the ouput may differ.
For instance, have a kanban arch with a js_class (pointing to a
custom view with a custom compiler), and have that arch used in an
x2many (where js_class is ignored, i.e. where it is rendered with
the basic kanban renderer). This happens in project, with the task
kanban view, which is also used for the child_ids field, in the
task form view.
This could lead to traceback, as the compiled template might refer
to attributes of a the KanbanRecord that only exist on the custom
KanbanRecord, not on the basic one.
Part-of: odoo/odoo#148351
Before this commit, the pager hook use useChildSubEnv to patch the
config with the pagerProps. We used useChlidSubEnv because this
information only targets one of its children (the ControlPanel),
not the components using the hook themselves (e.g. the controllers).
However, this has an infortunate side-effect. If a component using
the pager hook also wants to patch the env (e.g. with useSubEnv),
and does it after calling usePager, it will erase the sub env
created by the pager hook for the children by its own.
This happens with the TimesheetTimerListView:
```js
setup() {
super.setup(); // super will call usePager
useSubEnv({
config: {
// this config doesn't contain the pagerProps
// generated by usePager, as it's the config of
// the component itself
...this.env.config,
disableSearchBarAutofocus: true,
},
});
}
```
Since using useChildSubEnv in this case isn't necessary, we simply
replace it by useSubEnv.
Note that we don't add a framework test for this issue, as it
would be totally artificial. Instead, the enterprise PR adds a
test for the TimesheetTimerListView.
opw 3636182
closesodoo/odoo#147393
X-original-commit: 8dbf8021842b94b9b067e2582f3aa92d31ef62e5
Related: odoo/enterprise#53342
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the layout of the import module form view (in
the dialog) was broken. This was due to unnecessary and wrong use
of col/colspan attributes.
closesodoo/odoo#147271
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Before this commit, and since [1], automated rules of type
"on_change" (i.e. on UI update) didn't run. This is because the wrong
field (trigger_field_ids) was used to record fields for which the
rule must be triggered. For that type of rule, the field to use is
on_change_field_ids. As a consequence, those rules were not
correctly created, and thus they didn't properly react to field
changes.
[1] odoo/odoo@8bdac7e26c
opw 3632084
opw 3595411
closesodoo/odoo#146780
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
When defining a selection field as field dependency, one must
specify the options of that selection field (or at least an empty
list if options don't matter). Because if that field isn't in the
arch (which is the point of defining field dependencies), and the
model has to process a value for that field, it will crash in
`parseServerValue` (selection case).
There's no scenario to reproduce this in standard, but one can
build one: edit the project task form view arch, in the child_ids
x2many, set mode="tree,kanban", but do not add the kanban nor the
form view inline (s.t. default views are used). Then open the view
in mobile and click to add a record in the relation.
closesodoo/odoo#146435
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Before this commit, columns in list views could be manually resized
only if there were records in the table. For the ungrouped case it
makes sense, as the table is empty anyway. However, for the grouped
case (either with empty groups, or with all groups being folded),
the list contains no records, but resizing could make sense as
there could be aggregate values displayed on group headers.
Technically speaking, there's no reason to restrict the resize
feature if the table is empty. Functionally wise, a user could get
confused if the feature is sometimes available, and sometimes not.
For that reason, this commit simply removes the isEmpty condition,
meaning that resizing columns is now always available, even if the
table is empty.
Task 3621490
closesodoo/odoo#146622
X-original-commit: 8fbdbb59eb3f37fad1fb75f4ff363f7fa17e6d27
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit fixes 3 issues with the domain in field tooltips, in
debug mode.
1) it only displayed the domain defined on the field in the model,
not the domain set in attrs in the view, if any.
2) when the domain was the empty array, `domain: ` was displayed.
3) unset values should not appear in the tooltip (invisible,
column_invisible, required, readonly).
opw 3455119
closesodoo/odoo#146563
X-original-commit: 8c4ff1fac9eb003c23770bf74f9d7ffe062f6ce7
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when the user tried to quick create a record in
a grouped kanban view (by clicking on the "+" icon of a column, for
instance), and then clicked on the "Edit" button of the quick
create, if the name_create rpc failed, the webclient switched to
the form view and an error was displayed.
The displayed error was about a destroyed component trying to do an
rpc, namely the kanban controller. This is because it does 2 things
when the name_create failed: it opened the form view in a dialog
and it also switched to the form view. The latter was unwanted:
in case of errors, we don't want to switch to the form view but
rather to quick create from a dialog.
The error was actually caused by a small mistake: we use the
record variable to determine if the quick create succeeded and if
we can switch to the quick created record. However, that same
variable was already set before, for another purpose.
OPW 3620671
closesodoo/odoo#146141
X-original-commit: 01bc79051b22f41eff20d860327ed0e41b572cd4
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When a tour fails, the tour system is supposed to log the failing
step (with the 3 previous/next steps). Before this commit, this
didn't work, and the first 3 steps were always logged, no matter
which step failed.
This didn't work because to determine the failing step, we try to
find the step from the list of steps, with reference matching
(steps are objects).
However, since [1], steps are obtained from a getter which calls
the steps function of the tour, so they always get a new version
of the steps.
This commit fixes the issue by memoizing the steps, such that the
function is called only once, and we keep the same references to
the step objects.
Note that this could be reworked in master to make it more robust
(e.g. finding steps based on ids).
[1] https://github.com/odoo/odoo/commit/81be42d8f9421e796087325c99aa4289d3912352closesodoo/odoo#145385
X-original-commit: 16ffd4d0bcb705c86fedd8dc7e6dd749c35eb5bc
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since the milk redesign, and the move of the "Add to my dashboard"
action from the search view to the CogMenu (next to breadcrumbs),
the action was available in all views, especially in form views,
which isn't what we want. Adding a form view to the dashboard
results in an empty form view (in creation) being displayed in the
dashboard.
Before milk, the form view naturally didn't allow to add to
dashboard as it has no search view.
This commit checks the view type to determine if the action must
be available or not.
Task 3552870
closesodoo/odoo#145534
X-original-commit: d01c75938948bd0e365d7ca1e4f518ce5b563f5c
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Before this commit, a studio qunit test ("edit/delete menus")
sometimes failed on runbot, because it tried to click on a button
in a modal footer, but it found 3 of them, because another dialog
which was expected to be closed at that moment, was still opened.
There was no guarantee for the dialog to be closed because of the
way browser.fetch was mocked. The fetching part was ok, but the
function returned a Response object, whose `json` method is async
(setTimeout-like async, i.e. "real" ticks).
This commit mocks some functions of the returned Response instance
to ensure that, by calling nextTick after a click or whatever, the
fetch operation has been done, the body has been decoded, potential
renderings are finished and the DOM has been patched.
Runbot error 23054
closesodoo/odoo#143980
X-original-commit: 66ef3ae730a233dc510425e0a5baca2973de493e
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, error message like "Uncaught Promise" were
translated. However, it may happen that the error is created (and
thrown) before the translation service is ready, i.e. before the
translations are loaded. Indeed, the error service is started first
and starts listening on errors that might be raised. If a module
throws an error (e.g. rejects a promise) before the localization
service is started, the error service being already set up, it
catches it and instantiates the appropriate Error. Doing so, a
"translation error" is thrown as translations aren't ready yet.
Translating those messages makes little sense anyway, as they
target developpers and they can't be found in the code if they
are translated. This commit thus stop translating them.
Issue found while investigating on opw 3602193
closesodoo/odoo#143551
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
PR [1] removed the legacy error handler that swallowed promise
rejection errors with anything else than an error (namely, the
"legacyRejectPromiseHandler"). As a consequence, promise rejections
done as "control flow" now lead to error dialogs being displayed.
In particular, it happened on the website (with website_event_track
installed), if the browser doesn't support service workers.
This commit simply leaves the promise pending if the feature is
unavailable.
[1] https://github.com/odoo/odoo/pull/137702closesodoo/odoo#143516
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Before this commit, the modified test sometimes failed on runbot
because it couldn't click on "Create and edit..." in the many2one
dropdown. Here's what happened:
1) call editInput to write something in the many2one input
2) call selectDropdownItem to select "Create and edit..."
This was done without mocking setTimeout.
The problem is that editInput triggers the opening of the dropdown,
but as setTimeout wasn't mocked, that opening was delayed. Then,
selectDropdownItem first clicked on the input to open the dropdown,
and then clicked on the requested item. It might happen that the
click on the input actually closed the dropdown instead of opening
it, if it had been already opened via editInput. In that case, the
test failed because it couldn't click later on on "Create and edit".
This commit also improves the test utils to better log what really
happens: in this case, the dropdown isn't open at all, so we
detect that specific issue and log it with a proper message (which
is different than "the dropdown is open, but I can find the item
you're looking found).
Runbot issue 28207
closesodoo/odoo#143044
X-original-commit: 220d4325866330235ceccd61b8d1d00d8c919ba8
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, some tests of the SwitchCompanyMenu sometimes
failed:
- "companies can be logged in even if some toggled within delay"
- "can toggle multiple companies at once"
They failed because the debounce delay between the first click to
toggle a company and the moment the company service is notified to
actually select the companies was sometimes too short for the 2 or
3 clicks on the menu to toggle companies to occur, as those clicks
are separated by nextTick(), i.e. a mix of calls to setTimeout and
requestAnimationFrame.
In tests, we patch the debounce delay to 0 by default, and before
this commit we set a delay of 50 in the two faulty tests. This
commit fixes the issue by keeping the real delay in those tests (1s),
as they aim at testing the fact that the user has the time to do
multiple clicks before committing the company changes and reloading.
Fixes runbot error 29962
closesodoo/odoo#142904
X-original-commit: 2ec65691ac11cb4216d873dcab77a84e2c35ba17
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The test 'buttons with attr "special" in dialog close the dialog'
sometimes fail on runbot because it can't click on 'Create and edit...'
inside the many2one dropdown. Before this commit, the test edited
the many2one as follows:
1) edit input to write a new value (with editInput)
2) click on the input to open the dropdown
3) click on 'Create and edit...' in the input
But calling editInput opens the dropdown (even though the opening
is a bit debounced, which is why it only failed sometimes). So it
might happens, in rare cases, that the dropdown is already opened
when we click in the input (step 2), which closes it and makes
step 3 fail.
This commit changes the test to do something similar as what we do
in many2one_tests.js: we patch setTimeout to execute the callback
directly, and thus remove the opening delay. We call editInput
which triggers the opening of the dropdown, and we click inside
the dropdown.
Runbot issue 24739
closesodoo/odoo#142863
X-original-commit: 4a011149cba968585d5e74ee4f4fff7212c729e3
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The cog menu in the control panel (displayed next to breadcrumbs)
has a shortcut, so it is available in the command palette. However,
as is has no text content and no title/tooltip, the command palette
displays "No description provided". This commit adds a tooltip on
the icon, which is thus also displayed in the command palette.
closesodoo/odoo#141913
X-original-commit: 991e2e75d20bbb56b080c97e6b5ca96b746de3f3
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Before this commit, a grouped kanban view with create="0" on the
root node would still allow to quick create record in columns (i.e.
the "+" icon would still be displayed). However, clicking on it
would most likely raise an AccessError as the user isn't allowed to
create records.
This commit restores the pre 16.0 behavior, which is to disallow
quick creation if the user can't create.
Task 3559638
closesodoo/odoo#141631
X-original-commit: 775475aaed6ea88f54a6530b81f35f3114431716
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
The MacroEngine has a stop function that allows to completely
disable it. Before this commit, it correctly disconnected the
"main" mutation observer, but it didn't disconnect the mutation
observer for iframes.
In web_tour tests, we mock the MacroEngine to stop it at the end
of tests, but this didn't stop the iframe mutation observer.
This had an highly undesirable side-effect in tests: the qunit
suite stopped during mass_mailing tests, because the iframe
mutation observer detected a change which produced the log of
"test successful", which ended the whole suite. Some tests were
thus never run anymore (fortunately, we're only talking about a
few qunit modules).
closesodoo/odoo#141143
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
In views with a searchbar, we want the filters to be displayed
directly when they are activated, without waiting for the view to
be reloaded. This is to provide a direct feedback to the user.
Before this commit, this didn't work in grouped kanban view with
progressbar. The regression has been introduced by [1] which moves
the progressbar logic out of the model. With [1], the rendering of
the KanbanController waits for the progressbar data to be loaded
in onWillUpdateProps, thus delaying the rendering coming from the
WithSearch when a filter is toggled.
This commit applies the same logic as for the model: we do not wait
for the loading promise in onWillUpdateProps. That way, the
rendering coming from WithSearch is synchronous, but a reload is
initiated and another rendering will be scheduled by the Controller
itself when the data will be loaded.
This commit also adds a test for the model case, as it appears that
this wasn't tested.
[1] 58ca40b032closesodoo/odoo#139967
X-original-commit: 47cf6e326f5a795984bac2138b169503c3dd099c
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
The messaging service starts synchronously and exposes a promise
isReady that is resolved when the call to init_messaging is done.
This is good as this call thus doesn't slow down the services
startup and thus the webclient mount.
Unfortunately, the ChatWindowContainer, which is a main component,
i.e. a child of the WebClient, waits for that promise in its
onWillStart. As a consequence, the webclient can't be mounted
until the rpc returns, which can take a while (in odoo.com, this
rpc lasts ~500ms).
The chat windows being "peripherical components", there's no reason
to block the whole application for them. Instead, the webclient
can be mounted, and when they are ready, the chat windows can be
rendered. This is what this commit does.
Back-port of https://github.com/odoo/odoo/pull/139750/closesodoo/odoo#140056
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
...when voip addon is installed.
We want to avoid predictable rpcs that are systematically done at
webclient startup. In particular, the voip service needs to know if
the user has group "base.group_user", which produces a rpc when
the service is started.
To avoid this, this commit adds the information in the page
directly. As this information is also useful at other places
(even though it's not at startup), we directly add it to the
groupCache of the user service (and we do the same for the
"base.group_system" group, which we also receive in the page).
closesodoo/odoo#139477
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The attendance systray item needs data to determine whether or not
it should be displayed, and what to display. Before this commit, it
fetched it in the standard way, in onWillStart, and returned the
fetch promise.
However, for a systray item, it's better not to wait for the
promise, such that the webclient doesn't wait for it to be mounted.
In the case of this item, it is simply not displayed until data is
fetched, and when it is displayed, it's the right most item so it
doesn't produce any flickering.
This allows to save several ms on specific screens (e.g. home menu).
Part-of: odoo/odoo#139477
Before this commit, the CodeEditor component called the `onChange`
props function each time the ace library fired the `change` event.
This in particular happens the value of the editor is set
programmatically by a update of the `value` props. Worse, in that
case, the event is fired twice: once with the empty string, and
one with the new real value. This isn't what we want for the
CodeEditor API. We only want to notify the parent of updates done
by the user in the UI. This commit thus filters out the noisy
`change` events fired by ace.
This fixed an issue with the ResourceEditor of the website: select
a scss or js custom resource, click on Reset: the resource is
marked as dirty, because `onChange` is called when the CodeEditor
is updated with the new value.
closesodoo/odoo#139154
Related: odoo/enterprise#49286
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, there was a special kind of dropdown item
defined in the search/ folder, named SearchDropdownItem, which was
basically a DropdownItem but with role "menuitemcheckbox" instead
of "menuitem". It allowed to displayed a check icon in front of
values to indicate that they are selected. It is used especially
in the search menu, to indicated which filters/groupbys/favorites
are active.
This specific item is used in other context that search (e.g. pivot).
A similar usecase has also been introduced in website, in the
ResourceEditor (the wowl version of the AceEditor).
This commit thus moves the component to web/core/dropdown and
renames it into CheckboxItem.
Part-of: odoo/odoo#139154
This commit removes the last low level legacy stuff (e.g. Widget,
mixins...) from the backend bundle, and from the webclient bundles
of mrp_subcontracting and project. They are no longer used in the
backend. There're still necessary for the frontend and for the
web_editor though, so we had to manually add them in the lazy
loaded bundle of the editor. Hopefully, the last widgets and
dialogs will be converted soon, and we'll finally get rid of all
those legacy files.
Part-of: odoo/odoo#139154
The select2 library is only used in the frontend, now that the last
backend usecase (AceEditor) has been removed. This commit thus
removes the select2 library from the backend assets.
Part-of: odoo/odoo#139154
Now that the last Component using that helper have been fully
converted to Owl (AceEditorWrapper -> ResourceEditor), we can
remove it.
Part of task~3439226
Part-of: odoo/odoo#139154
This commit refactors the website AceEditor to owl. The wrapper
around the lib was defined in web_editor, and extended in website,
where it was used (single usecase). This commit thus introduces an
owl Component to replace it, directly in website, and specialized
to the website usecase.
This thus allows to remove the legacy implementation.
This also removes the last usecase of Widget and select2 library
in the backend bundle, which will allow to trim it down.
Part of task~3439226
Part-of: odoo/odoo#139154
By default, the SelectMenu component alphabetically sorts the
choices. Before this commit, this wasn't avoidable. As there's now
a usecase of SelectMenu where we want to enforce a specific order
on the choices (the website AceEditor), this commit introduces a
props `autoSort`, which is `true` by default, but which allows to
disable the sort.
Part-of: odoo/odoo#139154
This props allows to specify the initial width of the panel, whereas
before the initial width was the minimal width, i.e. the user could
only expand the panel, not shrink it.
Part-of: odoo/odoo#139154
This component has been introduced in web_studio. We have now a
similar usecase in website, for the AceEditor component. We thus
move the component definition to web.
Part-of: odoo/odoo#139154
The `beforeEditorActive` props is a function, not a boolean. So
before this commit, there was a crash in debug mode when the
WysiwygAdapter was instantiated.
Part-of: odoo/odoo#139154
Since [1], invisible attributes on views are no longer evaluated
server-side. In search views, field and filter nodes can have an
invisible attribute which can be static ("1" or "True") or dynamic,
depending on the context (e.g. "context.get('something')"). Before
[1], in the arch received by the client, the value of the invisible
attribute was always static as "context.get(...)" expressions were
evaluated server-side. This is no longer the case, and we thus have
to evaluate the expression client side.
Before this commit, the invisible attributes in search archs were
simply ignored if they weren't static. This could be observed for
instance in Project > open a project: the "Private tasks" filter
was available even though it is dynamically invisible, and shouldn't
be there.
This commit ensures the invisible attributes are always taken into
account and evaluated.
[1] odoo/odoo@ba1a5509faclosesodoo/odoo#138590
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
The jSignature lib is only used by the NameAndSignature component,
which is not accessible on a many screens. This commit thus
removes the lib and its extension from the bundles, and makes the
NameAndSignature component load it on demand.
Part of task~3439226
closesodoo/odoo#138054
Related: odoo/enterprise#48633
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
This commit converts the SignatureForm widget into a Component.
This allows to remove the last usage of the legacy NameAndSignature
widget, which we thus remove.
Part of task~3439226
Part-of: odoo/odoo#138054
This function must be used to safely redirect to another url. It
ensures that we stay on the same origin, and thus that the url is
safe.
Part-of: odoo/odoo#138054
The tempusdominus library has been removed by [1]. This commit
removes scss customizations of the library that have been forgotten.
[1] 910897fc97closesodoo/odoo#138129
Related: odoo/enterprise#48657
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
This service was used to redirect legacy service requests to the
wowl service infrastructure. It has been incrementally simplified
with the codebase getting converted. It now only allows to redirect
calls to the effect service, which doesn't seem useful anymore.
This commit thus removes it.
Part of task~3439226
closesodoo/odoo#138120
Related: odoo/enterprise#48654
Signed-off-by: Géry Debongnie <ged@odoo.com>
This commit aims to simplify the evaluation context used to
evaluate expressions used in views (invisible, required, readonly,
domain and context attributes). For now, the evaluation context is
typically the current record (there's a key for each field in the
view). In addition to that, there're static keys (that may conflict
with field names): uid, allowed_company_ids, current_company_id,
active_id, active_ids and active_model.
The motivation of this commit is at some point to get rid of the
3 active_* keys, because they are misleading and basically useless.
The notion of active_* exists, but it is something else: when you
are in a form view (let's say the form of a partner) and you open
its opportunities (by clicking on the stat button), the list view
of opportunies shows up and in the context, there're 3 keys
active_*, referring to the record from which we came. One can
easily access those information with context.get("active_*"), in
python or in view archs.
However, almost all `active_id` found in archs were actually used
to refer to the id of the current record. Indeed, for now, in the
evaluation context of a record, the value of the `active_id` key is
always the id of the record. So this commit adapts them to
directly use `id` instead. There was no use of active_ids, and
a single use of active_model which was removed (active_model is
the res_model of the view, so it isn't really necessary).
This commit doesn't drop the support of those keys, it deprecates
them. They will be removed for v18. A warning will be displayed if
they are used.
closesodoo/odoo#136665
Related: odoo/enterprise#47917
Signed-off-by: Raphael Collet <rco@odoo.com>
The motivation of this commit was to remove the override of owl
that disables the validateTarget check, which we believed was
necessary for the renderToString function.
Fun fact: renderToString doesn't seem to need the override, as
validateTarget is only called when mounting an app and when
completing a fiber, which renderToString doesn't do. It was instead
probably necessary for the legacy compatibily layers that have now
been removed.
So this commit removes the validateTarget override.
This commit also simplifies the setup of the renderToString fn by
lazy creating the app itself, instead of requiring the application
setup to set the main app as renderToString app (e.g. main.js in
web).
Part of task~3508223
closesodoo/odoo#137807
Related: odoo/enterprise#48514
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Since commit [1], there was a crash when the user clicked on the
"Get View" item in the debug menu (in any views). This was because
the arch now received by the views in props is an XmlDocument,
whereas before it was a string.
[1] odoo/odoo@cc3a3a328dclosesodoo/odoo#137668
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*board,mail,project
This commit aims to simplify the XMLParser logic and the way archs
are manipulated in views, motivated by [1] where we had to
modify the arch in View to insert access right information.
First, the xml utils have been reworked. The XMLParser class has
been removed. The xml utils module already exported a parseXML and
a serializeXML functions, this commit adds visitXML, s.t. the whole
XMLParser feature is fully replaced by the 3 functions.
Second, concrete views now receive the arch in props as an
XMLDocument, as the arch is parsed once for all in View. With this,
we were able to remove serializing/parsing back and forth at several
places, where we needed to extract information for sub-parts of an
arch individually (e.g. View, x2many subviews, list view groupby).
Third, even though this change has been driven by the one above and
wasn't initally wanted, the view compiler cache and API have been
simplified. The cache is now flat, there's an entry in the cache for
each template that has been compiled. Moreover, the useViewCompiler
hook no longer takes the cache key in params, as it can directly
compute it itself (the key being the outerHTML of the template).
[1] odoo/odoo#135145closesodoo/odoo#136376
Related: odoo/enterprise#47808
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
The initial motivation of this commit was to ensure that the qunit
test suite doesn't stop when an error is thrown in a test, which
could happen if the error was thrown "sufficiently close to the
end of the test". Indeed, the "unhandledrejection" event being
async, it was sometimes triggered after the end of the test, when
the service registry was already reset, and the check of the
presence of the error service was wrong, so the error event wasn't
default prevented (e.g. await makeView(...) and the view crashes
at render time).
This led us to rework in more depth the way we deal with errors in
tests. Here are a few behaviors we want (probably not exhaustive):
- an error in a test must never end the suite (executed in py)
- an error in a test must always make the test fail, except if the
error is expected in the scenario, which one must be able to
state
- a test must always wait for potential unhandledrejection events
to be triggered before ending.
- ideally, we don't want to have to deal with unhandledrejection
in each test throwing an error (in order to prevent the suite to
stop)
To achieve this, we come with the following solution. We introduce
a new assertion method, "expectToThrow" which allows to state that
during the test, we expect errors to be thrown. It takes a list of
error messages that will be compared at the end of the test with
the errors that have been thrown during the test. If they differ,
a qunit failure is pushed and the test fails. If an error occurs
in a test and "expectToThrow" hasn't been called, qunit is directly
informed of the error and a failing assertion is done, make the
test fail as well.
If the error service isn't available in the test environment, we
apply the logic above when an "error" or and "unhandledrejection"
event is thrown. If the error service is available, we wrap the
default handler (typically the one that handles everything that
hasn't been handled by specific handlers, like tracebacks) and if
we get to it, we apply the logic above. This means that one must
call "expectToThrow" if
- the error service isn't deployed, or
- the thrown error is handled by the default handler, because
it is something like a traceback (errors like UserError,
ValidationError are graciously handled by the RPCErrorHandler)
and thus never reach the default handler.
In all cases, we prevent default the event such that the error
doesn't make the python test end.
Finally, to ensure that "undhandledrejection" events are handled
before the test ends, we wait, in the qunit lib, for a setTimeout
before ending the test, which ensures that all such events have
been dispatched.
closesodoo/odoo#137120
Related: odoo/enterprise#48211
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
This commit removes a loophole in the evalContext used in form,
list and kanban views to evaluate python expressions (modifiers,
domains and contexts). Before this commit, the evalContext was a
mix of different things:
- keys of the current context (which also contained keys from the
user context);
- a key for each field in the view (allowing to use field values);
- a "parent" key in the case of x2many records (allowing to go up
to the parent record values).
- "active_id", "active_ids", "active_model", "current_company_id".
All those keys were mixed in the evalContext, and they could
obviously conflict (e.g. if there was in the context a key which
was also the name of a field).
Even though the evalContext didn't contain an explicit "context"
key, expressions like `context.get("x")` worked. This was because
the python evaluator automatically adds the whole evalContext as
value for the "context" key if this one doesn't exist. This allowed
people to also access field values with `context.get("fieldName")`
and thus bypassing the view validation, which ensures that
everything used in those expressions is either a py builtin
supported by pyjs, a field name which is in the view or some other
whitelisted keys ("uid", "allowed_company_ids"...). Fun fact:
people did it, in a form view that is used on two different models
(product.product and product.template).
With this commit, the context (and user context) keys are no longer
spread into the evalContext. Instead, a "context" key is added.
Two special user context keys can still be accessed directly though,
without doing `context.get("...")`: "uid" and "allowed_company_ids".
The reason why we keep them is simple: those were the two only keys
that could be used directly as they were whitelisted by the view
validation. The client also evaluates domains and contexts coming
from actions and from search view filters. In those cases, the
evalContext is simply the context, and those two keys are widely
used. So it's easier if we know that, e.g. "uid" can be always
directly accessed, whether we're in an action domain, in a search
view or in a form/list/kanban view.
To summarize, accessing a context key must always be done through
`context.get("...")` except for "uid" and "allowed_company_ids",
which can still be accessed directly. This doesn't change from
before. What changes is that a record field can no longer be
accessed with `context.get("...")` (which kind of allowed to bypass
the view validation).
closesodoo/odoo#135782
Related: odoo/enterprise#47522
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Commit [1] changed the separator of cids in the url to make it
better looking, by using a character that doesn't need to be
encoded (namely, "-" instead of ","). However, by doing so, urls
still using the former separator couldn't be correctly parsed
anymore. This commit adds a small backward compatibility layer,
s.t. links in emails for instance keep working as before.
[1] abae4d4a5cclosesodoo/odoo#136247
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Before this commit, cids in the url (in the hash part) were
separated by a comma, which was encoded by encodeURIComponent as
it is not considered as a safe character, resulting into "%2C"
appearing in the url in between company ids. This was kind of ugly
and made the url a bit hard to read.
This commit uses "-" as separator for cids, which is a safe
characters [1] to use in the url and which is thus left untouched by
encodeURIComponent.
AL request.
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent#descriptionclosesodoo/odoo#136104
Related: odoo/enterprise#47723
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
When it is unset, the domain of an action can be either false or
the empty string, which in both cases means []. Before this commit,
we didn't process the domain in thoses cases (i.e. we kept the
false or empty string value). However, having an empty string as
domain could cause issues if it is manipulated by Domain/pyutils.
In particular, in stock.picking, clicking on "Insert menu in
spreadsheet" crashed before this commit.
To prevent those issues from happening, this commit sanitizes the
domain of the action at the first entry point, such that it's
always an array (the empty array in our case).
This commit comes with a test in enterprise, which reproduces the
scenario given above, as we couldn't find framework and blackbox
scenario to highlight it.
closesodoo/odoo#135738
X-original-commit: a7c32029aaf595b9b3ae13b9c425e384ab4c8305
Related: odoo/enterprise#47500
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
We must wait for an additional tick to be sure that the error
dialog is displayed, because the "unhandledrejection" event is
triggered asynchronously.
Runbot issue-24690
Runbot issue-24691
Runbot issue-24744
Runbot issue-24733
Runbot issue-24742
closesodoo/odoo#135500
X-original-commit: e341f592e2a8ebc3c2e479566425df89a29bf2c7
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
This commit reworks a little bit the backend assets to remove a
bundle and thus save a call at webclient startup. The bundle
"assets_backend_prod_only" existed only to allow to add files in
production, but not in the tests (typically, the file that spawns
the webclient).
This commit introduces a new bundle "web.assets_web" that contains
"assets_backend" and the few files that we only want in production.
In the /web page, we now load "assets_web" instead of
"assets_backend" and "assets_backend_prod_only". In the /web/tests
page, we keep loading "assets_backend", which is now directly
included into "web.tests_assets".
For the sake of consistency, this commit also renames the dark
mode bundle "dark_mode_assets_backend" into "assets_web_dark".
closesodoo/odoo#135204
Related: odoo/enterprise#47316
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Have a form view with a view button. Make some changes in the form
s.t. the create/write rpc will return an error. Before this commit,
the "oh snap" dialog was displayed, providing 2 choices to the
user: stay here (basically, close the error dialog and do nothing
else) or discard (discard changes, and continue the flow). In this
case, the flow is to do the "call_button" as we clicked on a view
button. It means that if the user clicked on discard, we still
call the method/action, even though the record was invalid (and
maybe not even existing if it was a new record). This can cause
other issues afterwards.
The "oh snap" dialog was designed for navigation flows (e.g. menu,
breadcrumbs...), when the user tries to leave the form view. It
doesn't fit very well with flows involving the current record that
couldn't been saved.
This commit thus prevents the "oh snap" dialog from being displayed
if the save preceeding a call_button fails. The error returned by
the save is simply displayed in a basic dialog that can only be
closed.
opw~3395109
closesodoo/odoo#135050
X-original-commit: 50b2a24f22cb470bcc1a9befe677cf794211d7b2
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Have a form view with an x2many list with handle field and a
default_order containing id (e.g. sequence,id), but id not being
defined in the list view. Before this commit, on an existing
record, it was impossible to resequence records of the x2many.
The reason is that after resequencing (drag&drop), the model tried
to sort the records, and since the "id" field wasn't in the view,
but was in the default_order, records were reloaded and the changes
(the new sequences) were lost.
The "id" case is special because the field doesn't need to be set
in the view, it is always known by the model. However, it is only
available in record.data if it is defined in the view. This commit
treats the "id" field individually in the sort algorithm.
Bug reported in the new relational model feedback pad.
closesodoo/odoo#135045
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Before this commit, if an onchange returned an error, the faulty
value was kept in the UI and there was no feedback given to the
user besides the error being displayed in a dialog. However, the
former value was still the one stored in the model, which produced
a discrepancy between model and UI.
This commit tackles the issue by marking the field as invalid in
this case (like when you input letters inside a numeric field).
That way, the value in the model is still different from the one
in the UI, but the field is stored in the list of invalid fields,
it is displayed in red, and the view can't be saved (it can be
discarded though).
Task~3498849 (master version, which differs from 16.0, see [1])
[1] odoo/odoo#134792closesodoo/odoo#135017
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
*account,web_editor,website,website_sale,website_slides
This commit removes all legacy utils except Markup, which will be
removed in another PR. A lot of those utils were no longer used and
thus have just been removed. Those that were still used either
already existed in the wowl codebase, so usecases have been adapted
to use the new version instead. A few have been re-implemented (or
moved basically) to the wowl codebase (e.g. isEmail and humanSize).
Part of task~3439226
closesodoo/odoo#134620
Related: odoo/enterprise#47044
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Be in an ungrouped list or kanban view. The "limit" number of
records is displayed (by default 80). Apply a group by. The same
limit is applied for the number of groups, whereas there's a
specific parameter ("groups_limit") for the number of groups to
fetch and display. The same problem occurs the other way around
(going from grouped to ungrouped), as in this case the groups_limit
is kept when the view is no longer grouped.
This commit fixes the issue by forcing a reset of the limit when
we go from grouped to ungrouped and from ungrouped to grouped.
We also add a test to ensure that the "groups_limit" is taken into
account even when there're multiple groupbys, which wasn't the
case in previous versions, but which is working as expected with
the new model.
closesodoo/odoo#134253
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Have a form view with a one2many field (e.g. displayed as a list)
containing itself an x2many field (e.g. many2many_tags), with a
dynamic context depending on the parent record (see the test for
a specific situation).
Before this commit, the dynamic context on the inner x2many wasn't
correctly evaluated, because when we evaluated it, the parent
evalContext hadn't been computed yet (they were computed bottom-up)
when the datapoints were created.
With this commit, we wait for all datapoints and evalContext to be
properly set up before evaluating the static list dynamic contexts.
closesodoo/odoo#134160
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
This utils also exists in /core/utils/strings and the legacy
version was no longer used. Also remove the diacritics map which
is heavy.
closesodoo/odoo#133896
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
This function became useless at some point, after the views and
actions have been all converted to owl.
closesodoo/odoo#133699
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
*project,spreadsheet
The unity version of web_search_read will soon replace the older
one, so this commit prepares the work by adapting the remaining
calls to web_search_read s.t. they call unity_web_search_read
instead.
Part-of: odoo/odoo#133617
Before this commit, many2one values were still returned as pairs
of id and display_name by unity read, whereas they should be
objects with keys id and display_name.
Part-of: odoo/odoo#133617
This component was necessary during the transition phase, when all
actions weren't converted to owl yet. Now, they are, so we can get
rid of this small compatibility layer.
Part of task~3439226
closesodoo/odoo#133489
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Before this commit, in an editable list view grouped by a many2many
field, it crashed when the user tried to add a new record, because
the default value set in the context was wrong (it was an id, but
it must be a list of ids, containing a single id, the one of the
group where we want to create a record).
As this is a master fix, this commit takes the shot to refactor a
bit the way we extract information from groups returned by
webReadGroup, s.t. everything is now computed directly (before,
the serverValue was computed in the datapoint, which didn't allow
us to use it in the context). We can also get rid of the context
handling in kanban (where the bug wasn't present), as it is now
correctly generated in the model for everyone.
closesodoo/odoo#133420
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before chrome 116, programmatic clicks on disabled buttons weren't
actually fired. With chrome 116, they are. As a consequence, some
tests fails on chrome 116 because they click (on purpose) on
disabled button to highlight the fact that nothing happens.
This commit improves the click helper to make it throw an error
when the target is disabled. It also adapts the tests that were
clicking on disabled button, in general to simply assert that the
button is disabled instead.
closesodoo/odoo#133196
Related: odoo/enterprise#46398
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
In a kanban (or list actually) view grouped by a many2one field,
the "false" group is folded by default. Before this commit, if the
user opened it and then reloaded the view (e.g. by applying a
filter in the search view), the group was folded again. With this
commit, the group remains open if the user manually opened it.
closesodoo/odoo#133305
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Before this commit, when a list view was grouped by more than 1
field, the view was considered empty, and the no content helper
was displayed. For instance, go to Contacts and group by Company
and Country.
Part-of: odoo/odoo#133305
Have a grouped kanban view with sample data and existing groups,
and the quick create feature enabled (e.g. CRM pipeline). Click on
"New", or on the "+" of a column. Before this commit, all columns
displayed the "Load More" button, with the count of sample records
that had been generated for that column, even though the columns
were empty. After this commit, no "Load more" button is displayed,
as expected.
closesodoo/odoo#132802
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Have an editable list view with sample data (sample="1" and no
record). Before this commit, there was a flickering when the user
clicked on "New" to add a record. Indeed, the list was first
re-rendered without the sample mode (i.e. without the opacity style
and no content helper), but still with the sample records. With
this commit, we wait for the reload to be done before leaving the
sample mode, s.t. when the list is re-rendered, we don't have
sample records anymore.
Part-of: odoo/odoo#132802
There's a single usecase left for this helper, which is in website.
This commit directly moves the function definition in the file
using it.
Part of task~3439226
closesodoo/odoo#130843
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
This commit moves the smooth scroll on drag helper from web to
web_editor, which allows us to move it from frontend and common
assets to web_editor.assets_legacy_wysiwyg which is only loaded
in the website editor, the only place where it is used.
Note that it uses legacy Class and mixins, so it still needs to be
converted to the modern codebase, alongside editor snippets.
Part of task~3439226
closesodoo/odoo#130813
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Aaron Bohy