- transform odoo.py -> odoo-bin / recent branches + pip3 packages
- deactivate wpa_supplicant when starting dhcpcd automatically
- postgresql create clusters manually
- latest stretch raspbian image / add versatile-db.ptb for kernel-qemu
- ifconfig output change
- upgrade hw_-modules:
hw_escpos: to python3
hw_posbox_homepage: to v11: csrf does not work as it needs a database
hw_posbox_upgrade: to python3 decode utf-8
hw_scale: to python3
hw_proxy: to python3
With the commit, the posbox will also work on the new Raspberry Pi 3b+
``import odoo.addons.foo as bar`` doesn't seem to properly trigger the
import hook in Python 3 (it blows up on decimal_precision and
base). Thus convert *all* examples of that pattern to the more
sensible ``from odoo.addons import foo as bar``.
This commit fixes the driver to respect the new device
registration mechanism via hw_proxy.rs232_devices.
It also refactors the code to more easily support multiple
scale protocols, and introduces support for the ADAM Equipment
AZExtra scale protocol. (Might be compatible with other ADAM
Equipment scales)
Support for th AZExtra scale is experimental at the moment,
especially given two annoying problems with this model:
- they do not support proper probing (stays mute until a
non-zero weight is measured), so they have to be probed
last and *assumed* to work
- the scale beeps when a read attempt is made and the
weight is not stable yet, or the weight has been already
read previously. This constant beeping during operation
is mitigated by extra delays between readings, but might
still prove to be a major issue for supporting this scale.
I'm not sure why the serial timeout is so aggressive, but I assume there
is a reason for it. During probing however, we shouldn't use such an
aggressive timeout because if we miss the device during initial startup
we'll never find it since we only probe devices once.
After plugging in multiple identical serial to USB interfaces, only the
last one will be available under /dev/serial/by-id/ because they'll have
identical IDs. Instead use /dev/serial/by-path/ which does not have this
issue.
We support the Mettler Toledo scales which have their own built-in USB
to serial interface. Due to continuing issues with that built-in
interface we will also support the scale configured in raw RS-232 mode
which seems to be more reliable.
This means that in order to connect the scale you'll need a third party
USB to serial interface (unless you have built-in serial interfaces, but
the POSBox doesn't).
The main difficulty this poses is that using this approach we cannot use
the name of the interface to find the device. When using the built-in
interface of the scale the interface would identify with an ID
containing 'mettler' and 'toledo'. When using a third party interface
the ID will instead contain information about the third party
interface. To fix this we use a probe-based approach, probing every
available serial interface until we find one that returns a response to
our probe. This approach will work with both third party interfaces and
the built-in interface of the scale.
Contrary to probe-based approach used in hw_blackbox_be this one is
slightly more complicated because hw_scale is written in such a way that
it is 'plug and play', which means that as long as the module is running
it will continually try to find a scale. This is fine, but we don't want
to keep sending probes to eg. Fiscal Data Modules, which could lead to
issues. Therefore we will only probe every device once. When we lose an
existing, confirmed connection to a scale we will however keep retrying
to connect to that particular device.
This commit contains the patches from the now obsolete 'posbox'
branch. These patches were written by Martin Donies (@mdo-odoo) and
Frédéric Van der Essen (@fvdsn).
Prevents installing the hw_* modules at all when the python
dependencies are missing. If they were already installed
do not start the hardware threads to avoid wasting resources
and logging errors
Unify and refactor exception handling in framework and addons.
The generic `except_osv` is now deprecated, and replaced by more specialized exception subtypes:
- `UserError` (renamed from Warning, as it conflicts with the built-in `Warning`) raised when a non-technical error occurs during a business operation. It could be a missing information in the data provided by the user, or a misconfiguration.
- `AccessError`: raised when any operation is denied because the user conducting it does not have the required access rights.
- `AccessDenied`: raised when an operation that requires authenticated access is attempted via an unauthenticated request.
- `MissingError`: raised when an operation is attempted on a record that does not exist.
- `ValidationError`: raised when an operation violates a SQL or Python constraint.
- All other exceptions are internal errors due to a system problem or bug, and raised untouched to the client-side, which should display a traceback.
All exceptions take a single message argument.
The `test_exceptions` module has been updated to showcase both new and old (deprecated) exceptions.
A great many old `except_osv` had a useless title with "Error!" or "Warning", those have been removed, as this is handled by the client-side widget that displays the messages.
This commit introduces a more consistent policy for logging errors and warnings:
- All messages that do not require administrator attention should be logged at INFO level or lower. This includes all errors that are notified to the user in a friendly manner, even for access right problems or validation errors during business operations.
- All messages that indicate a likely misconfiguration or malicious use by the users should be logged at WARNING level, as they typically require administrator attention.
- All other unhandled internal errors cannot typically be handled by the user and should be logged at ERROR or higher level, as they require immediate administrator attention.
Rebranding has been done in:
- data/demo files
- html templates
- help notices
- comments
- logger messages
- and other various messages
(Commit taken from odoo-dev:8.0-improve-openerp-odoo-rlu at rev 7deaa08)
Closes#1260
Josse Colpaert