Let arrow keys, tab and escape pass through. We still want users to be
able to use eg. arrow keys to be used when selecting a radio item. This
will always work in Chrom{e,ium} because they do not dispatch keypress
events for these types of keys, only keydown/keyup events. Firefox does
dispatch keypress events. This makes sure that we do not touch those
types of events in Firefox.
devices have to fire keypresses every 50ms minimum
Previously this was 100ms. This works just as well, but was mainly in
there for testing purposes.
Before this, users were only able to press a key when all other keys
were released to prevent a key from repeating. This works but when
typing you usually press the next key before releasing the current
one. This allows users to do exactly that while still blocking keys from
repeating.
Implement a new way of dealing with barcode events. This was necessary
because the old way of dealing with input coming from barcode devices
did not stop keyevents. This lead to all kinds of issues (eg. barcode
reader output being inserted as tender in a paymentline).
This new class inserts itself so that it handles all keyevents before
everything else. This means that it has authority on what keypress
events pass and which ones do not. It differentiates between 'real'
keyboard input and input coming from devices by buffering events. When a
certain amount of events come in fast enough, it is handled as a barcode
and a 'barcode_scanned' event is emitted on core.bus. When buffered
events are decided to not be a barcode, they are recreated and
redispatched.
The name of an event is the name a created record will get.
If the event name of a new event is left empty, the edited record will
also be empty which could be less user friendly.
closes#6896fixes#6869
opw-640921
This reverts commit e18a3a43e4.
website.error is used in the Javascript file it was removed from,
in website.js, line 350.
Another solution to not load this template when not needed has
to be found
opw-640822
Previously, all existing event.mail schedulers were
auto-triggered at each registration, which could
make the behavior unpredictable/surprising,
including during the tests. Only trigger `after-sub`
event.mail schedulers, as only those are related
to a new registration.
Tests fixed to take into account this new behavior.
The sale.order.line on_change returns related field
values that are not meant to be written on the line.
Removing them from the `values-to-be-written` avoids
the useless write() on product.product and the locking
problems that come with it under high concurrency
environments.
* add on_change_uom behaviour to quote templates lines
* fixes frontend layout issues
* use action_button_confirm instead of signal_workflow
when confirming the quote in the frontend to trigger
all events properly
* adapt prices using pricelist on onchange_template_id
on sale orders
When splitting landed costs against the picking line, the decimal
precision was not taken into account.
For example: with a landed cost of 5.01 split equally over two lines,
the cost for each line is 2.505 which is rounded to 2.51 with a decimal
precision of the fractional part of 2. Hence the total was wrongly of
5.02 (which is an issue when wanted to validate the landed costs).
With this commit, the split landed costs are restrained to stay under
the whole landed cost price.
closes#6882fixes#5568
opw-639503
Javascript regex \b is not unicode aware,
and words beginning or ending by accents won't match \b
We therefore use a custom regex to replace \b.
Basically, it's a regex matching all words separators
such as dot, comma, spaces, etc. and other unicode
separators as well.
opw-641005
Rebasing a merge commit with a lot of conflicts is a real pain as every
non-automatic conflicts should be redo manually (especially when there
is a lot of file rename that git cannot follow)
- Automatic bank reconciliation: failure to acknowledge that x * -1 == -x
- Interface: hide the 'partial reconciliation' sign when matching a transaction with an already registered payment
When creating an incoming shipment to be invoiced with as source location
"Transit"
and as destination location
"Stock"
Clicking on create invoice leaded to a crash.
opw-639536
We force the user to select only one picking at a time. The reason is that we
can choose the number of products to return for every picking, so it does not
make sense to group the returns in one picking.
opw-640030
So far, we do not support the following combination:
- route set on 'dropship'
- PO invoicing set on 'picking'
- SO invoicing set on 'picking'
opw-634898
Joren Van Onder