In the new version of the iot we import a new "crypt" library which is not available for windows
Addition of the class in the input of the password
closesodoo/odoo#128467
X-original-commit: f84bbfac2de786bf73e1fbe6d3b77452e17ac4bb
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
With this update the version of python goes to 3.9.2
In addition, a unique password system has been put in place
closesodoo/odoo#127975
X-original-commit: a0feb285ff2ff4a9b82f87ff5abefb307847f25a
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
*: hw_drivers
Improvements:
- Makes the display responsive to practically never have a horizontal scrollbar.
- Automatically reconnect to the customer display popup if it's still open from a previous session, allowing the user to keep it open between sessions.
- Adds a view when no order is selected (in the restaurant POS UI, when the user is in the floors and tables view for example), which is also opened before leaving the POS UI (closing session or clicking on the Backend button).
- Adds an empty order title as the one displayed in the backend when there is no product.
- Improves the display of payment lines to take benefit of all the available free space.
- Shows customer notes and discount in the customer display.
- Adds order line unit next to or under the quantity (so as not to lose horizontal space).
- Adds a footer dedicated to the Odoo logo, always visible.
- Adds an optional user-customizable background image displayed either on the right side of the customer display if it is in landscape orientation, or in the top header of the portrait orientation.
- Adds a title bar "Your Order".
- Removes the "Customer Screen" label in the POS session UI and moves the status message of this screen to a notification and the title of the button.
Fixes the local display of customer display for restaurants when the "Customer Screen" button is clicked from the main view (floor with tables) and not from the view of a table order.
Removes .pos-adv and .pos-js_no_ADV css properties that no longer seem to be used.
Thanks to Xavier (xlu) for the design ideas and mockups.
task-id: 2906039
Closes#106907closesodoo/odoo#118721
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
When we send a report to the iot_w we use Ghostscript to print it. But if it is a ZPL report it crash.
So we need valid if the report sended is a PDF before print it
However if it is a different format, like ZPL, we use print_raw to send directly to the printer
closesodoo/odoo#124146
X-original-commit: a4c315ab657109f2ed69745207cd99ea978889b8
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Currently, if a problem occurs during the loading of iot handlers
(drivers or interfaces), all loading of iot handlers is compromised.
With this FIX we display the Exception and the file concerned without
blocking the operation of the iot
closesodoo/odoo#118557
X-original-commit: 3b717b0d66ea2656e5058ab3df0b068fae8b08c8
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Before this commit:
Assuming we have a "Shipping Labels Printer" set on an operation type.
Assuming we also have a delivery carrier which send Label through the chatter of this picking type (like DHL or BPost).
If we have several sessions connected with the same user (author of the chatter message), for examples, on different devices.
Each session will send the same IoT request to print the label (as the code rely on the bus).
In consequences, the same label will be printed multiple times
After this commit:
The label is print only once
Associated enterprise PR: https://github.com/odoo/enterprise/pull/36904
opw-3081423
closesodoo/odoo#117251
X-original-commit: 8ca27ae07b0a7b3bf27ac5459d74f28bbcc89ce0
Related: odoo/enterprise#39087
Signed-off-by: Sens Loan (lse) <lse@odoo.com>
HTTPS certificate IoT issues can be complicated to troubleshoot
as the information are not visible/given.
This PR aim to share this information on the IoT box homepage.
As there is a lot of possible causes for a given problem,
a code is used that will be explained/detailed in Odoo's
IoT documentation:
https://github.com/odoo/documentation/pull/3818
OPW-3227004
closesodoo/odoo#116650
X-original-commit: 8bc6b2d0033676507f95b74b3ae383ab17164203
Signed-off-by: Loan (LSE) <lse@odoo.com>
Signed-off-by: Sens Loan (lse) <lse@odoo.com>
Currently we verify the SSL certificate of the iot after starting the nginx web server.
So for the Windows iot if a new certificate is downloaded it will only be loaded by nginx
on the next restart of the iot because the process that runs nginx is a child of the one that runs the iot
With this commit we restart the windows iot if a new certificate is uploaded
closesodoo/odoo#112945
X-original-commit: 880afb3006ece93ee6575c977233bfb61081bf3a
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
This commit adds "download_from_url" and "unzip_file" functions to
helpers.py
These allow to downloaad files and unzip them from Python and let us
remove the bash scripts we were previously using for the same purpose.
More specifically this allows the same code to be used on Linux and
Windows IoT to download and unzip files
closesodoo/odoo#112942
X-original-commit: 01aad66d5bde13ced704dfc5226f271da185887a
Related: odoo/enterprise#37205
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
The command delay on writing to the device is a little too prolonged.
After some testing it has been determined that this can be reduced to
by reading with the serial.read function (rather than read_all) when
we know the expected output length.
The serial read fuction accepts an integer describing how many bytes are
expected in the read buffer, and returns when the buffer is filled.
This has much better performance than waiting a fixed length of time,
and reduces the chance of getting an empty response (when the device
takes longer than expected to process the previous command).
The request sent when trying to abort was incorrect, the length byte was
too large by a value of 2. It has been corrected to be the length of the
message
i.e. LEN = 0x20 + len(<LEN><NUM><CMD>) = 32 + 3 = 35
where num is the serial message number
The error message for aborting the post was incorrect, stating the the
invoice had been cancelled when it was not successfully cancelled, and
vice versa. Loggers have also been added for the cancelling of the
invoice.
closesodoo/odoo#108629
X-original-commit: aaa0bbde8251e08feeb180fb14543ede7d05afa6
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
This module implements communication with the fiscal device for
submitting invoices to the KRA (Kenya Revenue Authority). The device
supported in this module is the Tremol G03.
-- COMMUNICATION FLOW SUMMARY --
1. "Send Invoice To Device" on account move is clicked
2. l10n_ke_action_cu_post triggers a client action, with serialised
invoice data. (more details below)
3. The client action uses the 'post_send' function defined in javascript
to forward the request to the /hw_proxy/l10n_ke_cu_send endpoint on
the proxy server (more details below)
4. The proxy server wraps the serialised data with the appropriate bytes
(for instance, a couple of a checksum bytes), and sends them to the
device through serial communication (more details below)
5. The data returned from the fiscal device is communicated back in the
request. The client action 'post_send' then triggers the
'l10n_ke_cu_response' with an rpc call, with the aforementioned data
from the fiscal device
(more details)
2. The module l10n_ke_edi_tremol inherits from the account_move model in
order to provide methods for serialising the data of the account_move
and sending it to the proxy server. Fields have been added to the
product template to define the HS Code and HS Name (data which is
required by the KRA in some circumstances). A field has also been added
to the company defining the address of the proxy server. The fields
added on the account move are populated by the data returned by the
fiscal device, this includes the device serial number, the invoice
number on the device, the URL of the invoice on the KRA web portal, and
the date/time the invoice was signed.
3. Communication between the client database and the proxy server is
defined using a client action defined in
l10n_ke_edi_tremol/static/src/js/send_invoice.js. This allows users who
aren't on-premise to communicate with the device, provided the proxy is
accessible on the network that the user is on.
4. The proxy server is an intermediary server that should be connected
to the tremol G03, and running the IOT drivers from hw_drivers. The
driver that supports communication between the proxy server and the
fiscal device has been defined in this commit inside of
hw_drivers/iot_handlers/drivers//L10nKeEDISerialDriver.py.
The proxy server can be run on the IOT box, or on odoo community by
running:
./odoo-bin addons-path=.... -d dbname --load hw_drivers --proxy-mode
** all messages are encoded/decoded with cp1251, as defined in the
protocol. The company vat code is sent along with the request to compare
that sent with that of the device. The 'serial_number' of the device is
always returned along with the request, since it is required for the
invoice details, and it is retrieved as part of the query to find the
registered VAT code on the device.
--- DATA and VIEWS ---
product_view:
adds HS Name, and HS Code on the product product and product template
form views.
report_invoice:
adds to the invoice qweb template such that a section including the
fiscal device / KRA details is included at the bottom of the invoice
when the invoice is rendered as a pdf.
res_config_settings_view:
adds makes the proxy address field editable from the config settings.
account_move_view:
add a tab for the tremol device details and the qr code on the account
move form view. The KRA invoice number is also added as an optional
field on the account move tree view, and the invoice search view is
inherited to make this field searchable too.
(l10n_ke) account_tax_report_data, account_tax_template_data:
The tax report is defined for Kenya, and tax tags that link to the lines
on this tax report are defined on the existing taxes. This allows the
classification of the tax, between zero-rated and exempt, during the
serialisation.
closesodoo/odoo#106654
Task-id: 2950308
X-original-commit: b0be9e074a1ecf1f6de7a03c71df0c63868501e3
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
From the commit 2ab231bd7af609a751ed8168cc094dfeb1012eda
We introduce a error in the path to read Linux file
In this commit we correct the access to the file
which is in the "home" of the raspberry
closesodoo/odoo#107779
X-original-commit: e427d0a2147896aa4311488ebc13f45b84cb330c
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Currently it is only possible to run the modules
for the IoT Box on Raspios.
The modifications brought by this commit brings the possibility
that the various hw_* modules can be executed whatever the OS
of the hardware (Linux or Windows).
If the modules should be versioned according to the OS,
the file will be renamed so that the end of
the file includes *_L (for linux) or *_W (for windows)
closesodoo/odoo#107350
X-original-commit: b7b8809ea8b7fe4ac8b24f43fe3f3a5e38a66696
Related: odoo/enterprise#34713
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
This commit aims to solve the reported issue where printers are switching states from "connected" to "disconnected" and stay unreachable for 2 minutes. Now theavailable printers will be searched for multiple times before disconnecting them
task 2891909
Fixes 2687380
Fixes 2856101
closesodoo/odoo#106180
X-original-commit: ac0ca14c349e0d70d9f3a1aeb720f5e31f16d63e
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Actually it is not possible to add manually a printer.
With this commit we loop into all printer recorded in cups to
check if a printer is not automatically added.
If a printer does not match with a identifier automaticcaly generated,
it is added to the list of usable printer.
closesodoo/odoo#95709
X-original-commit: de03cbefd537503cd46cbecf1622bd2a547b4615
Signed-off-by: Masereel Pierre <pim@odoo.com>
Some modules used Bootstrap minified bundle but this was replaced
in [1] to avoid using of minified files.
We now want to have the same way to import bootstrap by using non-minified
individually compiled Bootstrap files (bootstrap/js/dist/).
Note that in 'hw_drivers', the js and css part was imported at the
same time but the javascript seems never used...
REF:
[1] https://github.com/odoo/odoo/pull/95450
Part-of: odoo/odoo#95628
* = base,http_routing,hw_drivers
- Update Bootstrap from 4.3.1 to 5.1.3
- Update PopperJS to version 2 for Bootstrap 5 (JS part)
Some code was for PopperJS V1, but it's not compatible anymore.
- Remove some BS5 classes utilities backport
- Fix path for BS5
Task ID: 2766483
Part-of: odoo/odoo#95450
To reproduce:
Synchronise an IoT-box with a device with `\x00` characters in its name
=> ERROR: bad query: UPDATE "iot_device" SET "name"=%s WHERE id IN %s
ERROR: A string literal cannot contain NUL (0x00) characters.
Note that this is pretty rare to have this characters in devices names. But it looks to happen with some Chinese devices like the "TaoTronics 2-in-1 Bluetooth & Wired Barcode Scanner USB Portable Bar Code Scanner"
OPW-2748580
closesodoo/odoo#90018
X-original-commit: 5a94d445f1183f256d7847b332b86c81bb711854
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
From the last refactoring #78857 it was no longer possible to run the odoo server on an iot
With this commit we change the override of the db_list function
And and reload the driver controllers
closesodoo/odoo#86665
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
This commit is the 14th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
* `request.uid = x` => `request.update_env(user=x)`.
* `request.context = x` => `request.update_env(context=x)`.
* `request.context = dict(request.context, x=y)`
=> `request.update_context(x=y)`.
* `request.cr = None` => `request.cr.close()`.
* `http.mono_db()` => `request.db`.
* `http.dispatch_rpc()` => `service.dispatch_rpc()`.
* `@service.model.check` => `service.model.retrying()`.
* `request.endpoint`
=> `env['ir.http']._match(request.httprequest.path)[0].endpoint`.
* `request.routing_iteration `=> `removed`.
* `request.jsonrequest` => `request.dispatcher.jsonrequest`.
Note that `request.params` is now set much later in the process. If you
are in a situation where you values from the query string or the
http body you can use `request.get_http_params()`.
Note that using the new `request.future_response`, it is possible to
add headers and cookies on the response object before the response
object is initialized. Please note that headers/cookies saved on
the future response will NOT be injected in case of error.
PR: odoo#78857
Task: 2571224
This commit "forks" fontAwesome into `src/libs` in order to allow
further customization.
Part of v16 overall restyle (task-2704984).
task-2745275
Part-of: odoo/odoo#83501
The http.addons_manifest is a map {module: manifest_dict} that is
populated upon the first http request. This map is basically a module
manifest cache with an extra `addons_path` key, the path of the module
on the file-system. This cache is eagerly populated upon the first http
request, the map is empty in non-http contextes (e.g. cron) which have
been a source of bugs (e.g. 50c8eb1).
A manifest cache is necessary because reading and parsing python files
from the file-system is not that cheap but there is no reason that cache
is located in `odoo.http`. A thin cache layer now wraps
`load_information_from_description_file()`/`load_manifest()` and is
lazily populated.
The `http.addons_manifest` have been removed. The extra `addons_path`
key is now present in the "normal" manifest. The `read_manifest()` was
hardly used so it has been deprecated. The only way to retrieve a
manifest is now `load_information_from_description_file()` which was
renamed `load_manifest()` (no cache) and `get_manifest()` (cache).
Side note about performances, the cache is necessary. Addons manifest
are read-only and reading + parsing python files from the file system is
not a cheap operation. Running the e-commerce tour
`@website_sale.test_04_admin_website_sale_tour` without cache on
`load_manifest()` requires 68,29 secs to complete on my laptop,
exceeding the default 1-minute time frame allowed in tests. Using a
cache the time is down to 36,53 secs. The performance impact is huge.
Part-of: odoo/odoo#79977
In the new version of Odoo and in the drivers we "map" the actions.
The "mapped" functions must take at least 2 variables as parameters; Self and Data
closesodoo/odoo#78912
X-original-commit: 86653d2024075129c3f52390abdce0abb8d8ec31
Signed-off-by: Masereel Pierre <pim@odoo.com>
If you unplug the iot box and wait 15 seconds or so, and then plug it
back in, it's possible to get an exception from helpers.get_ip, because
neither the wired nor the wireless interface has an IP. In that case,
the exception would kill the Manager thread, since it was uncaught.
This fix adds a catch-all to the Manager thread that logs any uncaught
exceptions and continues its main loop.
closesodoo/odoo#77111
X-original-commit: a9808a4efe46c4ba7948f5d6a8757546c6b4147b
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Signed-off-by: Raf Geens <raf-odoo@users.noreply.github.com>
get_ip and get_mac_address respectively try to get the IP and MAC from
the IoT box's active network interface. If the interface isn't fully up
yet (due to waiting on a slow DHCP server response for example), both
functions can end up raising a KeyError exception since neither
interface has a value.
This can be bad if it's uncaught and happens in something like the
Manager thread, potentially killing it as a result. This can then
disrupt the rest of the application. The network being gone for a bit or
slow is something that can happen during everyday use, so we should be
robust against it.
Since the box can't do any useful work without an active network
connection, this fix keeps retrying until one of the interfaces comes
back up.
opw-2357144
closesodoo/odoo#77052
X-original-commit: d0359858b17fb84c04c267bdf5cc1626569f5cce
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
We call the status of the hostapd in each request of 'get_odoo_server_url()' and 'get_ssid()'
And this call display in the log the status '0' or 'inactive' in the log
With this commit we hide this useless information
closesodoo/odoo#72133
X-original-commit: e5e9f9f91cf9bf35f1e0b307008840a0de134e2f
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Currently, none of the classes derived from Interface use `super`. If
it's added, for example by adding this to `SocketInterface`:
```
def __init__(self):
super().__init__()
```
, a deprecation warning will appear in Python 3.6 and 3.7:
```
2021-04-30 13:14:25,000 24736 WARNING ? py.warnings: /home/pi/odoo/addons/hw_drivers/iot_handlers/interfaces/SocketInterface.py:11: DeprecationWarning: class not set defining 'SocketInterface' as <class 'SocketInterface.py.SocketInterface'>. Was classcell propagated to type.new?
class SocketInterface(Interface):
```
In Python 3.8 this is no longer a warning and becomes a `RuntimeError`.
The reason this happens is that `InterfaceMetaClass` caches the results
of the `__new__` calls it does in `interfaces`. CPython's data model
specifies that when calling `__new__`, the cell for `__class__` needs to
be passed along to the parent class: https://docs.python.org/3/reference/datamodel.html#creating-the-class-object .
See https://docs.python.org/3/c-api/cell.html for a definition of what
a cell is.
Because of the caching, this doesn't happen when `__new__` is called
multiple times for the same class. In the case of the `SocketInterface`
example, `__new__` is called twice: first when it's imported directly by
`load_iot_handlers` (https://github.com/odoo/odoo/blob/841c016913a87133bf7257c62ae5f6bf7d99e06d/addons/hw_drivers/main.py#L81)
and second when `IngenicoDriver` imports it. The `__class__` cell is
different each time in that case. With the caching present, this means
the second cell isn't propagated correctly, resulting in the warning /
error.
After `load_iot_handlers` has finished, the `Manager`'s `run` method
iterates over `interfaces`, instantiating and starting the loaded
classes. Because of this, simply removing the caching appears to be
sufficient to avoid the issue while keeping the end result the same.
This issue was encountered while forward-porting a V13 PR, which adds a
`super` use to `SocketInterface`. The issue didn't occur in V13, because
the metaclass doesn't have a cache there.
I found a second problem resulting from the caching. I had noticed that
the `socket_devices` dict the `IngenicoDriver` had access to did not
have the same contents as the one the `SocketInterface` was operating
on. This means that whenever you called the `disconnect` function on the
`IngenicoDriver`, which deletes its entry from `socket_devices`, it will
always fail. The bluetooth driver seems to be impacted by the same.
It turns out the reason for that is how downloaded modules get loaded in
`load_iot_handlers`. That logic (using `exec_module`) doesn't actually
import the module, it just executes the code (registering the interfaces
and drivers as a side-effect). This means the module doesn't get cached
in sys.modules. That means that when another module (`IngenicoDriver`)
imports that same module (`SocketInterface`), Python will execute the
entire contents again, in this case effectively replacing socket_devices
with a new dict, which `IngenicoDriver` gets a reference to, while the
`SocketInterface` thread that runs is still using the old reference to
the original dict. Meaning the two are out of sync. See
https://docs.python.org/3/reference/import.html#the-module-cache for
details on how the import caching works.
The reason the classes get out of sync is because the metaclass doesn't
update interfaces when the second actual import happens, so the
`SocketInterface` class that gets instantiated holds a reference to the
old `socket_devices` dict. Removing the caching removes that problem as
well. If there's no caching, both the `SocketInterface` class and
`IngenicoDriver` will hold a reference to the same instance of
`socket_devices`.
X-original-commit: edffdd10f3ceb3826bf8897f93fa8290d7fce1ec
This commit was originally part of a larger commit related to an
Ingenico double connection deadlock bugfix in V13, but in V14 most of
the related code has moved to enterprise. When a driver thread is
running, calling `disconnect` on it will delete it from iot_devices. If
the driver thread gets added to iot_devices in the Interface thread
after starting it, this means there is a tiny window of time where
`disconnect` could be called and the thread wouldn't be in iot_devices
yet, resulting in an exception. This change puts the driver thread in
iot_devices before starting it, avoiding that scenario and the need to
check in `disconnect` for that happening.
X-original-commit: 6c24d30c3910e67ed751327d1554e2e8cf5e958b
This commit will add the needed ESLint configurations on the JS files.
These configurations are added if the JS file uses a different
environment (serviceworker, node, etc) or if it uses a specific global
(google, ace, etc).
Co-authored-by: Samuel Degueldre <sad@odoo.com>
* The result of `plaintext2html` is fully controlled and
markup-safe (the first thing we do is escape the input).
* For `append_content_to_html`, we assume the inputs are HTML and the
output is thus always properly HTML.
Alternatively, we may want to `Markup("%s%s") % ...` and require the
inputs to be properly marked? That seems like a good idea.
* In `_replace_local_links`, applying re.sub will strip out the markup
mark, so store it and reapply it on output if necessary.
That one is a big gnarly, because if the input to ustr is
markup-safe bytes (e.g. qweb rendering output) then the output is a
Markup object, but if the input is str then the output is str, so we
need to check before and after unless... we update ustr to check for
subclasses instead of exact type?
* In `_prepend_preview` the issue is similar to that of
`append_content_to_html`, though in this case we should *not* trust
the input, so we can flag the "parent document" as Markup and format
the preview bit in.
* And since we're marking mail's jinja output as safe, do the same for
web and iot.
Sadly there doesn't seem to be any hook for doing that at the
environment level of jinja, so every `Template.render` site has to
be marked.
Some requests are sended without specific action.
So we need set these call to fit to a default action
who is a empty string.
Pull requeste related: 63375
closesodoo/odoo#67089
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Only the 'action' requests have the 'data' parameter set, so any other
request triggering a 'device_changed' failed.
closesodoo/odoo#66826
X-original-commit: 0850814dda9802973e48ef89d6a81d61fc36a646
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
Add possibilities to map actions for the drivers
To avoid a sequence of "if elif else" we integrate a '_actions()' dictionary
where the key is the name of the action and the value is
the name of the function to be executed in the drivers
with the action data as a parameter
closesodoo/odoo#63375
Related: odoo/enterprise#15310
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Add all the request data in events triggered by IoT actions.
closesodoo/odoo#61798
Taskid: 2320958
X-original-commit: a8c56602ba8301b6e901be7ffeaa219d77401f79
Related: odoo/enterprise#14763
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Events coming from the IoT Box were lost in two cases:
1. Create a listener for device 1
2. Send an action to device 1
--> If the action arrives before the listener the event is never sent
to the DB
1. Setup up two listeners for devices 1 & 2
2. After a few seconds, send two consecutive actions to devices 1 & 2
--> Everytime a longpolling request arrives, a new threading.Event
object is created. The first action sets the event, then, before the
new longpolling request arrives, the second action sets the same event,
which is overwritten once the new longpolling request arrives.
We now maintain a list of events, and when a longpolling request
arrives on the IoT Box, we make sure that all events that occured in
the last 5 seconds were received by the DB. If no events were pending,
we wait 50 seconds to check if a new one pops up.
Taskid: 2320958
X-original-commit: e3260712ce96a8d81bf807574c334d92c37c6ae4
Add support for Star Line Mode protocol, used by most Star receipt
printers.
closesodoo/odoo#60371
Taskid: 2365648
X-original-commit: cd0545b98fc1e7a66dd46eb6a283736ef58ac4ff
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
We used to patch http.py using a diff. This was really not practical
because every time the file was modified, the diff had to be recreated.
We now override the specific methods directly.
closesodoo/odoo#60366
X-original-commit: a6012f03ff02f04a3d128e33326f932fd22f0ced
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
We sometimes encountered IoT Boxes crashing because the remount failed.
As this isn't a big issue, we won't check the return value of the call
to `mount`.
closesodoo/odoo#59438
X-original-commit: 5f9874da0f5f5b27c546cd248d08299f0e65544b
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
The path to folder of images of IoT has change.
So we adapt the path for the upgrade of IoT
closesodoo/odoo#57978
X-original-commit: 9512a23f48176fe0e7970039c824281c4af18162
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
If IoT Box is on access point mode the box try to reach https://iot-proxy.odoo.com
to get pairing code. So the box try while 5 minutes to reach iot-proxy
and send request on network every 10 secondes.
Now we add a condition 'if not access_point()' to send these request.
closesodoo/odoo#57976
X-original-commit: 901dc987c0204a7df2b811bb430f31eabf204fbb
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
We make request to iot-proxy.odoo.com every 10 secondes
while 5 minutes.
But we have a traceback if we don't have a internet connection.
So we put a 'try except' to catch error
Related 841c016913a8
closesodoo/odoo#57567
X-original-commit: 3227490e270a1f5b98ef7811edca59e9aa1b6b55
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
When printing a long receipt from the POS, the printer crashed, printed
random characters and needed to be rebooted to print other receipts.
The problem was that there's a limitation of height when printing
images with ESC/POS (see [ESC/POS documentation](http://www.starmicronics.com/support/mannualfolder/escpos_cm_en.pdf), page 158).
We then split the image into slices and print slices with separate
commands.
closesodoo/odoo#57512
X-original-commit: ab06df30557af90f3e704d4cfc1e6da66f7708b7
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
The threads of devices were still running after `disconnect` had been
called. We add a `_stopped` flag that is set when the thread should be
stopped.
closesodoo/odoo#56500
X-original-commit: 639a4e4fc72567a9655599eef150fabefaf1ff2e
Related: odoo/enterprise#12651
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
lejeune quentin