Before this commit, we propagate all the slots to the SettingsPage. This
could raise an issue if the default slot (propagated) has a content, for
more information see: https://github.com/odoo/owl/issues/1256
Now, to avoid this, we only propagate the slots that are used on the
SettingsPage component, ie: NoContentHelper.
closesodoo/odoo#100362
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
From a (e.g.) list view, click on "Create". In the form view, fill
in some fields, but leave a required field empty. Click on the
breadcrumbs to come back to the list. Before this commit, a
notification was displayed (because some required fields are
unset), but we left the form to come back to the list anyway.
The desired behavior is to stay on the form view, and display a
notification indicating that some fields are invalid.
In legacy views, we rejected promises to indicate that we couldn't
leave. This is a pattern we tried not to use anymore in new code.
Instead, we return a promise (if the method is async obviously)
which resolves to a boolean value, indicating if it works or not.
As a consequence, the action service wasn't properly dealing with
new views, as the promises they return always resolve.
This commit fixes the issue by adapting the code in the action
service.
Part-of: odoo/odoo#100050
Before this commit, we didn't apply the default favorite (if any),
when there was an active_id or active_ids in the context. This was
a mistake. Note that it only impacted owl views.
closesodoo/odoo#99989
X-original-commit: 1e13e6cd073e57b3744caefc4b8f3795c35a4c10
Signed-off-by: Aaron Bohy (aab) <aab@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>
Steps to reproduce:
- Go to settings
- Click on discard
-> the breadcrumbs contains twice the "Settings" entry.
This commit fixes the issue by restoring the legacy behavior in
the "Discard" button handler, that is, calling doActionButton with
the special="cancel" param. This had been changed by mistake during
the conversion of the settings form view.
To make the fix work, a slight changed has been done in the model
as well, as reloading a datapoint could lead to the creation of
a new datapoint (typically when it's a new record), so the handle
must be updated in this case.
closesodoo/odoo#99904
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Let's assume the following scenario:
- be on a list or kanban view with sample data
- click on "Create" (-> opens the form view)
- in the form view, there's a kanban x2many field
Before this commit, the no content helper was displayed in the
form view, whereas it obviously should not.
The issue occurred since [1], as this commit has the unwanted
since effect to set the property `useSampleModel` to true on the
form view model, which is used in the x2many kanban renderer to
determine whether or not to display the no content helper.
This commit forces that property to `false` on views that
explicitely ask to ignore sample data.
[1] 2600d1f2aeclosesodoo/odoo#99889
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Go to a (OWL) list view with sample data, click "Create" to open a (OWL)
form view and go back to the list view using the breacrumbs: the sample
data has disappeared.
This is due to the fact that the form view set useSampleModel=false in
the globalState when it is left while it does not use at all sample data
mode.
Here we make it simply pass the value that it received initially.
closesodoo/odoo#99587
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit converts the report code to the new framework.
Since the module stock still has code that extends the old
"ReportClientAction", the old report code is put inside this module.
It can be then naturally removed once the module is fully converted.
closesodoo/odoo#97390
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, if a text-muted on a setting (a description of the
setting) contains fields or HTML tags, the highlight generated wrong
texts.
Now, we highlight the text in an iterative way, taking care to only
highlight the text.
closesodoo/odoo#99205
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When searching a text of a hidden field (for example, "gate"), the
setting itself will not be shown, but the group title, and the app
Search Header will be shown.
This issue arise because, we use an if condition with all the label of
all the fields (hidden or not) in the group (or app) to decide if the
group title or the app header will be showed.
Now, we modify this to hide (d-none) the group title or the app header
if there is not a settings below them.
Part-of: odoo/odoo#99205
Previously, when a label in a form arch had an empty string attribute,
we would not render it at all as it seemed useless. In practice, some
existing form arch rely on empty labels being rendered for layout
reasons, and the corresponding views are now broken.
This commit fixes that by instead rendering an empty label, just as
legacy views used to.
Part-of: odoo/odoo#98711
In legacy, when you have a label with a string attribute that is empty,
that label is rendered as empty. In the new form view, when the string
attribute was empty we would fall back to the default label for that
field, which is incorrect.
This commit fixes that by not rendering labels that have an empty string
at all.
closesodoo/odoo#98237
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
There were 2 problems before this commit:
1. When switching view and coming back from the breadcrumbs: the
previous view props (such as the pager props) were lost;
2. When paging to the next record, switching view and coming back from
the breadcrumb, the view was reverted to the first selected record,
effectively ignoring the paging step.
This commit fixes both of these issues by keeping the controller's
props during a "restore" action, and by also updating the current
controller's props when using the pager.
closesodoo/odoo#97395
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Inside a res.config.settings form view have a label with a string on it placed
before the field it is linked to.
i.e.:
```
<label for="myField" string="myString" />
<field name="myField" />
````
Before this commit, the string was not taken into account to build the HTML label.
After this commit, it is.
closesodoo/odoo#98109
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
*: mail, web.
The pyEnv used during tests is based on the mock server to provide
server like api. This issue is that when creating multiple environments
during tests, a new mock server is created each time. This is not realistic
since in a real world scenario, multiple tabs would share a single server.
In order to make pyEnv work with multiple tabs tests (e.g. multiple env tests),
let's create a single mock server shared between js environment during a test.
task-2053917
Part-of: odoo/odoo#97975
Spawn a form view with a record and set its props "mode" to readonly.
Click on "Create".
Before this commit, the new record was in readonly mode.
This is never what we want, we always want a new record to open
in edit mode.
After this commit, the new record is in edit mode.
closesodoo/odoo#97451
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, the isVisible helper would most of the time work as
expected, except if an element has display: contents. In that case, it
has no bounding box, but it may still be visible if one of its child
is visible.
This is particularly important since we want to set the display property
of all field components to "contents".
Part-of: odoo/odoo#96865
The mock of sendone/many was relying on the bus_service. Since owl.Component.env
is changing during tests setup, the bus_service was not always defined. In order
to make this more reliable, the longpolling/poll route is now mocked, returning a
promise that can be resolved by the sendone/many methods.
closesodoo/odoo#97298
Related: odoo/enterprise#30059
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
On the res.config.settings form view, click on button that will do an action
e.g. defined as some flavor of `<button type="object" name="myMethod" />`
Before this commit, this did not work as we never fully created the res.config.settings record in python
hence, when executing myMethod on the model res.config.settings, the ID was unset, pointing to no record.
After this commit, we "create" in python the transient res.config.settings record before doing anything.
closesodoo/odoo#97428
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Have an editable list view, displaying a many2many tags field. The m2m field
has a context, mentioning `active_id`. (`context="{'default_field': active_id}"`)
"basic context keys" is to be understood as the usual suspects: active_id, active_ids, current_company_id, active_model
Type something in the m2m input, and selet create and edit, in order to create a new record in a dialog form view.
Before this commit, there was a crash because active_id was not present in the evaluation context.
After this commit, the new record opens in its form view, with the right value for the field that must have a default.
closesodoo/odoo#96910
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
In community, some actions contain view types that only exist in
enterprise (e.g. in MRP, Work Orders, there's a gantt view). Before
this commit, it crashed because the view doesn't exist. This commit
simply ignores those unknown views.
closesodoo/odoo#97369
Signed-off-by: Samuel Degueldre <sad@odoo.com>
In the BS5 migration, the legacy `checkbox` and `boolean_toggle` widget
were adapted but not the OWL Component.
Also, we have tweaked the old widget and the component to have better
positioning and margins.
Note:
the CSS for the print is already done in BS5
```css
@media print {
.form-check-input {
color-adjust: exact;
}
}
```
Also we change `offsetWidth` by `getBoundingClientRect().width` in
`list_renderer` to avoid inaccurate rounding in columns width's
calculation.
Lastly a `.o-checkbox` class is added to the Checkbox component for a
more universal and context independent targetting.
closesodoo/odoo#96185
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
In the context of an action, one can specify the "dialog_size" key
(only useful for actions in target="new"), which impacts the size
of the dialog. Before this commit, the corresponding bootstrap
classname wasn't applied. As a result, the dialog size was always
"large". This commit fixes that issue.
closesodoo/odoo#97085
Signed-off-by: Géry Debongnie <ged@odoo.com>
Have a legacy list view, click on a record to open it in a new (WOWL) form view
Before this commit, the pager was wrong, as we never passed the list's current resIds
to the form.
After this commit, the pager of the wowl form view is correct.
closesodoo/odoo#96123
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
*hr_timesheet,point_of_sale,website
This commit moves the settings form view implementation from base
to web, and converts it to owl.
The setting's search has been improved to take into account more
elements. Before, it was possible to only search on the field's
labels. Now, we can also search on the field's description, and
the titles of setting's group.
Part-of: odoo/odoo#78221
Co-authored-by: Samuel Degueldre <sad@odoo.com>
*: bus, calendar, iap_mail, im_livechat, project, web.
In order to ease the PR introducing the websockets in Odoo, the bus service
has to be updated to be a wowl service. This PR takes care of it.
task-2053917
closesodoo/odoo#95824
Related: odoo/enterprise#29361
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
- modal 'show' option doesn't exist anymore
-> We need to call .show()
- by default, show is not the default
-> we need to call .show() explicitly.
- generic close button for dismissing content like modals and alerts.
- BS5 modals needs `modal-dialog` class to work
- normally we need also to add `modal-content` class but as the original
XML don't have this nested level of div we don't use it, but instead
we add `pointer-events: auto` for all children `DIV` of `modal-dialog`
-> See DocumentViewer
Task ID: 2766483
Part-of: odoo/odoo#95450
* data('bs.popover') is not a jQuery data anymore
-> fetch data from the instance instead.
* use the new class name 'popover-arrow' instead of 'arrow'
* website_forum: offset is not a number anymore
-> Convert to string instead.
* BS5 event listener: 'focus' -> 'focusin'
* use `mouseover` event to show and `mouseout` to hide.
* disable at some point the animation to avoid remaining listener
in the DOM.
Ref:
https://getbootstrap.com/docs/5.1/migration/#popovers
Task ID: 2766483
Part-of: odoo/odoo#95450
Before this commit, the context parameter "form_view_initial_mode" was
ignored by the form views, so that the form view would not be always
initialized in the appropriate mode.
closesodoo/odoo#95413
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the loading indicator is shown immediately after
each network request. But this is distracting, and may cause an
impression of slowness, since it shows that the web client is working.
However, the feedback is very useful.
So, it has been decided that we would only display the loading indicater
after a delay of 250ms. All requests shorter than that duration will
just not show anything.
closesodoo/odoo#95037
Task: 2900450
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit introduces the new kanban, list and form views written
in owl. Even though it contains the implementation of those 3 views,
only the kanban view is activated for now (the list and form views
aren't 100% ready yet, so they aren't added to the view registry).
Alongside the views, the fields (<field name="..."/> in archs) and
widgets (<widget name="..." in archs) of web/ have been implemented
in owl as well. Legacy ones remaining in other addons are supported
in our new views, thanks to a compatibility layer. The goal is to convert
them asap though.
Legacy views, fields and widgets are kept for now, which explains the
number of added lines in this PR (around half of them concern tests).
They are still extended by custom code in other addons, that still need
to be converted (a lot of them are already on the way). Moreover,
they are still used in Studio as well. The plan is to lazy load them in
the Studio bundle when all custom code extending them will be
converted. Studio will be converted for v17.
Part-of: odoo/odoo#92475
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: Francois (fge) <fge@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: luvi <luvi@odoo.com>
Steps to reproduce:
1- install sales
2- allow warnings on sale orders
3- set a warning w with multiple lines on
sale order on customer c
4- try to add c to a sale order
5- w will be shown in one line
Bug:
the html is escaped and the proper styling is missing
Fix:
add the proper style
OPW-2847660
closesodoo/odoo#94730
X-original-commit: 36546f39ca44f6d5691e3b1d8a7d1eb2da4a7b51
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mohamed Megahed Abbas Megahed SALLAM (mome) <mome@odoo.com>
Before this commit, the test utils that trigger an event (e.g.
click) didn't check whether the target of the event was visible.
As a consequence, when writing a test, one might trigger an event
on an invisible and undesirable target, and don't understand why
it doesn't work due to the absence of feedback. This commit
improves that situation by throwing an error in those sitations.
Obviously, some tests relying on the former behavior needed to
be slightly adapted.
closesodoo/odoo#93549
Related: odoo/enterprise#28360
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to follow
- Use chrome
- Connect to a runbot with the demo account
- After a couple refreshes, the mail.MessagingMenu isn't displayed
Cause of the issue
The navbar should be updated when there is a new item added to the systray registry.
For that, the navbar listen to the update event with the `useBus` function.
`useBus` itself uses `useEffect` which only starts listening after a component has been mounted/patched.
-> The update callback is never called in this case because new items are added before the callback is registered.
opw-2801467
closesodoo/odoo#92768
X-original-commit: c2fd26881ceae95417e2a0afc71fdf8567e3b8c0
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Now that pyEnv is available, using it in the mock_server lighten the syntax.
task-2582313
closesodoo/odoo#90783
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Previously, the "debounce" util function was broken when passing
immediate=true, this was caused by the fact that the timeout was not set
to null after being executed, leading the function to always act as
though a call is already scheduled.
This commit basically rewrites the entire debounce function to fix this
problem, simplify the code, and make the API of debounce as close as
possible to underscorejs' debounce utility (with the exception that our
debounce function returns a Promise that gets resolved if and when the
call eventually goes through, and with the extra feature that the
debounced function has a cancel method to cancel the currently scheduled
call)
closesodoo/odoo#90297
X-original-commit: 24c39ba1744d83ef9712ef4d3df7db5baf35bc2e
Related: odoo/enterprise#26821
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Earlier in Odoo, JS views were defined by defining 4 elements: View,
Controller, Model, Renderer. This was complex in some way, because we
wanted to inherit behaviour as well, so it was necessary to think along
multiple dimensions to understand how the code was running.
Then, with Owl, we rewrote some views, and simplified them: views were
now just a Component. Most of the common behaviour now came from the
generic View component that instantiated the concrete view with the
proper informations. In practice, views were still split in views
(which was the equivalent of the Controller of earlier views), Model and
Renderer
Now, this commit reintroduce the Controller, and change the way views
are defined: by an object with multiple metadata, and an (optional)
props function to compute the actual props used by the view.
As a result, views are now much easier to extend/modify.
closesodoo/odoo#89889
Related: odoo/enterprise#26728
Signed-off-by: Géry Debongnie <ged@odoo.com>
When a doAction is done, the action service stringifies the given
action and writes it in the session storage, s.t. it can be
restored on F5 even if it's a dynamic action (i.e. not in DB).
However, the stringify operation may crash (e.g. if there is a
cycle in the action description). As we do not control what is
given to doAction, it can happen, and we have to properly handle
it.
This commit simply catches the error, and there's nothing more to
do in this case.
Part-of: odoo/odoo#90271
Have an action with target="new" and a list or kanban view as
first view. This view is displayed in a dialog. Click on a record.
Before this commit, the action service tried to switch view, but
in the action displayed in the background (since we cannot switch
view inside the dialog anyway). As a consequence, if the action in
the background was a window action with a form view, we opened that
form view, which is absolutely not what we want (different action,
different model...). And if the action in the background was a client
action, it crashed, because we can't switch view in those actions.
With this commit, we simply ignore calls to switchView when there's
a dialog opened.
opw 2791201 and 2793678
closesodoo/odoo#89539
X-original-commit: 81f8de82daa47a31e4a33478aeb537f2c9c1519c
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Have an action with target="new" and a list or kanban view as
first view. It is displayed in a dialog, and a there is a control
panel. Before this commit, the breadcrumbs in that control panel
contained the complete history of controllers displayed in
background, which isn't what we want. For instance, clicking on
an element of the breadcrumbs crashed. After this commit, there's
only one element in the breadcrumbs, which corresponds to the
controller displayed in the dialog.
Spotted when investigating on opw 2791201 and 2793678
X-original-commit: 9838bb3a35e8b205fe30ceb5f86dcd81d536d1d0
Part-of: odoo/odoo#89539
Before this commit, when closing an action Dialog ( when the action is
wowl ) an error was raised. This occurs because we use the
LegacyAdaptedActionDialog, and an old function is called.
closesodoo/odoo#88118
X-original-commit: a6e45c53642003243e8a0f498e69ffddcac6e086
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The target "main" feature has been lost during the conversion of
the ActionManager into the action service. An action with target
"main" should always clear the breadcrumbs. This commit
re-introduces the feature.
Fixes#83865closesodoo/odoo#87610
X-original-commit: 78ec7281ed550eb24629c1b81445b753314d292f
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: "Aaron Bohy <aab@odoo.com>"
