After a browser_js, http requests threads are joined. If one of them
doesn't finish gracefully, a dumpstacks occurs.
As the dumpstacks call is in a loop, it can quickly polute logs. Even
more, a the dumptack may include threads that were not yet processed and
that will be joined in a future loop.
With this commit, dumpstacks will be called once and for all at the end
of the method, if at least one thread is remaining.
Furthermore, before this commit a sleep of 0.5 sec occured at most ten
times for each thread before considering it as lost. It means that each
thread is benefiting of the cumumulated time of the previous ones.
That's not fair.
With this commit, a default timeout of 10 sec is used for all threads.
The original warning is kept for each remaining request.
* disable background networking like GoogleUrlTracker ...
see https://codereview.chromium.org/3312014
* disable backgrounding occluded windows is a CLI swith that was
specifically written for tests to avoid non deterministic behavior. To
avoid test flakiness, it should come with disable renderer-backgrounding
and disable background-throttling as stated here:
https://github.com/smooth-code/jest-puppeteer/issues/137
* disable breakpad is used to disable crash reporting, the difference
with disable crash-reporter is not clear.
see https://peter.sh/experiments/chromium-command-line-switches/
* disable defaults-apps, prevent installation of default apps on the
first run
* disable dev-shm usage that may cause crashes
Undeterministic failures "Cannot connect to chrome"
can occurs in two scenarios:
-One time on a build, occasinnaly. This seems to be linked to chrome version.
runbots using version 71 don't have this problem when it occurs on runbot
with version 74 and 75.
-For all (36) attemps of the build to connect to chrome debugger,
this is exeptionnal but add a lot of noise by adding this type of
failure on any runbot.
Used chrome versions at this time:
r11-r22 -> 71.0.3578.98
r23-r24 -> 74.0.3729.169
r25-r28 -> 75.0.3770.90
All 'Could not connect' failure by runbot by day
day r13 r20 r24 r25 r26 r27 r28
07-15 36 4 2
07-16 6 1 1
07-17 36 2 1 2 2
07-18 2 39 1 2
07-19 1 3 1 3
07-20 1
07-21
07-22 2 1 4 1
07-23 1 1 1
07-24 4 3 2 1
07-25 2 5 2
07-26 3 3 1 1
07-27
07-28
07-29 36 1 1 1
07-30 3 1
07-31 1 3 2 1
08-01 3 1 1
08-02 3 1 1 1
08-03 1
08-04
08-05 1 5 4 1
08-06 1
08-07 2 1 2
08-08 2 2 2 1
08-09 2 2
08-10
08-11 1
08-12 2 1 4 3
08-13 1 2 1 2 72
Back2basics changed the context in the views and actions from
`type_tax_use` into `default_type_tax_use`, but also changed the one
used in the domain of a field which caused a traceback
closesodoo/odoo#35998
Signed-off-by: Romain Libert (rli) <rli@odoo.com>
In order to display some stats on survey's card (in the kanban view), the survey's card has been reorganized:
We remove all the button present in the bottom of the card, button concerned are:
• analyze answers
• test
• share
We recreate the button "share" in the dropdown menu of the card.
We add the next information:
- For each survey with scoring, the number of people who passed the test is displayed as well as the success rate.
- For each survey with scoring and certification, a certification icon is displayed and the string "passed" (corresponding to the number of people who passed the test) bec$
TASK-ID : 2045617
closesodoo/odoo#35479
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The commit c429c0e0bd removed context keys that were used to expand the view
The the commit 98a55917a6 fixed that
The the commit 9bc4a19d74 reintroduced
it (prob. bad rebase)
This commit re fixes that.
closesodoo/odoo#35977
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
This PR improves the display of editable of list views.
Instead of always hardcoding column widths depending of the field types, we let
the browser compute them as much as possible, i.e. as soon as there are records,
and we then freeze the widths s.t. it doesn't flicker when switching a row in edition.
However, we keep the fixed widths heuristic when there is no record to display, as
in this case the browser doesn't have enough information to compute the widths.
In the latter case, we also tweaked the heuristic s.t. all field types having a relative
width now have the same width factor (i.e. the available space is uniformly shared
between them).
Task 2011587
closesodoo/odoo#35801
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Let's assume the following situation:
- an empty editable x2many list with date field (or any other
fixed width field) and optional fields
- add a record to the list, but discard it directly
- toggle an optional field
After those steps, the date field doesn't have its hardcoded,
absolute width anymore.
This rev. fixes this issue by clarifying the way the stored widths
are erased when the columns change, preventing to reach a corner
case in which we have stored widths, but we can't apply them, and
thus let the browser uniformly divide the space amongst columns.
Columns with an absolute width (e.g. '120px') must always have a
width of at least that value. When there are records in the list
the column's widths are computed by the browser according to the
content (in readonly). However, for some field types, the rendering
in edition is a bit wider (e.g. date(time) fields because of the
caret).
This rev. sets a min-width to those fields such that the rendering
is also correct in edition.
Before this rev., a grouped list view with all groups folded
behaved like a list with records w.r.t. the computation of column
widths, whereas it should behave like an empty list, as there is
no record to help the browser to compute the optimal width for each
record.
When there were records in the list (and the browser computed the
optimal column widths according to them), and the user removes
them, we want to keep the widths as they are instead of forcing
them according to the field's types.
Mainly, when adding the first record to the list, as this is when
we switch from forcing the column's widths (when there is no data),
to letting the browser optimally divide the available space.
Some other cases had to be handled, like the multi edition.
Having two attributes for this was probably overkill. We now have
a single attribute 'width' which can specify either a fixed width
(e.g. '120px') or a factor (e.g. '2.5').
On a list with no data, the width of each column is determined by
a heuristic. Before this rev., the heuristic was based on the field
type. It now takes the potential widget set in the arch into
account, and fallbacks on the field type.
This rev. refines the way we compute column's widths in editable
list views.
When there are displayed records, we let the browser compute the
width of each column (which is thus optimal with respect to the
content), and we then freeze those widths s.t. it doesn't flicker
when we switch a row in edition.
When there is no record, we keep the former heuristic based on
absolute and relative widths (depending on field types). However,
we set the same weight for all fields having a relative width (i.e.
all but boolean, date(time) and numeric), such that the remaining
space is evenly distributed between them.
Co-authored-by: Aaron Bohy <aab@odoo.com>
This commit cleans up website.visitor related views by removing unnecessary create mode.
It also removes the form view on the website.visitor.page model (="Visitor Page Views") as tree view contains all
necessary information and there is no point in creating/editing them.
Task#2057933
closesodoo/odoo#35978
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Allow publishers to add a comment on frontend reviews with ratings. Purpose
is to allow to give some feedback or context on published reviews.
SPECIFICATIONS
In order to answer to a rating message (review) of a course (eLearning) or a
product (eCommerce) we add a way to the publisher to directly comment a review
inside the website rating chatter.
Any publisher can add/edit/remove comment of a rating message from the website.
The goal is not to enter into a discussion but just to give a feedback. This
comment is not sent or propagated to anyone, just displayed for information
purpose.
In portal chatter
* add 1 button below a review "Comment" (for publishers of the website only)
* only one comment possible by review/rating
* when the comment is added, display
* author name, date, comment
* 2 buttons, only visible by the website publisher: edit and delete
LINKS
Task ID : 2026911
closesodoo/odoo#35956
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Allow publishers to add a comment on frontend reviews with ratings. Purpose
is to allow to give some feedback or context on published reviews.
SPECIFICATIONS
* rename / reorder some methods according to JS guidelines;
* split portal composer and portal chatter override to better understand
module organization and ease future code additions;
LINKS
Task ID : 2026911
PURPOSE
This PR rewords the mail template "slide_template_published", makes the
member of a course follower of the course, allow members to leave courses
and prevents the templates to crash on preview
SPECIFICATIONS
When a user subscribe to a course, the user is automatically follower of
the course in order to be notified when a new content is published.
The email that the members get when a new content is published on the course
is reworded and fixed to avoid preview crash.
A new widget is implemented allowing members to unsubscribe from a course
or to leave it directly from eLearning frontend.
LINKS
Task 1985511
closesodoo/odoo#35627
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- Before it was not possible to leave a course.
- This commit adds a modal to give the members the possibility to leave
the course and also subscribe or unsubscribe to get notified or not.
+ Display a warning message when leaving if field enroll value is "payment".
task-1985511
This commit improves the email that the members get when a new content
is published on the course and prevents the template to crash on preview.
task-1985511
when a user subscribe to a course, the user is now automatically
follower of the course in order to be notified when a new content
is published
task-1985511
When we open a table, the option verify sync is called, and doesn't
always work because of a race condition when we chack the status of
connecting, and the icon that has already changed.
As it doesn't really check anything because we check in python that the
orders are synchronised, we removed it.
closesodoo/odoo#35949
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
In the tour of pos restaurant, we are closing the pos that will redirect
to /web, and we won't wait this redirection. That will lead to a
remaining request taking too much time.
Since the refactoring, SMS is no longer in auto install. This is a shame
because we want to put forward the SMS features. In any case, the user can
always disable SMS from the General Settings if it is too invasive.
FP / AJU request.
Task 2057705
closesodoo/odoo#35946
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
To correctly choose in which account a line should be posted,
we have to know if the partner is a customer or a supplier.
Specification
=============
Keep track of the number of account moves "in" and "out"
a partner has. These counts should be based on the posted
account moves. A customer that has been created from the
'Customer' menuitem will have a rank=1. When a customer
invoice will be created for him, the generated account moves
will be taken into account to compute its rank. The most
invoices we have for a partner, the higher his rank is.
Note: To avoid any concurrent update failures on the partner,
if one transaction has already locked a partner row, the count
update will be skipped that time.
This means the values may be approximative in the database!
The exact values will eventually be correctly computed at
the next successfull try.
Known limitation of this approach: The computation ignores
the set of currently selected companies. Actually, storing
context dependent values in the database is a bad practice,
and is avoided in that case by taking all the companies into
account.
Use the stored fields `customer_rank` and `supplier_rank`
to order partners when searching by name. This allows to show
best customers or best suppliers on top.
To choose if best customer or supplier are shown on top,
the context key `res_partner_search_mode` is used.
The context key can take two values: 'customer' or 'supplier'.
This decision partially reverts/revamps 8766f38 to only use
account moves instead of PO and SO
On actions showing partners, set a default filters to menus to
only display customers (customer_rank > 0) if the string is
"Customers", and only suppliers if the string is "Vendors" or
"Suppliers".
TaskID: 2049131
closesodoo/odoo#35942
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
When you are creating an invoice from the POS, the report route is
called to download the invoice, since changes made in rev: 118190f3b3
The values for ids where empty, so we give them now the correct id list.
closesodoo/odoo#35926
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
This is a performance optimization: modifying a regular record will not
trigger some recomputation on a transient record. Most transient
records are simply waiting to be garbage-collected, so there is no need
to keep their fields up-to-date.
closesodoo/odoo#35909
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
As part of the back2basics, the stage messages were modified to be clearer
* when an opportunity is lost previously 2 separated messages where
created in the chatter (one for the reason, one for the active state)
now, one message is created with both infos;
* new message when an opportunity is restored;
There where also some fixes to typos, and an the probability of a lead
to be successful received a new title "estimated by Odoo".
Task 2026297
closesodoo/odoo#35308
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit provides hard constraints (SQL level) for expense to work in multi company
environement. This is related to a R&D task, the rest of the code need to be adapt, but
freeze is coming.
As expense implies accounting entries, it is required to generate them in the right
company, the company field should then be required.
Task-1999686
closesodoo/odoo#35953
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
- Before the change of `sudo` and `with_user` the code was non sense, it
was doing a `self.sudo(self._uid).check_access_rights('read')` which
was doing nothing.
But now with `with_user`, doing a `self.with_user(self._uid).check_access_rights('read')` breaks the
flag `superuser`.
Meaning that if the code was called using `sudo` it was bypassing the
ACL tests.
closesodoo/odoo#35896
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
- With the new ORM optimizations, the cache doesn't depend on the
context and the key context that are really important for the
computation of a value must be explicitly set.
Setting `force_company` as a determinant will make sure that the
company on the environment is taken in account.
Babel is already taking the language into account while
formating a time delta into a readable string like '2 minutes ago'.
_format_time_ago was put in translate.py file to be able to use
the _ translate class. But it can be placed in misc like other
format function already using babel.
This fix the PR #34624
and is linked to Task ID : 2028059
Task ID: 2055847
Closes PR #35806
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The fields supplier/customer was removed from the partner, then, they
cannot be used in the default for the views.
Avoid the next traceback in the next case:
'''raise ValueError("Invalid field %r in leaf %r" % (left, str(leaf)))
ValueError: Invalid field 'supplier' in leaf "<osv.ExtendedLeaf: ('supplier', '=', True) on res_partner (ctx: )>"```
1. Go to create a new payment for supplier
2. Try select the supplier
closesodoo/odoo#35743
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The setup of IoT Boxes failed since the merge of the task about
barcode scanners: odoo/odoo#35084
We tried to get the list of available keyboard layouts from the IoT
Box. The request was sent from the server, which cannot reach the Box
because it's not located on the same server.
We now perform this task the other way around. When a device of type
printer is created on the Box, we send the list of available layouts
to the server.
TaskID: 1961025
closesodoo/odoo#35925
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Before this commit, a simple optimization was done: if a field was
modified in such a way that the new value is the same as the initial
value, then it is not considered changed.
However, with the new changes in the ORM, it may be an issue, because
doing so loses the intent of the user. If an onchange changes a field,
then the user changes it back, the server is not aware of that fact.
With this commit, we simply keep the field in the list of changes to
send to the server.
opw #2057230closesodoo/odoo#35890
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
As f871908e86 wants to allow simple empoyee
to select any SO on which the expense should be reinvoice, we need a little
adjustement. Indeed, before this commit, the ir.rule of current user are
still apply (bad comprehension of `name_get_uid` parameter), so a salesman
will only be alble to reinvoice on its own SO while an employee can do the
same on any SO.
This commit fixes this strange use case with rco's advice to make this
mecanism work in a cleaner way.
To restrict this `name_search` done in `sudo`, we apply a context key, and
an hardcoded domain (combine with a AND) to minimize the divulgation.
Also, we want the saleman to be able to open and see the SO.
Task-1843241
closesodoo/odoo#35938
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
This commit avoid searching into quants and stock.moves, the quantities
(available, forecasted, ...), for service product in order to speedup the search
on big recordset
closesodoo/odoo#35920
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Christophe Monniez