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>
- Split driver.py to multiple files
- Remove hw_proxy module as most of its routes were not used and
move remaingin routes to a controller in hw_drivers
- Add missing coding and license lines at the beginning of files
- Reorder imports and remove unused ones
- Rename device_id to device_identifier for clarity
- Rename screen to display for consistency
- Other minors improvements
Taskid: 1973956
X-original-commit: 841c016913a87133bf7257c62ae5f6bf7d99e06d
`device_name` and `scanner_name` were defined outside of the scope of
the function where they were used in.
We move them and try to simplify the logic a bit.
closesodoo/odoo#56454
X-original-commit: e59e311578aa0b4539ef27580462a2c2e1dce970
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
Some scanner are detected like keyboard because they do not meet
the conditions to be supported as a scanner by the driver.
So we add the possibility to manually switch the type of device
between scanner and keyboard.
closesodoo/odoo#56053
Related: odoo/enterprise#12370
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Some network Zebra printer are not detected because
the protocol 'socket' is not supported.
Now we add this protocol in the 'supported' function
closesodoo/odoo#56146
X-original-commit: f7fa40bdbbd765caf8fe528fff949b4dccf3d8c2
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
We move the IoT Box version file from /home/pi to /var/odoo
so its not overriden after an auto-flash of the IoT Box.
closesodoo/odoo#54063
X-original-commit: ce0700ce401523267b5a8bd5665a368cfea24912
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Trying to call display_refresh or update_url when no screen was
connected to the IoT Box and the default distant_display was created
resulted in an error.
closesodoo/odoo#53975
X-original-commit: 77768b93bc64d47abdbd4abd48c386acb293815e
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>
In Chrome 84, mixed content will be completely blocked for security
reasons ([see blog](https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html))
Other browsers will probably follow in the next months.
As IoT Boxes don't have a valid certificate before connecting to a DB,
we used mixed passive content to communicate with the boxes.
This won't be possible anymore, and we have no possible way to
communicate directly from the browser to the box.
- When an IoT Box boots without registered DB, a unique code will be
created with a validity of 5 minutes.
- This code will be shown on the customer display and printed on the
status ticket.
- The box will call a route on odoo.com and a record will be created
in odoo.com with the unique code.
- The user will have to enter the code manually in his DB to connect
to the IoT Box, the DB will then contact odoo.com to search for a
record containing the unique code. If it's found, the
`openerp.enterprise.database` will be added to the record.
- The box will then query odoo.com at regular intervals (10 seconds)
to check if a DB is linked to the code.
closesodoo/odoo#53623
Taskid: 2246535
X-original-commit: c55f12e32598a713105f3c049ac053e46ba15bb2
Related: odoo/enterprise#11421
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
dbkosky