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
When sending notifications by batch one notification email can be send
up to 50 people. For one mail_mail entry to handle 50 emails can be sent
as those are sent independently for each recipient.
In some cases a bounce may occur while the whole batch of recipients is
not completely mailed. In that case the mailgateway will update the
notification status to bounced. When the cron finishes to send the whole
batch of emails it tries to update the notifications of all recipients.
However as a notification has already been updated due to the bounce we
face a concurrent update, meaning the transaction is rollbacked.
Emails have been sent but notifications are not considered as sent as they
have not been updated accordingly. Next time the cron runs it will send the
same batch again, with probably the same bounce and rollback. We could
therefore face an email loop.
This commit add test for this use case.
This commit is linked to task ID 1893054.
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...
Steps to reproduce the bug:
- Create a customer invoice I with an amount of 100$ and validate it
- Register three payments P1 at 11/10, P2 at 12/10 and P3 at 13/10
- Click on button "Print" and the report displays the payments in the right order
P3, P2, P1
- Click on button "Send by email" and click on the attachment with the report
Bug:
The report didn't display the payments in the same order, it displayed P1, P2, P3
opw:1888251
closesodoo/odoo#27895
In JS, the groupBy attribute is a list of strings
The default_group_by key that is sometimes present in the XML views
gets converted to a list at somepoint.
Before this commit, the task action couldn't be used in the app Dashboard
After this commit, it can
OPW 1894751
closesodoo/odoo#27908
- The field `signup_valid` was computed and stored using the `superuser`
env, which causes issue since it means the value was computed for the
wrong environment.
Using a compute_sudo instead of manually calling `sudo()` fixes the
issue.
e.g: reading signup_valid using a regular user (non superuser) will
always return False, while doing it as the superuser will return
the correct value.
Odoo Translation Bot