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.
Before this commit, the JS parser would add 0 after the input, then add the ean key.
Whereas reportlab.graphics.barcode fills the input with 0's on the left, then add the key
http://pydoc.net/Python/reportlab/2.5/reportlab.graphics.barcode.eanbc/
At: Ean13BarcodeWidget.__init__()
This commit makes the ean parser coherent with the lib the python uses
Simon Lejeune