Currently, on raspberry pi 5 our dislay interface is invading the logger
with errors due to the absence of both tvservice and the required
vcgencmd methods to identify the connected displays
While searching for a solution we can avoid the excessive log errors by
protecting the subprocess calls.
When using vcgencmd, the python wrapper of vcgencmd raises a
subprocess.CalledSubprocessError.
The tvservice does not exist on new rpi models so there is no need to
protect it
While the errors will still be present in the logs for a fresh image at
the moment,
once an rpi5 is connected to a database, it will receive the code from
this PR and will handle the exceptions more gracefully
task-3771334
closesodoo/odoo#155882
X-original-commit: 9dbcc7249d23fba36287c09c15252451ab6d0d87
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Currently, the user does not get any feedback if the printer couldn't print.
This can happen when the printer identifier is not the same on CUPS and on the IoT box due to this RegEx:
https://github.com/odoo/odoo/blob/5b62e301b91a3f39857c2c7f18729e10796ef194/addons/hw_drivers/iot_handlers/interfaces/PrinterInterface.py#L55
After this commit, an error message is displayed in the IoT box logs so the user is informed that the printing failed.
Also, the '-' character has been added to the RegEx as it is a commonly used character in printer's identifier as CUPS doesn't allow spaces.
opw-3458347
closesodoo/odoo#153148
X-original-commit: 722a7db800b66db2d0b735ced1b9f4074ddac611
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
we execute a subprocess without checking if an error occurs
so we place the subprocess.call() in a try except
closesodoo/odoo#152331
X-original-commit: 4adda36260f3ba0fdf75688b419593006b80adb7
Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com>
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Before the current PR, the version of Odoo along with the git branch of
the IoT Box and the associated image were never logged. Adding this
information to logs allow to to debug / inspect issues more easily
task-3716879
closesodoo/odoo#152558
X-original-commit: 8bf1c8984948b003544427eb81f66514ed783bd0
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
If an IoT doesn't have a DB recorded, the IoT client can't have an
url.
So the Websocket can't parse a empty string and return a traceback.
With this commit we check if there are a DB else iot_client is None
closesodoo/odoo#150089
Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com>
To reproduce:
1. Sync the IoT with a 17 database
2. Once it is set up, force shut down the server by Ctrl+C 2 times
3. Wait a few seconds:
=> crash of `WebsocketClient` thread with the following traceback:
```
Traceback (most recent call last):
File "/usr/lib/python3.11/threading.py", line 1038, in _bootstrap_i>
self.run()
File "/home/pi/odoo/addons/hw_drivers/websocket_client.py", line 83>
self.ws.run_forever()
File "/usr/local/lib/python3.11/dist-packages/websocket/_app.py", l>
raise WebSocketException("socket is already opened")
websocket._exceptions
WebSocketException
socket is already opened
```
The IoT synchronised servers can stop in 2 ways that we need to handle:
A. Gracefully (Ctrl+C):
In this case a disconnection signal is sent to the IoT-box
The websocket is properly closed, but it needs to be established a new connection when
the server will be back.
Solution: `while True` loop as `run_forever` will return on close.
`time.sleep` for the reconnection delay
B. Forced/killed (Ctrl+C 2 times):
In this case there is no disconnection signal received
Solution: use `reconnect` that will automatically take care re-attempting a connection
This will also happen with the graceful quit as `reconnect` will trigger if the server
is offline while attempting the new connection
In both case, we perform a reconnection attempt with a delay of 10 seconds to avoid
spamming the database
After this commit:
The websocket will reconnect itself automatically after 10 seconds
if the connection is disrupted
opw-3612528
closesodoo/odoo#147858
Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com>
Before, the websocket client was built manually, usign string
concatenation.
Now, urllib.parse() is used to appropriately adapt the database URL.
This update enhances security.
closesodoo/odoo#144303
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Context:
When an HTTPS certificate is delivered, it is valid for ~1 month.
To avoid missing the certificate, a script is automatically ran daily
to check if a new HTTPS certificate is necessary.
On the IoT box, it is added in the native Unix system with this file:
https://github.com/odoo/odoo/blob/16.0/addons/point_of_sale/tools/posbox/overwrite_after_init/etc/cron.daily/odoo
However, prior to this commit, there is nothing equivalent for windows
Note: the HTTPS certificate check is also done automatically when
accessing the homepage.
Before this commit:
After an HTTPS certificate delivery, if we let the IoT server
running non-stop (and without accessing the homepage).
The HTTPS will expire without any automatic renew.
After this commit:
The cron process is handled by the handler Manager
Other note:
- Using native Windows "Scheduled Task" have been proposed at:
https://github.com/odoo/odoo/pull/144584
But, was judged too risky from a security point of view
- `sched` library have been discarded as the code is too verbose
- This is unstable for the iot-box. This is the reason for the
initial Windows check on the import. The iot-box does not need
this fix anyway as explained in the context
opw-3617687
closesodoo/odoo#145114
X-original-commit: b9bd36056fbd3c27148da82cc49039669b8f8563
Signed-off-by: Loan Sens (lse) <lse@odoo.com>
The order of the imports have been changed in websocket_client.py to
follow odoo guidelines
closesodoo/odoo#144188
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Previously, there was a function called 'start_client' that was invoked
by the 'run' function. As 'start_client' was solely invoked within 'run'
and served no additional purpose, its functionality has been incorporated
directly into the 'run' function.
closesodoo/odoo#144134
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Before, the url was built with string comprehension.
Now json.dumps is use to ensure that the JSON sent is
valid
closesodoo/odoo#144125
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Add the possibility to dynamically change the logger level of Odoo and
per IoT handler (drivers and interfaces).
This will be done through the "Handler List" page.
This will be useful to troubleshoot purposes.
In particular when it happens on a specific handler.
The level set should persist on shutdown as saved in Odoo's configuration
using the `--log-handler` parameter, see:
https://www.odoo.com/documentation/16.0/developer/reference/cli.html#cmdoption-odoo-bin-log-handler
Notes:
- When changing Odoo's level, `werkzeug` logger will change to the same
level automatically (except in `debug` on which `werkzeug` will be set
to `info`)
- `--log-level` Odoo config wasn't used as it has unintended side
effects when dynamically switching to this level
- `load_iot_handlers` was modified as otherwise the loggers `__name__`
could be wrong and inconsistent on which several logger for a handler
exists. For example: `PrinterInterface.py` and
`odoo.addons.hw_drivers.iot_handlers.interfaces.PrinterInterface`. In
this situation `_logger` can be different from one used in the class.
In addition, of that, the parent logger for the different loggers could
be different (root and Odoo generally)
opw-3493585
closesodoo/odoo#139970
X-original-commit: 931456fed24c0d7700defd7672157d8bc54c3fe5
Signed-off-by: Loan Sens (lse) <lse@odoo.com>
Before the windows image couldn't run because the module
websocket-client was missing, now it's added in the list of module to
install on windows
closesodoo/odoo#143205
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Add a condition that check if the DB is connected to the iot box before
the start of the websocket client, before, if no DB was connected the
Thread was lauched for nothing
closesodoo/odoo#143132
Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com>
-Implemented a WebSocket service to facilitate communication with the IoT box. This enables printing reports on a network different from the browser. Before it was a long polling connection
-Implemented the ability to link multiple printers to a single report. Before it was possible to link only one printer er report
-When multiple printers are linked, a pop-up will prompt the user to select the preferred printers.
-The user's printer selection will be stored in the browser's local storage.
-Additionally, a reset button has been added to clear the printer selection.
task-3193258
closesodoo/odoo#129164
Related: odoo/enterprise#44398
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Fixes a large number of cases where strings are translated then
formatted, instead of letting `_()` do the formatting internally,
which allows it to recover from incorrect translations (missing,
broken, or extra placeholders).
Also
- removes translation markers entirely when there's nothing to
translate e.g. `_("%s - %s")` is not useful
- fixes a few messes which lead to only partial translatability
(DRY is generally a bad idea when translations are involved, even
more so when you don't make the variable part translatable)
- fixes a few nearby issues noticed at the same time
- replaces a few `"%s"` by `%r`, which should automatically quote
strings relatively appropriately
- fixes translated strings which use `\` to escape a newline (in order
to fill-paragraph): `\` escapes only the newline, if the
continuation string is indented this results in a bunch of spaces
ending in the string to translate, which is pretty garbage for the
translator, using implicit concatenation works much better
Note: some of the updates revert f-string parameters to %, because
babel (2.9) apparently has trouble with f-strings and blows up trying
to extract them.
Not in scope:
Helping translators fix translatable strings e.g. any translation
string with more than one placeholder probably should use keyword
placeholders
- Provides more context / data to the translator to make sense of the
sentence.
- Allows reordering the translated terms, which can be necessary
depending on the sentence and language.
closesodoo/odoo#139314
Related: odoo/enterprise#49311
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Adapts the build of the iot to meet the requirements of version 17 of Odoo
notably python >=3.10
closesodoo/odoo#139226
X-original-commit: 81d42e38beec510a0971685d3e58dcdee8da7951
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Replace all the calls to get_resource_path to the better file_path or
directly use file_open when not needed
Doing both a get_resource_path and file_open means checking twice that
the file exists.
Doing a simple path concatenation before a file_open is safe.
If given to another method (e.g. etree.parse), calling file_path is
the prefered method.
Note that get_resource_path used to return False when the file does
not exists while file_path/file_open raises a FileNotFoundException
closesodoo/odoo#135607
Related: odoo/upgrade#5187
Related: odoo/enterprise#47475
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before, when instatating the interfaces if there was an error inside
Odoo could stop. This PR prevents that and simply avoids instantiating
the interface which causes the error.
closesodoo/odoo#133890
X-original-commit: e8f700f766bde6906076192ffe12eec255454a81
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Before this commit:
When printing a receipt with an epson printers models TM-U2X0 (like
TM-U220), random characters will be printed instead of the receipt.
This happened as a picture of the receipt is sent to the IoT box, but
the TM-U2X0 models does not support all "Bit Image commands". We
currently use the GS v 0 one which is not supported by this printer
models. See:
https://reference.epson-biz.com/modules/ref_escpos/index.php?content_id=94
In addition, of that, the command itself is obsolete.
After this commit:
The support for another command "ESC *" is added which is not obsolete
and supported by TM-U2X0 models.
Notes:
- Compared to "GS v 0", the receipt printed with "ESC *" is worst:
- It take longer to print (5 seconds vs 1 second)
- There is consistently some thin "empty white lines"
- Most of the code is inspired from `python-escpos`:
https://github.com/python-escpos/python-escpos/blob/master/src/escpos/escpos.py
Due to the drawbacks, making it the default way to print would be a bad
idea. As such, we can configure the mode (with other parameters) using
particular name for the printer (which can be done by adding it manually
with cups)
opw-3351084,3341907
closesodoo/odoo#131332
X-original-commit: f30085bf673712c205e7ff318961d597297648d0
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Loan Sens (lse) <lse@odoo.com>
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>
Yaroslav Soroko (yaso)