If the method return false, when a user write require="1" on a x2many field, the content is valid that there have none or a value.
The method was overwrited for a visual change (display the field x2m in readonly mode when they are not value) but is_false is priority use to ensure datas.
Rev e37ba61 forward-ported 8.0 revision f02b230 from PR #12379.
This patch introduces extra tests and views for o2m onchange behavior,
including new fields in the test models.
In 9.0 a new convert_to_onchange() mechanism had been
introduced at 9f81c6d
The combination of both requires some adaptation to the
expected results of the new tests and adaptation of existing tests.
The test models in `test_new_api` have an implicit depencies between
models which cannot be express on ORM:
messages depends on participants of their discussion.
So, when editing a discussion, the field `participants` should be
processed before field `messages`. This is not always done because
field processing order depends of the iteration order of a `dict` (which
is undefined in python).
The testing tour `widget_x2many` worked by chance until now.
Adapt the tour to save the participants before the messages.
Private browsing in Safari doesn't allow to store anything in the localStorage,
and it throws an error when you try to do so. This new JS module is a connector
to the browser's localStorage if it is enabled, and if not, it simply keeps its
own storage in RAM.
Another reason why it’s better to change ‘not archived’ into ‘active’ is
because ‘active’ is the functional name of this field in the filter list in list view.
For the rest, it’s just a better en_US way of saying it.
On an editable list view, an issue occurs with the following procedure:
- Click "Add an item", write something
- Press "Enter" key --> a new item is added, write something
- Click outside of the list, then click on the last item created
- Press "Enter" key --> the cursor is set at the beginning of the list
This is an issue for two reasons. First, the behavior is not the same if
we have clicked outside of the list before pressing "Enter", which is
not logical. Then, in some undetermined cases, the focus can be lost
then retrieved on the last record. It means that suddenly, the cursor
goes back at the beginning of the list without notice.
The latter issue is problematic when batch-encoding data, for example
encoding the lot numbers of incoming products thanks to a scanner.
opw-680758
Before this commit, the action manager could in some case have a
reference of a modal dialog, even after it has been destroyed (for
example, when the "X" button has been clicked to close a modal).
Unfortunately, it has some unexpected consequences, for example, the
do_push_state method check the existence of self.dialog to update the
url.
When the content of a Many2Many tag is too large, it is truncated. This
is an issue since there is no easy way to see it.
The fix adds a title on the tag with the content.
X-port of commit odoo/enterprise@bd3bfe0422
In the Filters, Group By and Favorites dropdowns,
when clicking outside the `li` elements but still
inside the dropdown menu itself
(like on the dividers,
or next to the advanced search `Apply` button),
the dropdowns was closed.
This behavior was annoying when doing an advanced search
with a field using the datetime picker, as, to close the datetime
picker, you have to click outside it, and when you did, it closed
automatically the filter dropdown... So you had to open it again to
finally apply the filter.
opw-674310
The action object, and in particular its context, is modified by the Action
Manager and by some views (e.g. sales_team_dashboard Kanban). So, as the action
is stored in cache, the same object was returned each time the action was
requested, and previous modifications of its context still applied.
This produced a bug with the sales_team_dashboard when following those steps:
- click on the link to today's activities, it opens an action with
'search_default_today' in the context,
- come back to the dashboard
- click on the link to this week's activities, it opens an action with
'search_default_this_week' in the context, but the formerly added key
'search_default_today' is still there as well, so the domain is wrong.
1/ On create new record focus field should select already existing value of field,
So user doesn't have to remove the old value first and then enter new value.
2/ Forget about it
This reverts commit c43a97f353.
If you use a setTimeout in your js code, you might want to have a
serious look at what you are doing. You are almost certainly doing it
wrong.
If you chain a deferred with the number returned from a setTimeout, you
definitely don't know what you are doing.
If you try to fix editable list view by magically adding timeout,
potentially inversing the order of execution, and without understanding
how deferred works, it is clear that you are just changing stuff until
your particular bug disappear in your particular case, and that you have
no idea what other bugs you just introduced.
Please study how deferred works, how the basic JS methods works, learn
what setTimeout returns. Also, you might want to have a basic
understanding of how and when expressions are evaluated. For example,
if you cannot explain why a if statement cannot be replaced by a
function, you might want to stop what you are doing and educate yourself.
1/ On create new record focus field should select already existing value of field,
So user doesn't have to remove the old value first and then enter new value.
2/ Avoid the double empty line creation when pressing enter
step to produce
1 Menu Point of Sale > Configuration > Point of Sale switch to form view
2 Tick the box "Cash Control" , the one2many field will be visible
3 Press the "Tab" from keybord , control jumps to "Add an item" button
4 Press "Enter" from keyboad
5 You will see one extra line will be added..
When the user visited a view for the second time, the extra actions in the sidebar
were broken. The reason is that the sidebar code modified in place the
fields_view information.
Note: This was not a problem before, because the field_view_get call was done each
time the view was loaded, but now it is cached.
Christophe Matthieu