Steps to reproduce the issue: on an MD sized screen (i.e. such that
the chatter is below form views), go to a sale order in edit mode,
scroll down and click on 'Add an item', a modal opens, and the form
view behind scrolls back to the top, whereas it should keep its
scroll position.
This is because the ActionManager listens to event 'DOM UPDATED',
and when it occurs, it restores the current action's scroll
position (the main purpose is to restore the scroll position of a
previously visited action to which we return using the breadcrumbs).
When a dialog opens, this event is also triggered, but in this case
we should not restore the scroll position of the action in the
background.
Fixes#23491
This could (should?) be considered a refactoring, but this is actually
trying to restore lost functionality. In v10, the custom form widgets
were created with access to the node element that define them. We lost
that in v11, with the new views.
However, it is actually very useful for generic widgets. Since this is
not really a risky fix, I think that it can be done in 11.0.
Note: this feature was already reintroduced in master in commit
https://github.com/odoo/odoo/commit/b7aa439826df6b3e442b3f60bb593ff28efc8679
Before this commit, images in kanban view of the Contact app were not displayed
on non-latin languages, such as Russian.
This was caused by the is_bin_size helper that wrongly assumes that a certain
string is not a binary size, although it is (e.g. 64.2 Кб).
This commit fixes the issue by including such strings as valid binary sizes.
Bug found and fixed by @true-datura
Test by @alexkuhn
closes#23526closes#22519
Before this rev., the field widget 'mail_activity' kept an internal
cache of fetched activities (like the 'mail_thread' and
'mail_followers'). However, for activities, this cache may cause
issues.
For instance, create a new lead in 'My pipeline', schedule a
'Meeting' activity on that lead (it opens the Calendar view so
that real meetings can be created), create a meeting 2 weeks from
now, go back to the lead form view: the activity still diplays that
the meeting is today (when the view is refreshed, the correct date
is displayed).
This rev. removes the internal cache for this field widget, as the
activities can easily be updated in business flows (unlike messages
or followers).
This rev. also fixes a bug in the BasicModel, where the res_ids of
a list datapoint was altered in place to return a list of x2many
commands instead of the list of ids when being stringified. This
caused a traceback when opening a lead with activities, as soon
as the internal cache had been removed.
When there were no status widget in the form view statusbar, the left
buttons appeared without any vertical space around them in a smaller
statusbar.
There also was a 1px mistake that made the buttons appear non-centered.
Now they appear centered in any case and a row of buttons is always
forcing the correct statusbar height.
Closes https://github.com/odoo/odoo/pull/22053
opw-(1)813479
This is a manual forwardport of rev. b466b3bc.
Consider the following scenario: open in edit mode a form view
containing a many2many field displayed with widget many2many_tags,
on the many2many field dropdown, click on 'Search More' (it opens
a dialog), and in the dialog, try to save the current search in
the searchview's favorite menu.
Before this rev., it tried to retrieve the context of the active
controller in the closest instance of a ViewManager-like widget
in the SearchView's ancestors.
First, it is wrong as in the given scenario, the requested context
is actually the one of the list controller in the dialog, not the
one of the form controller in the background.
Second, it produces a crash in Studio, when trying to save filters
in the dialog opened by clicking on 'Search More' on the groups
many2many field in the sidebar.
This part of the code can't be tested in this version, but tests
will be added in master.
Fixes#23293
Consider the following scenario: open in edit mode a form view
containing a many2many field displayed with widget many2many_tags,
on the many2many field dropdown, click on 'Search More' (it opens
a dialog), and in the dialog, try to save the current search in
the searchview's favorite menu.
Before this rev., it tried to retrieve the context of the active
view in the closest instance of a ViewManager-like widget in the
SearchView's ancestors.
First, it is wrong as in the given scenario, the requested context
is actually the one of the list controller in the dialog, not the
one of the form controller in the background.
Second, it produces a crash in Studio, when trying to save filters
in the dialog opened by clicking on 'Search More' on the groups
many2many field in the sidebar.
This part of the code can't be tested in this version, but tests
will be added in master.
Fixes#23293
When creating a record in a form view of model A, and adding a line
in an inside tree view of model B(with a One2Many from A to B), it was impossible
to delete a wrong line even if the record has not been saved because the user had no
right to delete a record on model B.
opw:1819099
Since we are able to lazy load Qweb templates, there was
an issue to generate Awesome Timesheet iOS native app with
Cordova properly. It seems that under Cordova, iOS always
returns 0 for the status on a xml http request object.
The problem is that native applications are requesting
a local file from something that isn't a webserver.
The local file is delivered with no http headers that means no
"200 OK" header and no "404 Not Found" errors.
In this case, the request is still be completing as intended even
if the status code used by browsers is 0.
For more info, see:
https://developer.mozilla.org/fr/docs/Web/API/XMLHttpRequesthttps://bugzilla.mozilla.org/show_bug.cgi?id=331610
If the user tried to generate a report with more than 256 columns,
he would get a traceback instead of an error message.
Furthermore, if only one measure was selected, then the check was not done
and the user would also get a traceback.
opw-1816931
In some cases, the footer in a form view dialog could be duplicated.
The reason was that the form view was rerendered completely, footer
included, by the renderer, out of the formcontroller control (it is the
formcontroller's job to move the footer buttons to the footer).
A possible fix is to work on the form renderer to make it aware that the footer
buttons are expected to be only rendered once, but it has the disadvantage to
be a fix specific to this issue, and any other form view behaviour with some
side effects may have the same issue.
This commit tries to prevent the form view from rerendering itself
completely in those cases. This also has the disadvantage of possibly
not being a complete fix, if some edge cases are missed. However, I
have the feeling that we still want to avoid rerendering the full view
if possible.
Before this rev., in week and month modes, when navigating through
weeks or months, the weekday/monthday of today was still
highlighted in other weeks and months than the current ones.
This rev. ensures to only highlight today in the main calendar
view (this doesn't impact the mini calendar).
The DomainSelectorDialog behaves differently from classical dialogs
in terms of height and overflow: (1) its height can be larger than
the screen height, and (2) its content is never scrollable
(overflow visible).
However, before this rev., the 'height: auto' rule ensuring (1)
didn't apply, so the dialog's height was limited to the screen's
height, and when it had to much content to display, it overflowed.
It didn't work because the code tried to apply the rule too soon,
so the .modal-dialog element was not yet available.
Fixes#23292
Warnings are styled a bit differently than notifications, as their
background is red (thanks to classname 'o_error' on the warning
root element). This classname isn't correctly added since rev.
920df59, which changed the root element of the 'Notification'
template, which is extended by the 'Warning' template, making
qweb.js fail to add the 'o_error' classname.
Before this rev., it crashed when trying to create records of the
res.users model. This is due to commit ad1cceb.
The 'default_get' of 'res.users' always returns a value for field
'groups_id', whereas the docstring of 'default_get' states that it
only returns default values for fields given in arguments.
Rev. ad1cceb changed a bit the way the result of 'default_get' was
processed, by iterating over the values instead of over the fields
in the view. So, before ad1cceb, 'groups_id' was simply ignored,
and after, the BasicModel tried to process it and it crashed when it
attempted to retrieve its fieldsInfo, as this field isn't in the
view.
This rev. restores the previous behavior.
Fixes#23303Fixes#23305
Let's assume a one2many displayed over several pages with a default
order such that a record, say R, that would normally be on page 1
is actually on another page. Moreover, there is an onchange on that
one2many which converts all commands 4 (LINK_TO) into commands 1
(UPDATE), which is standard in the ORM.
When the first line of the one2many was edited, the record R was
fully loaded, whereas it shouldn't have been (as it is not on the
current page). So basically, a useless read was performed.
Moreover, if there was an x2many field in the one2many list, a
crash occurred because relational data of R that shouldn't have
been read wasn't postprocessed by the BasicModel.
The useless read occurred because the one2many subrecords weren't
correctly sorted before checking if some of them/some of their
fields should be read. This is not the case anymore.
OPW-1816800
Let's assume a one2many list view inside a form view, displaying
a single char field A. There is an onchange on the form view
returning a command 0 (CREATE) for the one2many. The command 0 only
specifies a value for field A. The one2many list isn't editable, so
when a sub-record is clicked, it is open in a form view (in a
dialog). In this form view, an x2many field B is displayed in a sub
list or kanban view.
Before this rev., it crashed when the user tried to open the
created one2many sub-record (returned by the onchange) in the form
view, because of the presence of the x2many field B, which wasn't
correctly processed by the BasicModel (its value was undefined,
whereas it must be a valid, empty, dataPoint).
Moreover, the limit of the x2many field B wasn't set, so a pager
was displayed as soon as it contained at least one record.
Fixes#22050
This is more a architecture fix than a bug fix. With this commit, it is easier to modify the behavior of the dialog using the super function. like this: this._super.apply(this, arguments).opened(...)
PR #23255
Issue:
domain="[('date','=',time.strftime('%%Y-%%m-%%d'))]"
is converted into a domain equal [('date','=','%2017-%12-%12')]
instead of [('date','=','2017-12-12')]
This commit improves link creation in web editor.
Before this commit, anything with a @ would be considered as valid email which
is obviously not the case. It would then be prefixed by 'mailto:'.
This was causing 2 issues:
- URL with @ symbol in it would have 'mailto:' added as prefix, like google
maps coordinates.
eg: mailto:http://www.google.com/maps/whatever/@312211.22,321321
- Incorrect emails would go through (eg: @@@, ko@k@k@, mail@mail)
Now, we will try to detect and identify valid emails from invalid emails from
URLs. It will also handle 'mailto:' directly typed in the input.
This commit comes with it's counterpart in enterprise https://github.com/odoo/enterprise/pull/1859
This closes#11984, closes#22936
Note that there is a WIP in master to use this new is_email function
everywhere we try to validate emails. It will aim to uniformize email
validation in odoo's javascript that are often performed with different mean
here and there, some more permissive than others, some only checking for @.
Before this rev., an issue occurred on grouped editable list views
that became ungrouped after a reload (i.e. when the grouped part in
the search view was removed). In this scenario, the click handler
outside the list used to leave the edition wasn't bound (because
the list was grouped at the beginning, and thus not editable). So,
it was impossible to leave the edition, even by clicking on 'Save'.
Fixes#23061
This commit only concerns the community webclient. The user can
edit the company data by clicking on the company logo displayed
in the submenu (left bar). When it does, the logo's url must be
updated to force the logo to be reloaded.
The last part doesn't work since the new views, as it uses an
hook of the form view (called when it is saved) that doesn't
exist anymore.
This rev. adapts the code so that the logo is reloaded when the
edit menu dialog is closed.
It also ensures that the logo is properly reloaded by specifying
the timestamp in the img url as a query string parameter instead of
an hash param, since changing the hash doesn't seem to be enough to
fool the browser's cache anymore.
When onchange RPCs return a command 4 (LINK TO), the res_id of the
record to link is given, and the BasicModel has to read the fields
in the view for that record. When one of those fields is an x2many
(for instance, displayed with widget many2many_tags), the
subrecords in the relation must be read as well (at least their
display_name).
Before this rev., this last part wasn't done by the BasicModel, and
as a consequence, the many2many_tags widget was always empty, even
though there were records in the relation.
Same thing applied to reference fields, but this is way more
uncommon.
This rev. ensures that x2manys and reference fields are correctly
fetched in this scenario.
Before this commit, there is an issue with one2many lists with records that
have been created on 'default_get': if the record has a required field that
is empty, when the user clicks on this empty required field and then somewhere
else, the record is removed from the list.
The cause of this bug is that these records have invalid field changes, here
the required field that is empty. As a consequence, it checks whether the
record is "new", and if so, removes it visually from the editable list.
(Note: a record is "new" when it is not stored in DB).
This behaviour is expected when discarding records created from "Add an item".
However, that is not intended for records that have been created as default
items of the list. These records are still considered as "new" items, because
they are not stored in DB, but they should stay in the list on discard.
This commit solves the issue by making an additional check before assuming
that the record for which we discard changes comes from "Add an item":
if the record in the list has been created before user interacts on the list
(in other words, the record has been added in the list when the user accesses
it), then we should not remove the record from the list, even though the record
has some invalid fields from the savepoint (e.g. empty required).
opw-806650
Create a new column in Project, add a record and then hit 'Archive Records' : a
traceback occurs.
When creating the new column, the `groupedBy` attribute on the datapoint is set
according to the parent list datapoint, which makes no sense as the records are
not grouped inside the column.
The mentioned attribute is now removed as the records cannot be grouped inside
the column.
Before this rev., the aggregates values displayed in the footer of
list views were formatted according to the field type, and the
field's widget was ignored, whereas it should be used by default.
For instance, if the 'float_time' widget is set on a float field,
the sum should be formatted as FloatTime as well.
Closes#22724.
Before this rev., the list of selected records wasn't correctly
reset when the list was reloaded (e.g. when coming back using the
breadcrumbs). In the UI, the records weren't selected anymore, but
in javascript, the list of selected records wasn't empty. As a
consequence, the aggregates were wrongly computed, and always
displayed 0.
Closes#22725.
Since the <widget> tag is not used anymore in any of our views, it was
not really properly supported. In particular, the form widget was not
notified when the state of the form view has changed, which makes it
very difficult to actually do any useful work.
With this commit, we make sure that the widget method 'updateState' (if
it exists) is called with the new state whenever it changed.
This should allow developers to do useful work without having to work
around the issue. Note that this is not really a perfect solution, since
the updateState methot may or may not have been implemented.
I think that we need some kind of ViewWidget abstraction, which could be
used to have a better and more complete API for widgets in a basic view.
And AbstractField could inherit from ViewWidget.
Rev. dbdd742 introduced the 'baseMode' parameter of field's nodes
in the BasicRenderer. Its purpose is to encode the generic mode
of the field, regardless of its readonly modifier (i.e. in form
views, the baseMode of all fields is the mode of the renderer and
in list views, the baseMode of all fields is 'readonly', except for
fields in the row being edited, whose baseMode is 'edit').
Unfortunately, when the value of the readonly modifier of a field
was 'readonly', its baseMode was changed from 'edit' to 'readonly',
which shouldn't, as the baseMode's value should not be affected by
the modifiers.
This produced a bug when a field had a readonly modifier, as once
its value became true, the field was rendered in 'readonly', and
whatever the value of the modifier afterwards, it always remained
in 'readonly'.
The rev. ensures that the baseMode is no longer impacted by the
value of the readonly modifier.
Closes#22729
The parentedMixin doesn't automatically set the parent, so when this mixin
is used, the parent must be set manually. This wasn't done at several places,
and thus those elements weren't destroyed with their actual parent.
In master, we should probably make the ParentedMixin set the parent itself.
Before this rev., it might happen that the parent of BasicModel instances
wasn't correctly set to the Controller instance. It was actually set to the
ActionManager instance, which is never destroyed. So when this happened,
the BasicModel instance wasn't destroyed when it's controller was.
The parentedMixin doesn't automatically set the parent, so when this mixin
is used, the parent must be set manually. This wasn't done at several places,
and thus those elements weren't destroyed with their actual parent.
In master, we should probably make the ParentedMixin set the parent itself.
Before this rev., it might happen that the parent of BasicModel instances
wasn't correctly set to the Controller instance. It was actually set to the
ActionManager instance, which is never destroyed. So when this happened,
the BasicModel instance wasn't destroyed when it's controller was.
This is a small correction of odoo/odoo@3aad756 ; a traceback occured when ESC
was pressed in a list view with modifiers.
The `confirmChange` was done on the parent datapoint (of type list) which has no
attribute `evalModifiers`.
`confirmChange` is now called on the record datapoint. Note that for x2m, it
means that all modifiers linked to the parent record won't be re-evaluated (but
this wasn't probably intended as this is a bit overkill).
Closes#22718
A traceback was occuring when downloading the pivot view without data.
The export function expects the attribute `main_row` set on data, which
is defined in `_prepareData`. The latter wasn't called because of the `return`.
Closes#22728
Aaron Bohy