Have a list with readonly modifiers on at least one column.
Have the first record of the list be readonly as computed by the modifier
Create and edit a second record
Enter a value in the cell and hit TAB
Before this commit:
The focus on the targetted cell was lost and the rendering of the cell was in mode readonly
This was because the baseMode of the modifier dict was applied to one and only one node (== one column) and hence to *all* the records
After this commit:
The rendering and keyboard TAB navigation works as expected in the list editable
The baseMode concept has been sharpened and each cell now has one
OPW-1816569
OPW-1824979
closes#23809closes#22859closes#23436
* [FIX] web: Make accessible with keyboard the delete button on o2m fields
Currently, the delete button in one2many fields (trash icon) is not
reachable when using the keyboard, because it's neither a link, nor a
button or any other interactable HTML element, but a `<span>`.
This change causes that button to be an actual HTML button keeping the
same appearance, so it may be reached when using the keyboard.
* [FIX] web: Modify test to expect button instead of span as o2m trash icon
Since buttons to delete records in o2m fields (the trash icon) were
changed from `<span>` to `<button>` to be able to access them with the
keyboard, the test need to be modified so it expect the new element
type and doesn't break.
Before this commit, search was broken because containsLike was searching on
the innerHtml. (3dd93ed129)
Settings use _wordHighlighter to change the background of the matching text
into the label, so the label was not only text, but html.
<label><span class="highlighter">Mul</span>ti-company</label>
: looking for (mul)
After this commit, the match is based on the text content and not on the html.
Steps to reproduce:
- Create a sale order and add sale order lines(Not Inline) without saving the sale order.
- Edit any of the existing sale order line and hit on "Save & New" on the sale order line.
- Add another sale order line and hit on "Save & Close"
Bug:
A validation error was raised.
opw:1829723
the only goal of this change is not to use a jquery selector on the
body of the document.
Jquery adds an ID attribute to all the nodes it selects. This in turn
triggers the attribute change debugger in chrome, and creates a lot
of noise while debuging.
Some status were shown in the statusbar even though they were not specified in
the `statusbar_visible` attribute. This happened when the value was a substring
of one specified value.
Example:
```
hello = fields.Selection([('hello', 'Hello'), ('hello_world', 'Hello World')])
<field name='hello' widget='statusbar' statusbar_visible='hello_world'/>
```
In this case, both status were shown ('hello' is a substring of 'hello_world').
Fixes#20034
Sidebar's menu items are not currently reachable when using the
keyboard, because they are missing the attribute `href`, thus are not
indexed for tabbing navigation.
This change causes that attribute to be included, so the menu items are
reachable and navigable when using the keyboard.
Some HTML attributes were missing, and are required to ensure good
compatibility with screen readers.
The following attributes are included:
- `aria-expanded`: this should be present in all dropdown menus
- `aria-label`: this should be present in all links and buttons which
don't show text, but icons or images.
Before this commit, there was an issue with input method using
composition in which typed characters were duplicated.
This was occuring until the composition ended.
This is a bug specific to Google Chrome v53+.
It has been fixed in the most recent version of ace.js [1],
and we just port the fix into our custom code.
Note that we do not simply import ace.js as a whole, because
we must update lots of custom code at the same time.
We plan to do so in the future.
Fixes#23629
[1] https://github.com/ajaxorg/ace/pull/3116
Before this commit, we had the following issue:
1. install CRM and Sales
2. Sales > Customers > (open any form)
3. Click on browser's "back" button
We are redirected to the contact kanban view in CRM
instead of Sales.
This is due to the fact that both menu items share the
same action. When the user uses the browser's "back" button
(AKA. it triggers an hashchange event), the web_client opens
the first menu_item that matches the action.
This commit fixes the issue by allowing us to open an action
by providing a menu ID:
1. If it matches the action, then it opens this menu
instead of the first match.
2. If we do not provide any menuID, or this menuID does
not match with the action, it falls back to the first
menu matching this action.
Fixes#23639
Before this commit, the menu_id displayed in the url was incorrect
when we click on a menu item for the first time.
This is due to the fact that the web_client was mistakenly using the
previous menu_id as the action's menu_id: the JS widget menu is not
up-to-date with the value of the current menuID, and the web client
was relying on its internal state instead of the server's response.
With this commit, the web client uses the server's reponse to
register the correct menuID that has been clicked.
Before this rev., the search menus (Filters, Group By, Favorites)
were lost when the user came back to an action with the
breadcrumbs (e.g. go to My pipeline, open a lead, click on the
Meetings stat button, go back to My pipeline).
This was because the two searchviews shared the same jQuery element
containing their dropdowns. This behavior is there for a long time,
but the bug has been revealed by 7b6056a0, which changes the way
the action manager and controllers interact with the control panel.
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
On mobile, kanban view always have its custom "menu" bar to cycle
between grouping if the kanban view is grouped.
But if the kanban view did not have the class `o_kanban_small_column`
the mobile CSS on record was not applied:
- all columns were always displayed one over the other
- switching tab did not hides other columns and show current one
- the style was the same than desktop (but on mobile and with column
after first "to be loaded)
opw-1827142
closes#23691
This rev. strengthens the handling of concurrent actions of type
'ir.actions.act_window' in the ActionManager. In particular, the
two following cases are now handled:
- execute an action A, its 'load_views' RPC takes a while, during
that time, execute an action B: A can be dropped, meaning that
it doesn't need to fetch its data, and thus it should not be
appended to the DOM (nor appear in the breadcrumbs) ;
- execute an action A, its 'read' or 'search_read' RPC takes a
while, during that time, execute an action B: A can be dropped
and should not be appended to the DOM (nor appear in the
breadcrumbs).
Have a model with a m2m (field A)
this m2m has also a m2m (and displayed as m2m tags in the view) (field AA)
Have a domain on field A, to trigger the search view selection
Click on add an item
Select everything in the modal, making sure that there is more than 40 records
Click on Select
Before this commit:
There was a traceback indicating the local data did not contain records >= 40
This was because the internal data repository was constrained by a limit
After this commit:
We adapt the limit of the local data repository and there is not traceback
OPW 1823400
When we discard an element, we want to make sure that the new state is
not corrupted by previous user operations. In our case, we possibly had
a limit and an offset values modified by the user.
This could lead to unpleasant situations, with incorrect data displayed
on the form view.
Note that this actually fixes a new bug introduced by commit
https://github.com/odoo/odoo/commit/e7fab234201e357da52c3576ad2e8fc9ceee9359
(this is the commit that introduces the tempLimitIncrement attribute)
The issue here is quite simple. If we are editing a multipage one2many
field, then we click on the pager, we need to properly unselect the
current row.
If we do not do that, then we can enter invalid data. For example,
assume that there is a readonly field. We click on add, it creates a
(virtual) record with no value for that field. When we click on the
pager, we select the next page, and bypass all validation.
When we are in the process of adding a record, we do not want to update
the pager count. The reason is that if the user is at the limit (so,
1-40/40, no pager visible), then click on add, there will be a pager
shown with 1-40/41. Now, imagine that the record currently being added
as a required field, and the user clicks on the pager. In that case, we
need to discard the newly added record (bringing the total back to 40),
then move to next page, which does not exist anymore.
So, to fix this issue, we simply consider that a record being added
does not count, from the point of view of the pager.
The widget statusbar was using an attribute `clickable` on the field widget
to define if the statusbar was clickable.
This attribute is in fact not a field attribute but a widget option so it
has been moved accordingly.
Note that a retro-compatibility adapation is done in the field widget.
Note that we do not do a custom build anymore, since we lazyload the
files anyway. A custom build will save a few kb, but will not do any
meaningful change to the user experience. However, it dies impact
negatively our ease of maintenance, so standard build it is.
Loaded actions (i.e. executed from url state, e.g. after an F5)
should not push their state back to the url. This was working fine
of act_window actions, but not for client actions, and this was
causing an issue in Studio as the same mechanism is used to prevent
the main Studio client action from pushing its state into the url
(to keep the state of the edited action in the url instead).
On an editable line with a many2one
Click to create a record
Click on create a record in the many2one
It opens the form view of the object in a modal, which has a many2many list, which choices are domainized
Click 'add an item' on this list
It should open a modal with the filtered choices
Click on any of the existing record
Before this commit:
There was a traceback in JS
That was because the event bubbled up to a parent, when it shouldn't
After this commit:
The whole flow unfolds without errors
OPW 1823205
Before this rev., this attribute was ignored for groups containing
sub groups.
Task 1786309
Closes#23514
Co-authored-by: Mohammed Shekha <msh@openerp.com>
When the bottom left and right areas were taking to much space, the
right one overflowed the kanban card, because those two areas
weren't allowed to shrink. This might occur for example on the
sale.order view.
A big problem with the o2m edition happens when the user has a full page
(so, in general, 40 records) and click on add.
If the o2m is in editable="bottom" mode (which is actually a really
common usecase), then the next record will be added at the end.
However, since we have a limit of 40, it will immediately go to the next
page.
The effect is even weirder when there is a required field in the tree
view. In that case, the new record appears correctly, the user can edit
it, then, as soon as the required fields are set, it will immediately
disappear from the current screen.
In this commit, we have a really simple solution: we simply increase the
limit in this case. An interesting thing is that it is actually temporary:
when the user goes to the next page, the limit is back to its original
value (due to the pager click: it resets the value to what the pager knows).
The 'toggle_button' widget is one of special field widgets that
can trigger changes in readonly mode (in this case, toggle the
boolean value when clicked). It was working fine in form views in
'readonly' mode, as in this case, the new value is saved directly,
and the form view is re-rendered (a new widget is created with the
new value).
However, in 'edit' mode, the value isn't saved directly (the user
has to click on 'Save' to save the changes), the widget is reset
with its new value, and the reset wasn't correctly handled in this
particular widget.
Fixes#23400
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
In multi pages list view, the scroll position is reset to top when
the user switches between pages. This wasn't working if he first
reset the limit, and then switched between pages.
This rev. improves the way the scroll position is restored when
coming back to a view (e.g. open a kanban view, scroll, click on a
record to open it in a form view, go back to kanban using the
breadcrumbs):
- generalize the scroll position handling from web_enterprise to
web to make it available in the community webclient as well
- also restore left scroll position, not only top (especially
useful for grouped Kanban views with a lot of columns)
- handle the case where the scrolling area is a sub element of
the view (e.g. the grouped Kanban view in mobile).
Task 34037
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Co-authored-by: Ankit Sathvara <asa@odoo.com>
Actions loaded from the url are flagged with 'pushState: false', to
prevent them from pushing their state back to the url, thus
producing an infinite loop. However, if the state of a loaded
action changes in the future (e.g. load an action in kanban view,
then switch to a form view), this state should be pushed to update
the url. Before this rev., this wasn't the case.
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, a client action was simply a subclass of Widget.
This is quite simple, but not really enough for the ActionManager. The
ActionManager needs to handle client actions in a different way that
view actions. Sometimes, it needs to check if a method exists before
calling it.
With this commit, we introduce a new abstraction: the AbstractAction
class, which defines a common API for all actions managed by the web
client.
Note that the API proposed in this commit is just the beginning. We will
introduce other methods in the future, to manage the focus, or the
scroll position, for example.
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
There was an issue with the control panel in mobile since rev.
7b6056a. In the enterprise webclient, by default, the search view
is hidden, and a search icon should be displayed on the top right
corner of the control panel so that the user can toggle the
searchview.
Before this rev., the icon was invisible at the first rendering of
a view, and only appeared once the view was reloaded.
The change in rev. 7b6056a that produced the issue is that the
control panel is now updated twice when a view is rendered (once
by the view itself with the buttons, searchview..., and once by
the ActionManager with the breadcrumbs). The control panel didn't
handle correctly that scenario.
A test case will been added in web_enterprise.
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.
Christophe Simonis