To be displayed correctly on odoo app (In a given category and not only in all or hidden)
the module category in the __openerp__.py file should be one of these:
"Accounting",
"Discuss",
"Document Management",
"eCommerce",
"Human Resources",
"Industries",
"Localization",
"Manufacturing",
"Marketing",
"Point of Sale",
"Productivity",
"Project",
"Purchases",
"Sales",
"Warehouse",
"Website",
"Extra Tools",
'Accounting & Finance' will not work, as 'Project Management', ...
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.
Now that most refactoring has been merged
It is better to have red a great work of another culture in translation than never to have read it at all.
― Henry Gratton Doyle
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).
- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
automatically in all countries thanks to Berne Convention + WTO rules,
and a reference to the applicable license is clear enough.
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
Christophe Simonis