It appears that chrome headless with sandboxing is failing when running
containerized because it tries to use Linux namespaces.
With this commit, the no-sanbox optional arg is used to avoid this
issue.
Closes#26456Closes#28053
Before that, when receiving, then invoicing with price diff, the value in interim account corresponded to the price on the invoice instead of the original valuation one.
Scenario to reproduce the issue:
* create PO with 1 product, FIFO valuation, price=10
* receive PO: the entry in stock interim account has debit=credit=10
* create invoice, with price=15 instead of 10
* the invoice entry should be: payable: C=15 ; price diff: D=5 ; interim account: D=10
==> Instead, we had payable: C=20 ; price diff: D=5 ; interim account: D=15 => this was wrong
Also added a test case for the same scenario, verifying the amounts written in the different accounts (and refactored a bit ValuationReconciliationTestCase for easiness)
Closes#27394
From times to times, warning are seen on the runbot during HttpCase
tests with the chrome headless browser.
Those warning are about Odoo trying to join remaining requests threads.
In the dumpstack, the thread seems blocked in the werkzeug
handle_one_request method, when trying to read the HTTP request line.
One explanation could be that Chrome opens a pre-connect socket for
a future use. When the HttpTest cleans the browser, the page stops
loading but (probably) keeps the socket open for a while.
That could explain the problem.
With this commit, a timeout is set on the request handler,
in the hope that it closes the pre-connect socket too.
Apparently missed in 07ab8b6cd2
In Python 3, there is no Exception.message attribute anymore, this would
lead to cascading exceptions in the stripe_s2s_create handler.
closesodoo/odoo#28141
1. Product A - on stock 5 pcs.
2. SO - 7 pcs. of A
3. Generated picking has reserved 5 pcs.
4. Increase stock to 7 pcs. (Update qty on Hand)
5. Run procurement scheduler
6. Picking still has reserved 5 pcs.
The scheduler should take into account the moves partially available.
Fixes#27874
opw-1895622
closesodoo/odoo#28136
Use case to reproduce:
- create a BoM of 50 finished products:
- Add a routing with an operation time of 1h
- Set a 1$/h cost on workcenter
- Set unit price from BoM
It will be 1$ for one product. It should be 0.02$
since it will take 1h for 50 products, so the price
should be 1/50
It happens because the system add the operation time by unit instead
of adding it only once.
related to commit 17b6256955
opw-1890005
Rev. 42e1efded5 aimed to disable the quick create feature when
grouped by date(time) fields, by only enabling it for char, boolean
and many2one fields. However, the selection case is quite important
and must be handled as well. This is what this rev. does.
Task 1878254
When a kanban view is grouped by a char or a boolean field, and the
quick create option is enabled, the correct default value for the
grouped field (i.e. the value of the column in which the record is
created) should be given (either in the context if that field isn't
in the quick create form view, or as a default value in that form
view otherwise).
Before this rev., it wasn't the case, as it was only working when
grouped by a many2one field.
Task 1878254
when grouped on field types for which it isn't supported.
Rev. 42e1efd disabled the quick create feature when the view is
grouped by date(time) fields. However, it hasn't been correctly
forwardported to 11.0 (with the new views). Indeed, the check was
done only once, at the initilization of the view. So if the user
selected another field to group by afterwards, the quick create
feature wasn't enabled/disabled accordingly.
Moreover, we didn't check if it was available when the user clicked
on CREATE in the control panel. So even if it wasn't (and thus if
there were no '+' icon in the columns), when the user clicked on
CREATE, the quick create widget was inserted in the first column.
This rev. fixes both issues.
Task 1878254
closesodoo/odoo#27867
Usecase to reproduce:
- 6 units in stock
- reserve 3 units on a move
- reserve 3 units on another move
- validate a third move with 1 unit
It raise the error could not reserve more than you have in stock.
It happens because when free reservation stole reservation from
an exisiting move with too much quantity available, it continues the
loop instead of stopping.
This commit stop the loop once we have enough quantity taken.
opw-1895578
closesodoo/odoo#27935
For unknown [1] reason, phantomjs starts to segfault when running qunit
tests.
Be radical with simply not using phantomjs anymore.
[1] Any guidance on tracking the root cause may help...
When computing coverage, the tests are slowed down and the timeout is
often exceeded.
With this commit, HttpCase headless Chrome tests timeout is increased if
coverage is detected.
When Odoo receive a SIGXCPU (CPU time limit reached), it shuts down
immediately. If a headless Chrome is running, it stays alive after the
Odoo shutdown.
With this commit, the signal is intercepeted and the Chrome browser is
properly closed before shutting down the Odoo server.
In some situations, Chrome remote debugging is sending an empty list of
opened tabs. In that case, an orphan Chrome process stays alive.
With this commit, Chrome is stopped properly in those situations.
When an HttpCase browser_js test is started, the screencast is started
and is discarded at the end of the test if no logfile was provided by
the config.
This behavior can impact the performances.
With this commit, the screencast does not start at all if not needed.
When executing a very long HttpCase browser_js test, it happens that one
of the chrome process PIPE is full (ie. clickEverywhere test).
In that case, the communication with Chrome is blocked.
With this commit the stdout and stderr of the Chrome process are
redirected to /dev/null.
Since chrome headless has been merged, js error messages are
difficult to read: some information was missing or only displayed in
full all log.
All console.error() will now be displayed in build details, and will
appear just before the python assertion.
XMO's improvement will also be used on all log: Using module and
classname of the class calling phantomJS.
Also: some small improvements on error messages to make them easier to read
Note: this commit also shown that some error were not detected:
now we will fail in any case if js log an error.
Before starting a JS test/tour the _wait_ready method evaluates if the
test is ready with a timeout of 10 sec. From times to times, it happens
that the page is not ready after this timeout but the problem is hidden.
In order to help fixing that kind of issue, the timeout is increased to
60 sec and a warning is logged to emphasis the fact that an
issue exists.
Also some unused imports are removed with this commit
When a Chrome headless test fails the browser is not cleaned and could
lead to a mix with other tests when the same method is called.
Also, the multiline assertions gives an unreadable message when the
assertion fails.
Finally, it happens that a thread does not have an 'url' attribute and lead to a crash when the logger tries to show the thread url.
With this commit, the browser is cleaned, even on failure and the
assertions are now one line.
Closes: #26432
The account module needs to import Form from "tests.common" causing a
traceback when websocket-client module is not installed.
As this module is only required for the tests, there is no reason to add
it to the "requirements.txt" file.
With this commit, Odoo account can be installed even when
websocket-client is not installed, in that case, the HttpCase tests that
needs to run Chrome headless will be skipped with a warning.
Closes: #26404
As the phantomjs project was suspended[1], there was a need to change the js test
engine. Moreover, the engine was rather old and leading to non
deterministic crashes.
Chrome headless was choosen for simplicity and the long term vision of
the devtools protocol [2].
The 'phantom_js' method still exists but will be deprecated in
favor of 'browser_js' with the same parameters.
In order to communicate with the browser, the python websocket-client package
is needed.
[1] https://github.com/ariya/phantomjs/issues/15344
[2] https://chromedevtools.github.io/devtools-protocol/closes#25991
* Make phantomjs logging clearer by logging within the test case's
module, not odoo.tests.common.
This way, a tour in e.g. point of sale is clearly logged as that,
rather than be logged as odoo.tests.common.phantomjs and require
hunting which module/test we happen to be in.
* Clarify tagging causes for exclusion of selection of tests.
If the invoice is not in the same currency as the sale order, then there was an
inconsistency in the sales report, as it was considered to be the unit currency.
We keep the initial computation in case where the invoice currency is the same.
opw 1890381
closesodoo/odoo#27797
Seems like something similar to odoo/odoo#17111 can happen on Python 2.
The same change as #17111 is a bit involved for -stable, but this looks
pretty harmless.
Probably fixes#23781.
Typically if you use an onchange method to retrieve values on the server
and convert them to write it will also try to write empty values like
[(6, 0, [])] and this will crash as it has also the length of 3 but no
dictionary but a list
closesodoo/odoo#27937
The CRON job that sends email sends them in a LIFO order instead
of a FIFO order which can lead to confusion when the order is
important.
Exemple, when updating multiple time an appointement, the last
update should be the newest mail clients receive in their mail box
which was not the case before this PR.
opw-1888601
closesodoo/odoo#27888
The test was comparing a scheduled date was correctly computed.
The runbot build 363053 failed because runbot12 is a bit slower and computed
the delay in 2 seconds instead of the 1 previously tolerated.
Increase the delta to 10 seconds.
The delay is a matter of days. Having a difference of 1, 10 or even 100 seconds
should be equivalent functionnaly.
Having a 100 seconds delay could indicate a serious performance issue though...
Christophe Monniez