The discuss application starting process is strongly asynchronous.
However, it relies implicitely on the fact that the widget is not
destroyed in its starting process. For example, if the widget is
detroyed before the updateChannel method is called, then any call to the
chat manager service will return undefined and the widget will crash.
When discuss is destroyed exactly between the start and the end of the
creation of its search view (which is asynchronous), then it is possible
to have a crash, because the search view will be destroyed when the
do_search method is called.
Note that we had to fix discuss mobile as well:
The _setChannel method is supposed to return a deferred, but the mobile
override did not return it. As a result, a test in the mobile suite
failed because this.alive takes a deferred in argument.
Purpose
=======
The method compute is annoying for the following reasons:
- 'compute' is difficult to grep
- Developers don't understand that they can specify the company and
the date on which we want to convert the amount. This is quite
error prone because if these parameters aren't specified, they are
set by default to the company of the current user and the current
date (today).
- Passing parameters is the context is not a correct way to call a method.
Furthermore, using with_context is not really good for the performance too,
as the record as to be rebrowsed, the computed fields have to be
re-evaluated
Specification
=============
- Introduce a new method '_convert'. This method takes 2 more
parameters: 'company' and 'date'.
- Deprecate 'compute' and '_compute'. Log a warning to notify that we
should use '_convert'.
Here is the issue that initiated this work: the bank reconciliation tour
sometimes failed in community. The reason was that the discuss client
action seemed to be loaded after the tour started, and interfered with
the second step of the tour.
What happened exactly was the following:
- web client is loaded
- initial action is starting (but not complete) (this is discuss)
- tour manager is loaded and starts the reconciliation tour
- the reconciliation tour changes the url to trigger an hash change
- the web client calls loadState on the action manager
- the action manager perform a doAction with the tour url
- the discuss client action is now ready, and replace the reconciliation
action
- the tour is broken.
The underlying cause is really a generic problem: the action manager
does not add the client action starting process in its 'dropprevious'
concurrency primitive. This is probably not really an issue for the
act_window actions, since they have custom loading code that make sure
the loading process is put in the drop previous, but it is definitely a
problem for all client actions.
The solution is quite simple, and should also protect the act window
renderers: put the action controller in the drop previous
In Less, the size_class XL is now defined and can be used in media-queries.
It is also added in JS for the sake of consistency.
This new size is needed for a fix in enterprise.
Whenever a widget is destroyed, it should be as inactive as possible.
Before this commit, it could happen that a widget was destroyed after
the willstart method, but before the start method. In that case, bad
things could happen.
For example, the discuss client action tries to look up some information
into the session, with the getSession method. This causes a crash
whenever the widget is destroyed.
With this commit, we introduce a new 'fail fast' feature to our qunit
test suite: when it is activated, the qunit test suite will immediately
stop after the first failed test.
It is accessible as a flag in the url (failfast), or by clicking the
checkbox in the UI. It is currently not activated by default.
Note that this commit also change the url for the runbot phantomjs test
in order to activate this feature. This allows us to increase the global
timeout for the js test suite without fear!
Note: original work of @dbh-odoo was to have + and - buttons on the
editor overlay but specs changed to use a standard dropdown (the work
of @dbh-odoo was thus adapted for this).
See task-46094
Closes https://github.com/odoo/odoo/pull/22197
Currently, when the button "More" is opened, the HTML elements of their
items are located before the button, instead of being after. That means,
when navigating using the keyboard, if the button is opened ant `<tab>`
is pressed, the focus will not go to the menu items.
This change causes the HTML elements of the menu items to be moved, from
before to after the button "More".
PR #23865
With this commit, the menu item for editing a view in debug mode has been
changed.
Instead of "Edit List View", it is now "Edit View: List".
That way, the code is shorter, generic, and translatable.
Exception to above changes: search view, which is unchanged
(it remains "Edit Searchview")
This commit add the reference documentation for the new dashboard view.
In an ideal world, this should be done in the enterprise repository, but
our documentation system is not extensible that way.
With this commit, the fields many2one are not always measures in pivot
and graph views. By default, they are *not* measures.
In order to have them as measures, we should pass `additionalMeasures`
as a param to any of the views, which contains a list of fields to consider
as measures.
example:
Suppose a model with the following fields:
- `product_id` (many2one)
- `categ_id` (many2one)
- `sold` (float)
By default, only the field `sold` is a measure
in a graph or pivot view.
In order to pass `product_id` as a measure of
a graph view, you should instantiate this view
as follow:
``
var viewInfo = /* ... */;
var params = {
additionalMeasures = ['product_id'],
};
var graph = new GraphView(viewInfo, params);
``
An exception to the rule above is when the many2one field is of type `measure`
in the arch: this field is set as the default measure of the view, therefore
it is implicitly added as an additional measure.
We recently added the possibility of aggregating the graph view on a
many2one field (with count distinct operator). This is useful, but then
a rare situation could happen: the view could be grouped by the same
field.
In that case, there is a name clash in the read_group, and the result
will be that the [id, nameget] of a m2o field will be used as an
aggregate.
The readgroup method should be improved (its API is a mess), but
meanwhile, we have a solution for this issue: if we group by a m2o, then
it is guaranteed that each group has an aggregate value of 1 for the
same field.
With this commit, we add the possibility of using many2ones as measure.
The way a many2one is aggregated is by using the count distinct
operator.
Some care had to be done to gracefully support the situation when a
pivot view is grouped by a m2o field F, and the same field F is used as
a measure.
Currently a lot of people are automatically added as followers of expense
reports. However most of them (managers notably) can choose what to follow
using subtypes on the department. We should avoid adding too much people
as following records should stay an active choice made by users.
From now on auto subscription works on
* employee of the expense report, if he has an user;
* responsible of the expense report, that is the expense manager or the
manager of the employee;
Expense report creator is not follower of the expense report by default
anymore, as previous values should be sufficient to ensure people having
to work on the expense report are already followers.
This commit is related to task ID 1819541.
User notifications are defined as
* notes;
* pushed to user Inbox or email through classic notification process;
* not linked to any document, meaning model and res_id are void;
When pushed in user's Inbox they are currently displayed with a gray
background like all notes. However UX experts think it should use a white
background to be easier to spot in chatter. This commit makes it work.
From now on discussion and user's notifications are displayed using a white
background. This commit is related to task ID 1829872.
Activities are quite personal and linked to daily jobs of people using it.
Being notified of all activities is therefore not considered as default
behavior and should be a choice done by users. Subtype linked to logged
activities is now not followed by default anymore. It is still configurable
through subscription widget or parent subscription (project/task for example).
This commit is linked to task ID 1824141.
Currently when posting a message if the author has no email address an user
error is raised. Indeed as posting a message goes through the process of
creating notifications and sending emails an email address is required on
the user.
In saas 11.2 a _message_log shortcut has been added to log notes and in saas
11.3 a message_notify has been added to notify peopel of a custom content.
Those methods should have the same behavior when author has no email.
Currently there is a crash when trying to encode its email. After this commit
an exceptions is raised like classic post.
This commit is a manual forward-port of 3a978cc64e6b1d8aca7cfd5d4e319bcb302dd262 as well as an improvement
to fix the newly-introduced message_notify method.
This merge goes through various cache invalidation done in mail application
in order to effectively limit it to records and/or fields to invalidate.
Purpose is to avoid having too much cache invalidation that causes to
fetch data again, therefore adding computation and queries to various mail
features. See sub commits for more details about the changes.
All performance tests are improved of a few queries as there is less data
to fetch again from database. On overall community runbot this leads to a
gain of about 16K queries when installing all 205 modules. This merge is
related to task ID 1834147. Closes#24061 .
This commit proposes to limit cache invalidation at some cases that will
trigger some behavior change when dealing with mail messages :
* creating messages linked to a document;
* update model or res_id of a message;
* updating notifications, as notified people could change some computed
fields on the record;
This commit also invalidates only mail-related fields as updating messages
should not invalidate other things than some computed fields linked to
mail.
Cache invalidation when subscribing people has been added at e6f038a821.
Indeed subscribing partners to a record may lead to an access right update
as some of them are based on followers. This is why a cache invalidation
is necessary to avoid access rights issues.
However subscribing people to a record should change their rights only on
the records involved in the subscription mechanism. We can therefore give
ids to the cache invalidation to limit to updated records.
Cache invalidation is also limited when writing on followers if writing
on model, res_id or partner_id fields. Indeed changing subtypes or
channel of a subscription should have no impact on cache and access rights.
Cache invalidation done manually in _message_subscribe is not necessary
as subscription create or update mail.followers records since f9c210923d.
Create and write of mail.followers records already ask for cache invalidation.
It is therefore not necessary to invalidate cache twice.
This commit allows to save a few queries on some tests, notably about
activities that deal with subscription and messages. As cache is now kept
it is not necessary to refetch some data, leading to a few query gain. We
gain about 1K queries on com runbot.
A side effect of limiting cache invalidation is that some unit tests require
a manual cache invalidation to have up to date results. Indeed record not
being up to date in cache was hidden by the invalidation we just removed.
When notifying partners or channels of a message, a cache invalidation is
currently done if the message has a parent. This invalidation has been done
when migrating the mail module at the new API at 4b122ad41d.
In that time notifying people of a message lead to the creation of
notifications of the parent message, if any. It was due to the chatter
being threaded and therefore displaying message with their header message.
Adding notifications for the parent was necessary to avoid access rights
issues when fetching parent message data. Indeed as being notified is one
of the rule to see a message record adding notifications was done. A cache
invalidation has therefore been added to clean the message cache and ensure
everything was fine.
Commit 88b8cd0587 changed the way notifications are modeled in Odoo.
Notification on parent message was removed and access rights changed. Threaded
mode for Chatter has also been removed. However cache invalidation has been
kept probably by fear of removing it.
It does not seem to have any viable reason to invalidate cache when a message
has a parent. Posting a message does not push other messages in users's Inbox
meaning there should not be any issue with the cache preventing to see
messages.
Removing this cache invalidation allow to gain queries in performance tests.
It has an impact on each process involving message creation which is quite
common in Odoo.
repro : open any editor (like tasks), empty its content and hit SHIFT+TAB
before this fix: you get a traceback
after this fix: you don't get a traceback
1. Added the ability to navigate within the kanban view using UP,
DOWN, LEFT and RIGHT keys.
2. By defaults, the focus should be set on the search input field.
3. From the search input field, using the DOWN key, the focus goes
to the first card of the kanban
4. From the search input field, using TAB key, the focus goes to the
create button
5. From the create/import buttons, using TAB or DOWN key goes to the
first card of the kanban, then UP and DOWN keys moves the focus
from card to card in the same column or if it is not a grouped
view from left to right.
6. In grouped view, LEFT and RIGHT keys moves the focus to the next
column
7. When on a card, hitting ENTER opens the view of that card.
Not included in this commit
1. Memorize the position on the kanban when opening an card, than restoring
when going back to that kanban
1. Added the ability to navigate within the List view using UP and
DOWN keys.
2. By defaults, the focus should be set on the search input field.
3. From the search input field, using the DOWN key, the focus goes
to the list
4. From the search input field, using TAB key, the focus goes to the
create button
5. From the create/import buttons, using TAB or DOWN key goes to the
first row of the list, then UP and DOWN keys moves the focus from
item to item in the list.
6. When on a row, hitting ENTER opens the view of that row.
Also in this commit
1. When on the first row, hitting the UP key does nothing
2. When on the last row, hitting the DOWN key does nothing
Not included in this commit
1. Memorize the position on the list when opening an row, than
restoring when going back to that list
2. Navigation on grouped list using the keyboard
This commits aims at adding an accesskey (a shortcut) to all buttons
in odoo. This is done by either by assigning an accesskey in the view
XML or by automatically assigning a key to the buttons using the first
available (not yet assigned as a shortcut key) letter of the text of the
button, failing that we use the latin alphabetical order to find the
first unused key.
Included in this commit:
1. Using the ALT key, automatically assign
2. When the ALT key is pressed, show the assigned shortcuts
3. Assign a number to the menu items (enterprise)
4. Activate number accesskeys without using SHIFT
5. Extra logic to support the activation of the alphabetical
accesskeys without needing to add the SHIFT key in the key
combination (except for Firefox on linux)
6. Assign a fixed accesskey to the search field
Not done:
1. Executing the primary action on dialogs using SHIFT+ENTER
2. Show the input using TAB on the appswitcher screen
Things to consider:
1. Fixing more access keys on forms that share the same features
(b.e. Validate in customer invoice and vendor bills)
2. Not assigning keys to the chatter section
The goal of this commit is to allow fast entry of the same model using
the keyboard for navigating through the form once, by blocking the user
from advancing in the form if there is a required field or once they
went through the form once to get them to a primary action (button)
This commit includes the following changes
1) Enable moving forward from field to field using the TAB key
2) Entering the one to many and many to many using the TAB key
a. When entering it, set the focus on the "add new line" link or
button
b. When adding a new line, set the focus on the field visible
editable field of the new line
c. Discard adding a new line with ESC key
d. If the user leaves the first field empty and uses TAB, we
will cancel the adding of a new line and move to the next
field of the form
3) When a field is required and not filled in, do not allow the user
to move out of the field using the TAB key (the user is still
allowed to use the mouse though), mark the field as invalid
instead
4) After going though the form once, using the TAB key on the last
field will move the focus to the first primary button of the page
5) When the focus is on a primary button (EDIT/SAVE), the user cannot
move the focus forward using the TAB key. Hitting TAB again will
display a tooltip telling to hit ENTER to activate the button.
The mouse is still available to move the focus.
6) When the user saves, the focus is placed on the first primary
button of the form renderer (like VALIDATE for a new invoice)
7) On dialogs, primary buttons should stop the users from moving out
of them, and showing a popup if the user tries
8) When closing a dialog, the focus will be moved back to the widget
that opened it.
This commit does not include the following features
1) Navigation with the keyboard on a selection one to man
2) Navigate between tabs in a form using the keyboard
3) Cancelling the adding of a new line in a many to many using the
ESC key do not set the focus correctly
4) Enhancing the focusses fields (like blue underline)
Since Python 3.2, close_fds parameter is True by default on POSIX
platforms. On Windows, it's set to False when one of the standard descriptors
is set.
This commit will give the opportunity to run phantom js tests on
Windows.
There was a filter 'Bom Components', that didn't filter anything. So we
make it work to show the products/product templates that are used as
components in BOM.
We've also added a filter 'Manufactured Products' that show the
products/product templates that have at least one BOM
TASK-54350
Before this commit, badge, user,... was available when a forum is archived.
Now we display a msg to explain to the user that the forum has been archived.
Related to task-33955
Commit 565ab7a2e4 added a bypass to message subscription because some auto
subscription is done without the right to edit the record. However there
are two issues with this commit
* message_subscribe API changed and code tried to pass now removed parameters;
* sudo-ing without checking any access rights before is a security issue;
This commit fixes the call and add an access right on read. As few people
(mostly HR officers and managers) can read a leave request it solves the
issue of auto subscription while a better solution is found.
We need to have a clear distinction between holidays managers and
holidays officers.
For this a number of improvements have been done in hr_holidays.
For more informations about the changes see the docstrings of hr.leave
and hr.leave.allocation.
Task #34222Closes#19270
Query count for some mail tests is not always the same for a given test.
This leads notably to runbot being randomly red although there is no real
error. This commit lessen the issue of having red runbot or wrongly
incremented tests by using the recently-introduced margin parameter on
performance tests.
Some work is still ongoing to find why some tests are not completely
reproducible. In the meantime let us have some warnings instead of errors.
Manual forward-port and improvement of 81a0852077.
Purpose of this commit is to avoid errors for some performance tests that
have a slightly variable number of queries. Indeed some tests in test_mail
module vary of 1 or 2 queries due to a behavior still not found that does
not seem deterministic.
This should not be considered as a real error, but should not be considered
as completely valid. This is why a margin is accepted in some tests that
will raise a warning instead of an error. This warning tells people to
check if they have increased the query counter or if it is due to a random
effect in query count.
This is a manual forward-port of saas-11.2 commit 3fe0ee5ae6 .
Remove the support to replace emojis by images. Most browser
now support colored emoji or at least black and white emojis.
The emojis list have been updated to ensure a correct support
for most os/browser.
Users have the possibility to install fonts localy if their os does not
have one of the default emoji font installed.
After default os emoji font, one of twemoji, emojione or noto color
will be selected.
The emoji list is now hardcoded in js in order to reduce the number of
records in shortcodes.
Also include a small fix for livechat to display message field when rating
is bad.
Task #36898
PR #23689
Géry Debongnie