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>
According to:
https://requests.readthedocs.io/en/stable/user/advanced/#timeouts
There is 2 different timeout, the connect and read one.
Both have their own exception if they timeout, the connect one
was handled but not the read one.
Before this commit:
If the read timeout happen, a traceback will occur interrupting
the (scheduled) job:
File ".../odoo/addons/product_images/wizard/product_fetch_image_wizard.py", line 308, in _get_image_from_url
response = self._session.get(url, timeout=5)
...
requests.exceptions.ReadTimeout: HTTPSConnectionPool(host='...', port=443): Read timed out. (read timeout=5)
After this commit:
We ignore the timeout-ing request the same way the
request.ConnectionError do
opw-3546601
closesodoo/odoo#147012
X-original-commit: a4c382e3e03541d5db7fd7c627b78658573732a4
Signed-off-by: Loan Sens (lse) <lse@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>
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>
To reproduce:
1. on your windows computer, add a system environment variable with:
- Key: ODOO_RC
- Value: (path to any file except the `$INSTDIR\server\odoo.log`)
2. Install Odoo Windows version
Notice that the log are stored into the `$INSTDIR\server\odoo.log` file
3. Restart Odoo's service
=> Odoo's log file does not log anything anymore
Cause:
As odoo will use in priority the environment variable as the config file path.
This will save the config change into that file instead of the intended one at
`$INSTDIR\server\odoo.conf`.
Due to this, the config file remain the default one created by the previous commands
but the log_file information get save to the wrong config file.
On restart of the service, as the parameter is not present,
it does not log in the intended way
After this commit:
Logs are logged into the log file as intended
Was discovered accidentally while reviewing an IoT PR:
https://github.com/odoo/odoo/pull/137547closesodoo/odoo#142796
X-original-commit: bbd06814a7e42c22206087c0df1e06d14dbba74e
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Loan Sens (lse) <lse@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>
Connecting a cashdrawer to an ePoS printer in direct device ( NOT with
an IoT box) will not automatically open the cashdrawer as it would be
intended when paying with cash.
This happens due to the fact that we check that the printer connection
is "connected" which is not the case with direct device as it use the
default value in the setup which is "disconnected".
opw-3470241
closesodoo/odoo#133216
X-original-commit: 339a76885db0f2034bae21eec76d0127d2733205
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Loan Sens (lse) <lse@odoo.com>
Before this commit:
JS errors on iOS with Safari's browser due to the date syntax not being
supported:
```js
new Date("2023-08-18 14:02:53")
-> Invalid Date
```
This does prevent Odoo's backend to start up on the browser and the app
on iOS devices.
opw-3465337
closesodoo/odoo#132461
X-original-commit: a39391d0df644fce86f435ba3f39e7634d8e5172
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit:
If the barcode nomenclature uses the or `|` symbol.
The part after it would be used as a "contains" instead of a
"start with".
e.g: `123|456`
would be transformed in the JS code to `^123|456` instead of:
`^123|^456`
As such, you would have error "can't find product with barcode" if
you set such a rule and a product barcode contains the second part.
For e.g: the barcode `44445666` would match, but should not!
After this commit:
Force the second (and following if any) part to start with.
Note: in practice it is pretty rare to have `|` in the pattern, but
it is the case for a default rule in version 16, see:
https://github.com/odoo/odoo/blob/5ac58ebf983c1c02019253c0430fde3502e13e7c/addons/pos_loyalty/data/default_barcode_patterns.xml#L10
In this case, if a regular product have `044` in its product barcode,
the PoS will tell that there is no corresponding coupon instead of
adding the product.
But the issue itself still apply in version 14 in case of custom rules
opw-3356951
closesodoo/odoo#130961
X-original-commit: 103566699d3492b682219efc3614f26d2ea972e5
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Loan Sens (lse) <lse@odoo.com>
To reproduce (16.1 and >):
1. Install PoS and enable Six payment method
2. Create a payment method using Six
(the IP can be set randomly, it does not matter here to have the
terminal connected)
3. Add the Six payment method to the PoS configuration
4. Open the PoS session
-> The "Send balance" button of the navbar is totally missing
For now, the manifest try to load the assets at:
`pos_six/static/src/app/**/*`
But, since 16.1 the file location for the XML and JS is misplaced in
`/static/app` instead of `/static/src/app`,
as such, the template file is missing.
opw-3422166
closesodoo/odoo#128813
X-original-commit: 859390a42cb8b2b10b017dca2ea5734cd8915c49
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Signed-off-by: Loan Sens (lse) <lse@odoo.com>
To reproduce (V16):
0. Install Accounting (can also be reproduced with just Invoicing, but
there is no "journal item" menu that will ease the process to show the
issue)
1. (In debug), change the dollar currency rounding to 0.0001
(instead of 0.01)
2. Go to Accounting > Customers > Invoices
3. Create a first invoice with:
- a partner P1
- set an invoice date
- make sure that there is a payment term set (for example "30 days")
- at least one invoiced line (the product does not matter) with the
tax 15 % and the price to 12.36
DO NOT confirm the invoice
4. Create another invoice with
- ANOTHER partner P2
- set an invoice date
- make sure that there is a payment term set (for example "30 days")
- at least one invoiced line (the product and the price does not
matter)
5. Go back to the Invoices list view and select the 2 new (unposted)
invoices then Action > Post entries.
6. Check Force and "Post Journal Entries"
7. Go to Accounting > Reporting > Journal Items
8. Group by "Journal Entry" and unfold the 2 last invoices (that should
be the one validated in 6.)
=> The "Partner" set on the Debit Line is the one of the other invoice
(and vice versa)
Analyse:
This issue is a mix of different sub-issues. Solving any of this
sub-issue would solve the issue but as other sub-issues may exists we
will fix each of them individually.
Sub-issue 1:
The account.move.line (=AML) partner is set correctly before the post
(6.), this is during the "mass posting" process that the issue happens.
The partner is changed because of this line:
https://github.com/odoo/odoo/blob/8006e7ce618f98bd26a82cf9b64eaa9b6e9c9d2a/addons/account/models/account_move.py#L2094-L2096
The value written to AML of id `line_id` include `move_id` which
overwrite the account.move that was originally set on the AML.
As the `partner` is computed only in certain circumstances, if the
`move_id` written differ from the one of the AML, most of the values
will be updated with the write values, but the `partner_id` will keep
its value (this is why the swap of partner happen).
In other words, this issue happen as `line_id.move_id` order is
different from `key["move_id"]`. So we write on the "wrong" AML.
Sub-issue 2:
In theory, this issue should not have happened in the first place.
The line:
https://github.com/odoo/odoo/blob/8006e7ce618f98bd26a82cf9b64eaa9b6e9c9d2a/addons/account/models/account_move.py#L2061
should have prevent the re-edition of the AML (as actually no relevant
datas are written). But the equality between the dictionaries fail due to some rounding errors.
Here:
- needed_after[<key Invoice 1>]["balance"] --> 14.214000000000002
- needed_before[<key Invoice 1>]["balance"] -> 14.213999999999999
N.B: if we don't set an "invoice date" on the invoice, a rewrite is
done before which would prevent our issue to reproduce.
Sub-issue 3:
If we try to reproduce the issue without setting a "payment term", the
issue would not reproduce.
By setting a "payment term" the `to_delete` computation change at:
https://github.com/odoo/odoo/blob/8006e7ce618f98bd26a82cf9b64eaa9b6e9c9d2a/addons/account/models/account_move.py#L2067
This happens as the `existing_before` keys and `needed_after` keys are
different:
- existing_before[<key Invoice 1>]["discount_date"] -> False
- needed_after[<key Invoice 1>]["discount_date"] ----> None
As the values are different, Odoo all the AML to the `to_delete` which
then trigger their overwrite.
In other words, if no "payment terms" were set on the invoices, the
issue would not happen either
opw-3270471,3292931,3333799
closesodoo/odoo#126272
X-original-commit: 074964b6c91d223da0b416855a92e9ed8a17ee55
Signed-off-by: William André (wan) <wan@odoo.com>
To reproduce (16.1 and >):
1. install pos_restaurant
2. open the bar PoS (NOT a shop)
3. choose a table
4. sell a product & make the payment & new order
5. choose a table (can be the same as before, it does not matter)
6. refund
7. select the previous order > refund
(already a bug, it is not proposed it is empty. But we can force
its selection by going again in the refund tab. Will create a
dedicated task for this issue)
8. go back to the main floor (to force sync the order)
9. go back to the table with the hanging refund order
10. try to pay it
=> server error:
```
bad query: INSERT INTO "pos_order_line" (..., "refunded_orderline_id", ...) VALUES (..., ARRAY[1,'Coca-Cola'], ...) RETURNING "id"
ERROR: invalid input syntax for type integer: "Coca-Cola"
LINE 1: ..., ARRAY[1,'Coca-Cola'],...
```
This happens due to this recent fix:
https://github.com/odoo/odoo/pull/116271
Adding this field in the `search_read` yield the product ID and the name
(ORM default behavior on Many2one fields). As the PoS needs only the ID
we take it from the tuple.
Note: the fix does target originally version 15, but the forward port
code was changed only on version 16.1 and > creating this issue.
After this commit:
Able to refund order without an errors
opw-3292121
closesodoo/odoo#120722
X-original-commit: a2ad09c0fb50a299afa29e01b457ff1699f6d811
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Sens Loan (lse) <lse@odoo.com>
Before this commit:
The scheduled action will repeatedly time out if the number of visitors
to remove is too high. In the case of the client, he has ~ 4 millions
inactive visitors to remove. This might happen after a bot spam attack.
After this commit:
The visitors are removed by batch of 1000, reducing the number of old
visitors with time
opw-3256349
closesodoo/odoo#119757
X-original-commit: b69917ec0e508f8354d831525c5c48ee79b5967a
Signed-off-by: Romain Derie (rde) <rde@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>
Before this commit:
If the ePos printer is reachable but is
configured incorrectly (change of Device ID, etc.)
or have an issue (missing paper, etc.),
a generic error message will be given:
"Please check if the printer has enough paper
and is ready to print."
This is too generic considering the amount of issue
that can happen and the fact that the printer itself
does send to us a `code` which give good indication
on the origin of the issue.
The list of these codes can be seen at:
https://files.support.epson.com/pdf/pos/bulk/server_direct_print_um_en_revk.pdf#page=52
In version 14 this code was given in the error message.
But this feature was lost in the versions above
&
Trying to print a receipt from the PoS with
a wrongly configured ePoS printer will just pop
the confirmation popup:
'Do you want to print using the web printer?'
Without giving any details regarding the errors
causing the issue
After this commit:
A more precise error message is given:
- Containing the printer error code
- Giving recommendation on how to search
online to solve the issue
- On the specific case of the `Device ID`
setting changed, give more details on the
value to use
&
The error pop-up with the error details
is displayed first. Then the confirmation one
opw-3188576
opw-3071709
closesodoo/odoo#116020
X-original-commit: 1f753d31c925e479e8243a6427a24b3da99bfc31
Signed-off-by: Loan (LSE) <lse@odoo.com>
Signed-off-by: Loan (LSE) <lse@odoo.com>
Signed-off-by: Sens Loan (lse) <lse@odoo.com>
Before this commit:
If a payulatam payment is received from the confirmation
page (so, with the webhook). If the value have some decimals
it might be rounded in the wrong way.
As such, the generated signature to compare with is wrong
and the payment validation cancelled
After this commit
If we cross compare the signature generation documentation:
https://developers.payulatam.com/latam/en/docs/integrations/webcheckout-integration/response-page.html#signature-validationhttps://developers.payulatam.com/latam/en/docs/integrations/webcheckout-integration/confirmation-page.html#signature-validation
We notice that the `new_value` computation is slightly different
depending on the return.
The one we currently use for both method is the "return"
one which is computed differently from the "confirm" one.
With this change of code a "confirmation" page payment
will be validated as intended.
I also changed the log level from warning to exception
so that the traceback and exception message is logged.
Before this commit there was just a generic warning message
opw-3018628
closesodoo/odoo#114552
X-original-commit: ee30c21eb5189b2cfcfd6d249985c947f759eaa2
Signed-off-by: Loan (LSE) <lse@odoo.com>
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Sens Loan (lse) <lse@odoo.com>
To reproduce (V16):
1. Force modify a view with an unexisting field
For example `res.users.tree` with:
`<field name="unexisting_field"/>`
( note that odoo won't allow to do so,
you will have to do it in raw PSQL * )
2. Open Settings > User & Companies > Users
=> JS traceback error:
```js
UncaughtPromiseError > TypeError
Uncaught Promise > Cannot read properties of undefined (reading 'string')
TypeError: Cannot read properties of undefined (reading 'string')
at http://localhost:8069/web/assets/debug/web.assets_backend.js:67523:84 (/web/static/src/legacy/legacy_load_views.js:67)
...
```
* : In practice, it happens to Odoo customers after
incorrect installations/removal of apps
After this commit:
The JS traceback is much clearer regarding the error:
```js
UncaughtPromiseError
Uncaught Promise > Missing field string information for the field 'unexisting_field' from the 'res.users' model
```
OPW-3071843
closesodoo/odoo#113345
X-original-commit: 33f82a60cd3bb64e67d939795b774cd332ab0508
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit:
1. Set up an EasyPost shipment setup, using
"Canada Post" as the Carrier Type and
"XpresspostUSA" as the Default Service Level.
2. Create a SO with a US customer (like Deco Addict)
3. "Add Shipping" using the button and choose the one created in 1.
4. When you try to "Get Rate" using the EasyPost shipment,
the API does always return the same error:
```
Easypost returned an error:
Unable to proceed, 'customs_info' is required for
international shipments, shipments bound for US
military bases, or US territories. Please see
https://www.easypost.com/docs/api#customs for more information.
```
After this commit:
As no commodities were set, `_customs_info` will return
an empty dictionary.
To solve that, we set the `DeliveryPackage` commodity
value on its initialisation to compute the customs
information the way it should.
opw-3104305
closesodoo/odoo#112988
X-original-commit: 06beca4373743787ae629b2c7ea623bf0583727a
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Before this commit:
If we do a payment in COP (Colombian currency) with a 2 decimal price,
For example: $ 1.23
The signature generated by Odoo to PayULatam will be wrong.
This will lead to an Internal Server Error caused by the `ValidationError`:
`PayU Latam: Invalid sign: received %(sign)s, computed %(check)s.`
Note that the issue does not happen on version 14.
By cross comparing with the version 14, the issue don't happen there
as the signature sent by Odoo at the beginning of the transaction is
different.
For some unknown reason the code was changed in version 15 to round it to the
first decimal and this looks to be the cause of the issue.
So, in fact the signature that Odoo send at the beginning of the transaction
looks to be wrong and this ends up modifying the signature that should be
generated on the return of the transaction
Version 14 code to compare with:
https://github.com/odoo/odoo/blob/bbb987edff769a825f7617d24314ec7d79e29c40/addons/payment_payulatam/models/payment.py#L41
After this commit
No internal server error and the transaction is validated correctly
opw-3018628
closesodoo/odoo#113059
X-original-commit: 106560e211fb02cedc6dd640effee2d97fb590f0
Signed-off-by: Loan (LSE) <lse@odoo.com>
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before this commit:
If the PoS config have no "Barcode Nomenclature" set, the PoS
session can't start and a cryptic JS traceback will be shown:
```js
TypeError: Cannot read properties of undefined (reading 'message')
at Chrome.start
```
This happen as the barcode rejected Promise request doesn't contains
an error message. More details in:
https://github.com/odoo/odoo/pull/108797
After this commit:
A more user friendly error is displayed
Note: the issue does not happen in previous Odoo's versions
as the field was required before.
opw-3110204
closesodoo/odoo#109191
X-original-commit: fae1f0e363587ac743cac2a7102528f1db4ec83b
Signed-off-by: Loan (LSE) <lse@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Before this commit:
If you make a PoS payment using a Stripe terminal, you will have
the following JS Traceback:
```js
TypeError: Cannot read properties of undefined (reading 'data')
at Proxy.captureAfterPayment
```
This happens on the line:
`capturePayment.charges.data[0].payment_method_details.card_present.brand;`
It occurs as Stripe API most recent version does not provide the
`charges` value anymore.
> The charges property on PaymentIntent has been removed
source:
https://stripe.com/docs/upgrades#2022-11-15
After this commit:
We skip the data if not mentioned on the JS side.
In addition of that, we use the `_stripe_make_request`
method of the Stripe payment provider as it
force in its header to use a certain Stripe API version
compatible with the features that we are looking for.
opw-3097460
closesodoo/odoo#108851
X-original-commit: 6a6057caf63d7e6a60dac190b2ea1ebb954d8f6a
Signed-off-by: Loan (LSE) <lse@odoo.com>
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Before this commit:
Thread details gave information regarding the database
the UID and the URL.
After this commit:
It also informs on the "performance times":
- `qc` = query count
- `qt` = query time
- `pt` = python time. It should in theory be "remaining time", but it won't be use as its acronym `rt` is too ambiguous/confusing
closesodoo/odoo#106610
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
This PR is mainly meant for the support.
Note that the `stack_info` is purposefully accessible to add some stack trace in the logs.
Example of support tickets where it can be useful:
A certain field of a particular model change it's value with no particular pattern and way to reproduce.
With this commit, we can now create an automated actions on the model update trigger to dump the current stack that will lead us on the action that did trigger it.
closesodoo/odoo#75320
Signed-off-by: Julien Castiaux <juc@odoo.com>
Before this commit:
If we remove a payment line using an Adyen payment method,
`pending_adyen_line()` return `undefined`.
With the `_poll_for_response` still being executed,
it will pop some JS traceback each call with:
```js
TypeError: Cannot read properties of undefined (reading 'terminalServiceId')
```
After this commit:
No JS traceback loop
OPW-3032391
closesodoo/odoo#106470
X-original-commit: 52a517ca74e563a0ad5538e8a7fc1fe19528856c
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Before this commit:
In the bottom of the settings, it would show:
`Database expiration: Invalid Datetime` if
the `database.expiration_date` system parameter
value is set.
After this commit:
The date is displayed correctly
OPW-3047586
OPW-3072884
closesodoo/odoo#106497
X-original-commit: 9f59129f5281894799dfdb0fcd296d2d52823e12
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
To reproduce:
1. Create a (incorrect) view manually. For example, inherit from
`res.config.settings.view.form` and do add the following view architecture:
```xml
<data>
<xpath expr="//div[hasclass('settings')]" position="inside">
<field name="field-dont-exist" widget="upgrade_boolean"/>
</xpath>
</data>
```
( In practice, Odoo will refuse to let us save the view if it is incorrect
(we can bypass that by pushing directly in the database for testing) )
-> When trying to open the settings app, you will have a cryptic JS error:
`TypeError: field_utils.format[(formatType || this.formatType)] is not a function`
The goal of this PR is to improve the error to ease its correction.
Note: This issue can happen in practice after an upgrade or a failed
uninstallation of a module.
OPW-2952309
closesodoo/odoo#103686
X-original-commit: 73dccc3e51472f76cf5cf32a4fbd48d0b58b5c36
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
To reproduce:
Video: https://drive.google.com/file/d/1bAh7KA_5UhhIrr-qF5A5gOVWhk3_9clj/view
1. Have multi-language website
2. Event with one ticket
3. Reload page and click the "Register" button
-> in some cases there is a traceback
`/event/great-reno-ballon-race-2/registration/new: Function declared as capable of handling request of type 'json' but called with a request of type 'http'`
Reason of the issue:
As the button "Register" in the form is defined with `type="submit"` it will send the form as plain HTTP if clicked.
This behavior is modified in the JavaScript to prevent this default behavior.
However, if the button is clicked before the JS load, the HTTP behavior is used which does create the above traceback (as the `registration/new` route accept only `json` type).
Solution proposed:
Prevent the button default behavior and make it deactivated and let the JS activate it when it is ready
Note on stability:
As JS code and XML view is modified, this fix was thought so that the JS won't have an impact if the view isn't updated.
There is theoretically no way that the XML view would be updated without the JS being updated (except manual modification in the view or rollback on the version revision after performing a module update on odoo.sh). If it was the case then the button will be deactivated until the user change the number of ticket.
OPW-2946706
closesodoo/odoo#101311
X-original-commit: 5a8892497e2b0df5e1dc8085214687786954c878
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Sens Loan (lse) <lse@odoo.com>
Revert of
https://github.com/odoo/odoo/pull/92794
If you install pos_restaurant and open a PoS sale session, issue will start to appear after a certain time (about 1 minute):
For V15:
Javascript console logs will log errors:
`TypeError: Cannot read properties of undefined (reading 'id') Chrome.js:97`
For V15.2:
The products button will become unresponsive (so the PoS is unusable).
With error in the JS console as well:
`TypeError: Cannot read properties of undefined (reading '0') Chrome.js`
OPW-2889985
closesodoo/odoo#94938
X-original-commit: 965b797772becba0dbd7b978b5c422ba1474663a
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Chrome did an update on which LAN devices are not accessible trough websites (but would still be accessible in `localhost`) ending in CORS error when trying to reach the device. More information:
https://developer.chrome.com/blog/private-network-access-update/
Before this commit:
A lot of customers were confused as of why their printers suddently stop working without any changes.
After this commit:
The error message have been improved to also guide people to solve this issue (creating an HTTPS certificate).
Note that it is not possible from the JS code to say if they are concerned by this issue or not as the error given does not specify explicitly if it is a CORS error or something else, see:
https://stackoverflow.com/a/6734427
OPW-2850019
& many more like:
OPW-2856164
OPW-2858658
OPW-2857076
closesodoo/odoo#93764
X-original-commit: e97b14f2bfe3d8b096b42c6bc3cf35537367aff7
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Test case:
~ 16 000 products and using a pricelist with a fixed price for all products (so ~16 000 pricelist_item).
To reproduce:
Open PoS and add an item to the order
-> Very slow and not responsive: ~5 seconds to do the operation & around 2 minutes to fully load the PoS.
Issue:
`get_price` JS method is called several times and is a bit slow (~200ms). Mostly because of the linear search in the pricelist to check if the product does match.
Note that the function is called once per ProductItem rendered. Each time a product is added to the order the rendering is refreshed for all ProductItem displayed.
So the performance impact is significant if several of them are displayed.
To solve:
As the pricelist per Product.id is constant, we store the possible applied pricelist records on the product itself.
After this commit:
Order does take a few milliseconds to be added (2 ms VS 200ms)
Other notes:
A. With the current OWL version, it is not possible to force the render on only some of the ProductItem. A more appropriate fix could be done with "fine-grained reactivity" using a more recent OWL version
B. It was thought to store/cache the price value on the ProductItem itself. It does have its share of disadvantages (no check if the pricelist time period did start/end, etc.). Either way, with that being implemented, the PoS was still a bit slow (because of the 200ms per `_get_price` call)
OPW-2826122
closesodoo/odoo#90245
X-original-commit: 6f0bfb36a11e52e20b90ca85fc8847faadcdc95e
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Masereel Pierre <pim@odoo.com>
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>
Before this commit:
A call to `sync_data` was made each time an event happen in the calendar
( changing the day, switching to day/week/month/year ).
This can easily saturate the server and spam the Microsoft API.
After this commit:
One call is made at a time per tab.
This PR is an adaptation of the same fix which was done only for
Google calendar at:
https://github.com/odoo/odoo/pull/69619/files#diff-8457ad89f2f7a1847af533828b40994bfc6d80e1e9d45ee7707b534bda2b0f06
and partially solve another PR that I was planning (but a bit too "overkilled"):
https://github.com/odoo/odoo/pull/85465
OPW-2749791 & OPW-2741728
closesodoo/odoo#85754
X-original-commit: d25b3d783fd08cd1c84095da554f52b463422bc2
Signed-off-by: Arnaud Joset <arj@odoo.com>
###To reproduce (V15):
Video:
https://drive.google.com/file/d/1wCebPCVQMXmQk7G4CIMkh1MbZ89HW9ek/view
1. Install the module "Product Availability" ("website_sale_stock")
(that will install ecommerce & stock)
2. Choose a theme for the website (like developement)
3. Uninstall website
=> Internal server error
```
Exception: Unallowed to fetch files from addon website
Error when render the template
Exception: Unallowed to fetch files from addon website
Template: web.frontend_layout
Path: /t/html/head/t[1]
Node: <t t-call-assets="web.assets_common" t-js="false"/> - - -
```
###Analysis:
The assets and view should in theory be deleted in cascade when
the websites records are uninstalled.
However, if a website record fails to be removed,
for instance - in this case - because of pricelist which have an
`ondelete=restrict` PSQL constraint on its `website_id` field.
The PSQL cascade constraints on the other record are dropped
before being applied which result in the resource being still
there but not usable.
Note: this issue is not specific to the website app in particular.
It's just not worth to think for a more sophisticated way to fix
this issue in a stable version.
OPW-2700476
closesodoo/odoo#85443
X-original-commit: ef5296ab32426422698b763c33b2ddb5d0da6cc6
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Performance issue arise when the recordset is very large due to the union operator which apply at worst `len(self)` times.
By storing the ids then browse on them we avoid the union operation execution.
PySpy: https://drive.google.com/file/d/1jnxuSWGf2WmqeRz7zQOpBpmeRE5YnTwS/view?usp=sharing
filtered_domain (odoo/models.py:5398) take 65.6% of the graph (55.7% of the 85% of button_confirm)
To confirm a RFQ with 10 000 of the same product:
Before this commit: ~42s
After this commit: ~10s
OPW-2347525
closesodoo/odoo#60131
X-original-commit: 8b0eeb5076ed5387ca7132d79182800e10c6895e
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
On instances with a lot of coupons programs, performance issue arise while using eccommerce (adding item in basket ant opening it in particular).
In the client case, he have ~2000 of them.
Opening the basket with 1 product take:
Before this commit: ~10s
After this commit: ~2s
( pyflame is available in the ticket attachment )
`_get_valid_products` use the v13 `filtered_domain` method
Average execution time:
Before change: 0.001 s
After change: 0.0001 s
=> 10x times gained
The average execution time of `_is_valid_product` is 0.002 s (20 times slower than `_get_valid_products` for the same result).
=> All use of `_is_valid_product` were replaced by `_get_valid_products`
In this commit targeting master, we also completely remove
`_is_valid_product` as it effectively is no longer used and there are no
stable compatibility requirements.
OPW-2323599
closesodoo/odoo#56460
X-original-commit: c3a9738e25dbd773e3ee7c2175e62219346ef764
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
To reproduce (V12) using a fresh database with demo data:
1. Install eCommerce and Sales
2. Change Mitchell Admin settings so that he can see the 3 companies
3. Go into Settings and set a distinct "Terms and Conditions" text for each companies
4. Go the Website > Configuration, set "My website" to "Company_1" and save
5. Go to the website shop and buy any items
6. Find its corresponding Sale order (should be on Company_1)
=> "Terms and Conditions" used in the SO is the one of "YourCompany"
Analysis:
The terms and conditions are not specified in the SO creation,
so it runs the default value code to determine its value.
However the default code just ask to use the OdooBot company "Terms and Conditions".
https://github.com/odoo/odoo/blob/b6bf91d26b8fb45997b266c16be620d834a97cc7/addons/sale/models/sale.py#L121
OPW-2297114
closesodoo/odoo#55424
X-original-commit: 60565b5cd42da080e36fee5a94bcf8eafd15934d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The idea is to avoid useless SQL request as the searching process is heavy (have to look the word in several field and can be in translation tables).
As we at some point fetch all the searched product we do it at the beginning and use its information to gain performance on other queries.
Execution time in e-shop for "test" on client database (160 000 product with 4500 published):
- Before: ~ 7 sec
- After: ~ 2 sec
OPW-2256662
closesodoo/odoo#54202
X-original-commit: ec743deb23f22a823cd0ea56eb4719209a9c4d09
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Before this commit:
The `display_name` of the product was showing the code in the "Recently viewed products",
the code value isn't needed to be seen in the website.
After this commit:
More user-friendly product name is shown
OPW-2258774
closesodoo/odoo#51719
X-original-commit: be4d0d58081bea1b75ceee8f90372ed8cedbee2e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit:
When a PoS session is closed in anglosaxon accounting with real time stock valuation, the stock moves linked to PoS orders are used to create the stock valuation entry.
When an order is composed of only products of type 'service', there are no picking linked to the order, and so the entry is created with all stock moves having no picking_id.
After this commit:
To avoid this problem, we are checking that the PoS order has a picking before looking for stock moves.
OPW-2206625
closesodoo/odoo#49117
X-original-commit: 0386e1f099bf42a59a79febfa06906dd76bd62e2
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
When testing to send an email of a campaign from the automation
marketing app, a traceback is thrown.
This is due to a context error. We define a default value which isn't
possible to be assigned for the variable.
opw-2190077
closesodoo/odoo#47039
X-original-commit: ff1d42e26bca3ce60697f9d4ee28f6aae5b7046b
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce:
- install sales and easypost shipping
- have a delivery order of multiple packages with easypost
- click "send confirmation email"
Previous behavior:
the template does not handle multiple package references
and the associated link is wrong
Current behavior:
each reference is set in a separated link.
previous fix in 5ed27d470cd76d0a742c25e2be473124428d0798
opw-2199339
closesodoo/odoo#46334
X-original-commit: 7a3479c14b58a1a588bf50d859ee437eb504fcef
Signed-off-by: mightyjol <jhk-odoo@users.noreply.github.com>
In the code for commenting or posting to twitter a selected range of
text, we did not take into account the case of no selection (eg. we
click on an element, but another code prevent default browser action).
opw-2197227
closesodoo/odoo#45883
X-original-commit: c578279dba4a3fd95e261d8dc58f2704c3b50eb0
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Co-authored-by: Nicolas Lempereur <nle@odoo.com>
Loan (LSE)