The quantity event handler is not correctly unbound when its action
is deleted, resulting in multiple window.prompt asking the quantity
of the products if you go mulitple times trough a view when a widget
implementing the barcode thing is used.
There seems to be a bug in the framework ("barcode_scanned" events
are registered the same way than the "keypress" one on core.bus
but they don't have suffer from the same issue).
It's possible to trigger click on form view's button with the help
of the "barcode_trigger" attributes. However, we don't want to be
able to execute clicks on items that aren't clickable by the user.
That's why we wrote the following condition: if the elem is visible
OR is a child of a .dropdown-menu, we trigger the click.
The second condition was always true since we used the jquery's
parent function which return an empty list when no result, and
an empty list is truthy.
Return key events don't get redispatched and even if they did, it
wouldn't work because 'fake' keypress events don't trigger native HTML
event handlers.
This should be safe because Return cannot start a valid barcode.
In some cases, several barcode widgets can be found on the same page.
This is for example the case of the stock picking: there is a widget on
the `stock.picking` model (main view) itself, and a widget on the
`stock.pack.operation` model (modal view).
In this case, when the focus is not set directly on the field which
needs to be filled in, both widgets will trigger a `barcode_scanned`
scanned event. This will call the `on_barcode_scanned` Python method
which can lead to errors/warning. For example, the `on_barcode_scanned`
method on the `stock.picking` model raises a warning in case the barcode
scanned does not match any product/package.
The fix is to make sure that the event target is located in the correct
DOM element.
opw-677506
On smaller screens some buttons will be hidden. An example of this is
the 'Validate' button in the stock.picking form view. It is not :visible
but it should still be possible to trigger through scanning a
'O-BTN.validate' barcode.
opw-676741
Introduced by 5bb64d40d0. Before doing
anything we should first ensure that the quantity keypress event targets
body (and that it is a number, but that's less important). Before this
we didn't do that and thus the _display_no_edit_mode_warning was given
when people where just typing in the associated thread of a picking.
opw-672350
When scanning items with a device like the Symbol MC3200 you are
presented with the Kanban view because of it's limited resolution.
In this view it is not possible to quickly set the quantity of scanned
products. Ideally users just want to scan the barcode, input the
quantity and repeat without having to click on virtual buttons on the
usually less than ideal touchscreen.
This implements a way for users to immediately start typing numbers
representing a quantity after scanning a barcode. The quantity will be
set on the specified m2x_field.quantity_field of the record associated
to the last scanned barcode. Because KanbanRecords are not editable
without opening a new view window.prompt is used. It will create an easy
to use native dialog of whatever device is being used. It also avoids us
having to implement a custom input field which would have to handle
keypress events like numbers, backspace, delete, etc.
We want to properly support devices like the Symbol MC3200. This is a
handheld computer running a modern operating system like Android or
Windows with an integrated barcode scanner. After installation of a
modern web browser and configuration of the integrated barcode scanner
Odoo works as well as it does anywhere else.
The main issue with these types of devices is that the displays (and
their resolution) are very small (3" @ 320x320 for Symbol
MC3200). Because of this a lot of tree views become awkward to use
because they require vertical scrolling. A Kanban view however scales
nicely on these displays.
This implements Kanban views for both the picking.form view and the
stock.inventory form view because those are the views typically used
when using a barcode scanner.
Doing this alone is not enough, because the barcodes module does not
work with Kanban views. Small changes where made to
barcodes.FormViewBarcodeHandler to make it work with both List views and
Kanban views.
Since the method must return a deferred, resolve it with true to proceed with onchange
and with false to prevent the onchange. Deferred failure is not an option.
Barcodes are detected by catching keypresses. When a keypress is not
part of a barcode, it is 'released' by forging a keypress event.
For security reasons, a non-native keypress doesn't trigger the native
input mechanism. So in order to make both barcode-scanning and manual
keypresses work in a field, it is necessary to have a handler listen
to the 'false' keypresses and simulate the native input behaviour.
For a model to use it, it must :
- Inherit barcodes.barcode_events_mixin and override on_barcode_scanned(self, barcode)
- Add <field name=barcode_scanned widget=barcode_handler/> to each form view that
should listen to barcode events and trigger on_barcode_scanned.
The method on_barcode_scanned works just like an onchange.
This avoids breaking shortcuts on Firefox, which rely on keypress
events instead of keydown / keyup. The tradeoff is that a barcode
cannot be scanned and interpreted if ctrl, alt or cmd is pressed.
Also don't catch function keys.
BarcodeEvents uses the fact that a barcode usually ends with \n, \r or
\t - and never contains it - to stop buffing keys as soon as such a
character is inputted instead of waiting x milliseconds.
This functionality was an attemps to fix the chair-to-keyboard
interface in the PoS. Since it is not a standard behaviour, it
must be explicitly requested.
In order to remove an eventhandler, removeEventListener must receive
the same function reference that was passed to addEventListener. So
the handlers references are kept as attributes of the class.
If the module barcodes is installed, a BarcodeEvents singleton is
automatically instanciated. It listens to keypresses and, when a
sequence of keys represents a barcode, it broadcasts a 'barcode_scanned'
event on core.bus containing the barcode string.
The module system needs to know the dependencies of a given module
before executing the function. This is why the dependencies were
defined once in an array, and then were described one more times in the
call to require.
But a trick can simplify this: the boot function can parse the string
representation of the module and extract the calls to require from it.
It is more work for the processor, but it leads to simpler module
definitions.
- Added support for UPC-A Barcodes
- Add a way to automatically convert UPC-A to and from EAN13. This
is usefull if you wish to standardise your product barcode encoding
in one standard but have a mix of the two in your merchandise.
- Various bugfixes.
Christophe Simonis