Same reason as 8d948d92.
In firefox if barcode is installed, for example on a form view the keys
to navigate the possible scrolling PageUp/PageDown/Home/End don't work
at all.
This is caused by the interface barcode catching and differences of the
key event handling between firefox and other browser.
So in this change, we add these keys so they are not catched by barcode.
note: aso backport 5bc29744c so the code is the same between 10 and 11.
related to opw-706352
closes#26219
- JS Modals were not correctly built anymore, their .modal-body element
was duplicated and many without-effect JS lines were introduced (as a
side effect, the form view design was broken when inside modals)
- Tests were changed to make bugs go unnoticed. For example, the media
dialog functionnality was entirely broken because the .modal-dialog
element was not receiving the correct class anymore.
- The JS translation function is _t, not _
- Do not use the <title/> tag as a regular DOM element, it is meant to
be unique, in the <head/> section
- CSS rules were added to the utils.scss file, which is meant to contain
functions and mixins, otherwise, the rule is duplicated in every asset
- Some icons were still broken, as missed by https://github.com/odoo/odoo/commit/f90cf060a3cfeb37a67bec83264c0aaab8892b56
- Tests were changed to use [role="dialog"]/footer/header in their
selectors without any reason, this commit restores some of that to
avoid rebase conflicts with the BS4 work.
- ...
Note: other elements should still be discussed, like the direct use of
the 'o_form_label' class in views definition... but those do not cause
direct problems.
PURPOSE
=======
1. Unified product demo data
2. Less demo: one per use case
3. Demo data for all models
Specification
=============
1. Refactor all the brol in the demo data
2. Adapt the tests to make them green, as some products are
renamed, removed, created in python instead of as demo data
...
Today, Odoo is really tricky to use without seeing the screen, it must be improved to be usable.
This PR forbid to use labels without a "for" attribute, add some title, rule and aria attributes in HTML. With that, Odoo will be fully usable with a screen reader.
* [IMP] Labels must have a for attribute. Improve accessibility.
* [IMP] Better error message when trying to read a missing cached value
* [FIX] Add some aria-label and title attributes for screen readers.
* [FIX] Template name is not included in the error message in case of SyntaxError in QWeb
* [FIX] Improve the Tour failed at step error message to be more explicit.
* [IMP] Add aria-labels
* [FIX] Add missing aria-label on failing test
* [IMP] aria-hidden means hidden. Fix all bad aria-hidden and hide aria-hidden for all.
* [IMP] Color names on kanban views and many2many tags
* [IMP] Add some checks on views for accessibility.
* [IMP] Add `alt` attribute on `img` tags.
* [IMP] Add aria-label and title on non-described icons
* [IMP] Add button role to widgets with btn class
* [IMP] Translate aria and formatted attributes.
* [IMP] Remove wrong aria-labelledby
* [IMP] Add menu role on dropdowns
* [IMP] Buttons must be focusable
* [IMP] Add aria attributes on progress bars
* [IMP] Improve accessibility of basic widgets
* [IMP] Change main layout to more semantic tags
* [IMP] Add menuitem role when missing
* [IMP] Remove wrong role='presentation'
* [IMP] Improve accessibility of tab panels
* [IMP] Add aria-invalid on invalid fields
* [IMP] Add aria-sort on ordered columns
* [IMP] Add role on alerts
* [IMP] Use dialog role, header, main and footer tags for modals
* [IMP] Add labels on o_status
* [IMP] Improve accessibility of kanban view with feeds and articles
* [IMP] Add alerts in case of new messages
* [IMP] Add widget, navigation or img role to aria-labelled items
Loads the barcode nomenclature only if one has been is defined. Indeed,
from commit 80e89c7a11, the POS config unset the
`barcode_nomenclature_id` field if the barcode support is not activated.
opw-1859928
On mobile, some barcodes didn't trigger in the picking screens, notably
O-BTN.validate. This is due to the use of parent() to check if the
button is in a dropdown, as parent() only checks one DOM-level upwards.
The button being inside a <ul><li>, we need to check more levels than
one to pass the condition and trigger the button press.
By changing parent() to parents(), the entire chain will be checked, not
just one level, and the button press is correctly triggered.
opw-1860964
closes#25941
If a barcode triggering an action on the pager was scanned while a pager
wasn't present in the page (see the workorder tablet view), a traceback
happened.
We display a warning instead.
Task: 1831245
This commit allows multiple button to share the same `barcode_trigger`
attribute. Note that it only makes sense if a single button is displayed
at a time.
Task: 1831245
(1) Before this commit, the input barcode was removed from the dom
after each scan but now we want to keep it focused to avoid to
automatically open the virtual keyboard in mobile.
This behavior will be useful in enterprise only.
Another commit will follow in this repository.
As the input is not removed anymore, we had to disable autocomplete
to hide previous entries as suggestions.
(2) We also add z-index property to avoid to click on the hidden input
located in the middle of the page.
Before this commit, it wasn't possible to use a barcode scanner
with the Odoo mobile app.
However it works fine for mobile Chrome browsers.
We now know that 'keypress' event doesn't work as expected in
Chrome for mobile. See @3a74afd21
It's why 'keydown' detection has been implemented.
We also want to use this detection in our Android app.
Unfortunately, 'window.chrome' doesn't seem to exist anymore
in the Android webview.
In this commit, we change the way Chrome is detected.
Before this commit, you were automatically redirected to the top of
the page when you scanned a product.
It was, therefore, difficult to find the product that had just been
scanned and to check its quantity.
Because of @3a74afd21 we need to put the focus in an invisible input
at the top of the page.
This input is now always vertically centered in the middle of the page.
The notification manager was removed and replaced by a notification
service. Some tests were forward ported after this change, so they need
to be updated to the new system.
The check on the event target and the barcode target is done outside
the check on barcode found. That result in a warning for each modal/form
view that is pending.
This commit do the check before doing any operations in order
to directly stop if the event target is not similiar to listening
barcode target
The barcode scanner and the quantity listener do not use
the same proccess although they act for the same operation.
(For example the quantity listener trigger onchange server side
while the barcode scanner not if 'notifychange' key on the
active_barcode is set to False)
Since quantity listener is based on candidate we could directly
call the _barcodeSelectedCandidate method in order to have a common
behavior and code.
Before this commit, the barcode value wasn't triggered on
some Android devices with Google Chrome and using the Odoo app.
In fact, the keypress event may not trigger with some devices.
This is probably due to the fact that this event is marked as
'Legacy'.
See: https://www.w3.org/TR/uievents/#legacy-keyboardevent-event-types
To fix this, we can use 'keydown' event but we have to handle an
other issue: there is no way to know which key is typed.
The auto-suggest feature on Android invalidate all the following
properties: Keycode, charCode, key, which, keyIdentifier, code.
This is a well-known issue:
https://bugs.chromium.org/p/chromium/issues/detail?id=118639
For more infos, please read this blog:
https://www.outsystems.com/blog/javascript-events-unmasked-how-to-create-input-mask-for-mobile.html
As a work around, we create a temporary input field that stores
the barcode value.
The focus is set on this input when a keydown is detected.
Note that when an input has the focus, the android virtual keyboard
will be opened. We can't avoid this behavior.
The only thing we can do is to automatically close it after 800 ms.
See: https://bugs.chromium.org/p/chromium/issues/detail?id=662386
As this fix is specific for Chrome only, it's not possible
to test it easily. Some tests will be added in master.
This fixes an issue occurring with Firefox.
Some events was buffered with an undefined value and it wasn't
possible to build the barcode value from these events.
See 'handle_buffered_keys' function.
So now, we simply skip this kind of event.
We consider this as 'special keys'.
Allow the user to set the quantity with barcode
scanning. This functionality was present in v9 but
didn't work in v11.
The code in order to make it work was already present in
_quantityListener however it makes a check on setQuantityWithKeypress
key on the obejct activeBarcode. Howver the key was never set during the
activeBarcode event.
This commit set the key on the activeBarcode if passed in the event data.
It also allow to trigger a barcode if the user is inside a modal.
In order to detect if a barcode scanner is being used, we detect the
delay between keypresses. The value is hardcoded to 55 ms. However, in
the case of a bluetooth scanner, this delay is often not enough,
resulting in an incorrect capture of the barcode.
We add the config parameter `barcode.max_time_between_keys_in_ms` which
allows the user to fine tune this delay for his hardware.
opw-806398
There is a subtle issue happening in tests when we override a widget
property for the duration of the test and try to restore the initial state at
the end by rewriting on the property. It actually changes the widget, by
having a function bound to the sub widget prototype instead of its ancestor.
This in turns can cause weird interactions with the class system.
We introduced a proper way to temporarily patch a class/widget by adding
a method in testUtils to do exactly that. This commit simply uses that
method to prevent unwanted interactions in barcode tests
related to rev 0d19ee989d
It was broken following the refactoring done in saas16, resulting in
barcodes being handled on all the displayed forms and it was problematic
in the case of a form dialog openned over a "fullscreen" form view.
This was particularily problematic for the scrap dialog in the
stock_barcode module.
Resetting the key 'test_barcode_handler' to its value before the
test was technically the best solution, as a test should leave the
environment unchanged. However, in this case, the widget is
undefined (there is obviously no 'test_barcode_handler').
Whereas this should not be a problem (the fields in the registry
are supposed to be accessed using get(), and the presence of a
key mapping undefined is equivalent to the absence of the key in
this case), this breaks a test in Studio if the latter one is
executed after the barcode test. This is because Studio browses the
map of the field registry to access each field's prototype. When it
encounters an undefined value, it crashes.
This was the case about 15minutes ago. But before pushing we
decided to change the Barcode override of FormController to
directly use handlers of the FormController when it could (e.g.
to handle 'Edit', 'Discard' actions). This wasn't a good idea as
those handlers don't return anything, and the barcode mechanism
requires its handlers to return a deferred. So basically, it
crashed when such a barcode was scanned. Having a test suite is
nice, but you should not forget to relaunch it before pushing...
The barcode mechanism is supposed to handle commands PAGER-FIRST
(go to first record referenced in the pager) and PAGER-LAST (go
to last record). Before this rev., it wasn't the case.
We needed to add an option 'notifyChange' to the updateState
function of the pager, to ensure that the form is correctly
reloaded when the pager cursor is manually set (by the barcode
handler) on the first or last element.
The barcode mechanism is optimized to (in certain conditions),
directly increment the quantity of a numerical field inside an
x2many, without performing any RPC, and then re-rendering the
x2many to display the new value.
Before this rev., it seemed to work fine, but when the view was
saved, those changes of quantity were lost. This was because the
changes weren't correctly notified to the model (the quantity
field being inside an x2many, the correct update command for the
x2many should be generated).
When a barcode field with widget="barcode_handler" is in a form
view, an onchange RPC should be done each time a barcode is
scanned.
Before this rev., it worked by chance because the views using it
don't define a 'pack_operation_product_ids' field.
Anyway, this widget is meant to be generic, so it shouldn't
hardcode a fieldname.
Before this rev. a warning was displayed when a barcode mapping an
invisible button was scanned. It shouldn't, for the following
reason. In the stock.picking form view, two buttons with
barcode_trigger='validate' are in the page ('Start Inventory' and
'Validate'), and there is always at least one of them that is
invisible. So when scanning the 'validate' barcode, we don't want
a warning to be displayed, as there is potentially another button
that is able to handle the request.
When scanning a command barcode, the view shouldn't be redrawn
after the operation corresponding to the command is executed,
for two reasons: first, it is useless as the view has already
been reloaded, and second, it may cause issues if it has been
destroyed meanwhile.
For example, when scanning barcode O-CMD.MAIN-MENU from a
picking form view: a do_action is performed to go back to the
main barcode client action (so the current form view is destroyed),
but an handler tried to redrawn the destroyed form view, which
produced a crash because the session was required by Date fields,
and it couldn't be provided (there were no more parent listening
to provide it).
When a keypress event is triggered in a 'field_float_scannable'
widget, the event is first catched by the barcodes mechanism, and
then manually re-triggered. However, the way it was done implied
that the environment was notified of each keypress event, so if
there was an onchange on that particular field, an onchange RPC
was done at each keypress.
Moreover, the focus was lost at each keypress as well.
This option has been removed with the new views but was used in barcode.
The form renderer was also dealing with some part of the autofocus
but this should only be handled by the controller.
The logic is now only in the controller and a test case has been added.
Since the new views, most of the barcodes feature was
broken. This commit re-enables the support of commands like
'edit', 'save', 'cancel', 'previous' and 'next'.
Also changed javascript event handler to jquery event handler to
make barcodes testable in phantomjs.
* web_editor, web_planner, website
The 'Dialog' class is used in both backend and frontend. Also, lots of
actions can be done without the use of any modal. It thus makes sense
to lazy load its related xml only when a first modal is opened.
This change also allows to get rid of the "base_common.xml" file as the
dialog template is the only remaining one in there and, in the future
website update, it will allow to not load any static XML file on website
page loadings.
Simon Lejeune