If there was parameters in the from clause, there was a possible error
when reading progress bar for activities.
eg. grouping product.product by "Routes" raise an error because we have
in FORM clause like:
FROM … ON … AND "product_template__route_ids"."route_id" IN
(SELECT … WHERE … OR ("stock_location_route"."company_id" in %s))
so when we add timezone to parameters, it should be after FROM clause
parameters and before WHERE clause parameters.
opw-2674179
closesodoo/odoo#78867
X-original-commit: 904d0aab204b0ce40d7bc284086c33cbde6f06d8
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* = auth_signup, calendar, im_livechat, snailmail_account, survey, test_mail,
web_editor, website_crm_iap_reveal, website_livechat
The aim of this PR is to improve/fix various flaws and limitation of the current
API, to make it easier to use and more efficient.
Notification are now defined with 3 distinct parts:
- the channel determines which client(s) should receive it
- the type determines how it should be handled
- the payload determines any extra information helpful for handling it
Channel
=======
Business code
-------------
- Record channel is introduced for ease of subscribing to and sending
notifications to specific partners, channels, documents, ...
- String channel is still supported (but it is converted internally to the tuple
channel).
- Tuple channel is still supported without any change (but should be avoided
whenever possible due to its complex syntax).
The channel is no longer sent to the client. When the channel was used for
business purpose, the information it contained has been moved into either the
new type, or the payload itself.
Technical note
--------------
All channels are now internally converted to the tuple (db, ...) channel, which
is necessary for the platform code (saas/sh).
Internally, the bus.bus table is not changed, type and payload are grouped
together into what was (and still is) called message.
Type
====
Type is introduced to uniformize the way notifications are sent and handled.
All existing notifications already had some kind of manually-built type in them.
This is now officially supported at the bus API.
In client code this will allow (to be done in future commits) to register one
handler per specific type, instead of having to iterate and to filter all
received notifications on every handler.
Payload
=======
Payload (ex message) did not change, it can still be anything depending on
business needs.
Few adaptations:
- When the type was included on the payload, the type has been moved to the new
type parameter.
- When the channel was used in business code, its data has been copied into the
payload.
task-1891151
closesodoo/odoo#79201
X-original-commit: 543af27c7d6836ffac9e80ff8490b6ddbd849221
Related: odoo/enterprise#21998
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Since [1] and [2], the mobile app gets this error when trying to login
on v15, while it was working fine in v14 with TOTP enabled.
The 'authenticate' JSON-RPC route tries to authenticate the user and
then call `session_info()`. As no UID is defined, some methods in
`session_info()` raise an exception and an unexpected error is sent:
* `_is_public()` -> "Expected singleton: res.users()"
* `get_web_translations_hash()` -> "lang"
In this fix, this exception is avoided and the proper result is sent,
allowing the authentication process to continue.
Steps to reproduce:
* Try to connect to an account with TOTP on the mobile app (v15+) => BUG
Refs:
[1] odoo/odoo@80d74e7ee0
[2] odoo/odoo@401fc7efe9
X-original-commit: 65dca67ecdcc2228d90781a9f5ccd99f290ada6c
Part-of: odoo/odoo#79182
In activity view, the deadline date that has no timezone is formatted
from UTC to local timezone, so if the timezone is negative, we display
by error the previous day (eg. 24 october instead of 25 october).
With this commmit, we interpret the date in local timezone so there is
no timezone issue.
note: no test added since this only happen on browser with negative
timezone which would be hard to test.
note: this was fixed similarily in 13.0 with 0735547086 but must have
been lost in a refactoring.
opw-2629681
closesodoo/odoo#78938
X-original-commit: 8935899c6fdc21ad6eff9f09af6e474652efbcd2
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
and in the notification zone.
part of task-2634175
closesodoo/odoo#78865
X-original-commit: 88fc69c06e4f1516c8d95812395f1e2fbf10f44c
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce:
1. Log on odoo with a user A on mobile device
2. Log on odoo with a user B on desktop
3. User B call user A
4. User A answer the call and the keyboard popup on the screen => BUG
To avoid this behavior, we disable the input auto-focus when we open a
chat window like other chatting app on mobile devices (like: Signal,
Messenger, WhatsApp...)
closesodoo/odoo#78864
X-original-commit: cf36921df8dff114f26a161c4f9d2f6a05ac2adb
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This reverts commit 4c18e2d09a372e975c2133516cc9bdd1880b2c1b.
This commit makes a barcode qunit test crash non-deterministically,
but quite frequently (50% of the time).
At the time of reverting this commit, we still don't know how this
commit affects this barcode test, but it's urgent to resolve by
revert and understand more in depth what are the causes.
closesodoo/odoo#78827
X-original-commit: 29eb6d3e5ea859955290a2c3f53908b80e16f03e
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
when a message or logenote with attachment(s) is edited attachment gets removed
even if user does not want to delete attachment.
after this commit,
editing message text will update only message and attachment will not be removed.
attachment will be deleted only when user wants to delete it
closesodoo/odoo#78785
X-original-commit: dbd6cf34d3fcf9d66657b68766d2a25ee0d2515b
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit intends to fix two strange bugs encountered while trying to
push a new component into the systray menu:
- MessagingMenuWidget and RtcActivityNoticeWidget were removing their
parent node via DOM manipulations when attached in the DOM. This caused
a crash when adding other items to the systray menu since the deleted
nodes were actually managed by OWL.
- The t-foreach directive in the navbar used indexes as the t-key, which
led mapping items subsequently added to wrong templates.
closesodoo/odoo#78784
X-original-commit: 5f0f80da4fc951954d253c9e45defd591605f556
Related: odoo/enterprise#21829
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Ooming <oomsveta@users.noreply.github.com>
Ensure that all models have their own explicit definition of identifying
fields. Prior to this commit, if a model did not have identifying fields,
the ones in mail.model were used implicitly because of the inheritance.
closesodoo/odoo#78722
X-original-commit: 02fb0c7caaa8a9813e7e78b464710eb772091e44
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Expected Behaviour
When a user reply to a mention (on an invoice, a client profile, ...) in a log_note, and this user answers directly in the chatbox, the answer should be considered as an internal discussion, and so be posted as a log_note.
Observed behaviour
Since V12, when a user reply in the chatbox, the reply is automatically set as a "send-message" reply, which is a issue as the user sends an email to all followers of the discussion while he probably thinks his answer will be visible only by the internal users.
Reproducibility
This bug can be reproduced following these steps:
1. Declare at least 2 users (A and B) and make sure user A handles notifications in Odoo
2. Log as user B, go anywhere in Odoo as user B and mention the user A in a log_note
3. Log as user A, open the mention notification and reply in the chatbox
4. The answer will be noted as a send-message answer, sending then e-mails to all followers ...
Problem Root Cause
As long as the V12 isn't supported anymore, we didn't investigate this version. In V13, the issue comes from the fact the chatbox didn't use the same composer class as the discussion module, and then it's not possible to send a log note from the chatbox. In V14, as the discussion module has been totally refactored, the "error" comes from the arbitrary choice to set "false" as the default value of "isLog" on a general message, which implies that the answer from the chatbox is considered as a "send-message" and not as a "log-note".
Related tickets
opw-2602712
opw-2659484
closesodoo/odoo#78565
X-original-commit: 9e62872561f9914beac8f58f5c3ebed83cd9defc
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
The `distinct` keyword in query
```SELECT distinct res_id FROM mail_message WHERE model=%s```
is not strictly necessary for the correctness of the result, as
it will be inserted inside a sub-query that will be able to use
the main (model, res_id) index of mail_message.
For example, when the `has_message` field is used in a domain
by the website_livechat module[1], the complete query looks
like this:
```
SELECT "mail_channel".id FROM "mail_channel"
WHERE ("mail_channel"."active" = true) AND
("mail_channel"."livechat_visitor_id" = 112678387) AND
("mail_channel"."livechat_channel_id" = 1) AND
("mail_channel"."livechat_active" = true) AND
("mail_channel"."id" in (
SELECT distinct res_id FROM mail_message WHERE model='mail.channel'))
ORDER BY "mail_channel"."create_date" DESC LIMIT 1;
```
In this query, it's obvious that the `distinct` makes zero difference in
the results.
However, the presence of the DISTINCT keyword means that PostgreSQL will
factor the cost of applying that UNIQUE sort in the query planning, and
use MERGE JOIN strategy to avoid sorting multiple times (ok, it could
perhaps guess that distinct is useless here, but we asked for it.)
For a database with millions of mail messages, there can easily be
millions of hits for the generic "all res_ids for model" query, so
the cost of that part will be quite high.
The plan will then look like this (notice the "Unique" step and the cost,
730ms for the index scan + 200ms for the sort):
<details>
<summary>The query plan when `distinct` is used</summary>
```
QUERY PLAN
------------------------------------------------------------------------------
Limit (cost=151528.28..151528.29 rows=1 width=12) (actual time=1021.237..1021.239 rows=1 loops=1)
Output: mail_channel.id, mail_channel.create_date
Buffers: shared hit=767230
-> Sort (cost=151528.28..151528.29 rows=1 width=12) (actual time=998.799..998.801 rows=1 loops=1)
Output: mail_channel.id, mail_channel.create_date
Sort Key: mail_channel.create_date DESC
Sort Method: quicksort Memory: 25kB
Buffers: shared hit=767230
-> Merge Join (cost=3.01..151528.27 rows=1 width=12) (actual time=998.786..998.790 rows=1 loops=1)
Output: mail_channel.id, mail_channel.create_date
Inner Unique: true
Merge Cond: (mail_channel.id = mail_message.res_id)
Buffers: shared hit=767230
-> Sort (cost=2.44..2.45 rows=1 width=12) (actual time=0.043..0.045 rows=1 loops=1)
Output: mail_channel.id, mail_channel.create_date
Sort Key: mail_channel.id
Sort Method: quicksort Memory: 25kB
Buffers: shared hit=5
-> Index Scan using mail_channel_livechat_visitor_id_livechat_channel_id_idx on public.mail_channel (cost=0.41..2.43 rows=1 width=12) (actual time=0.035..0.039 rows=1 loops=1)
Output: mail_channel.id, mail_channel.create_date
Index Cond: ((mail_channel.livechat_visitor_id = 112678387) AND (mail_channel.livechat_channel_id = 1))
Filter: mail_channel.active
Buffers: shared hit=5
-> Unique (cost=0.57..143838.35 rows=614997 width=4) (actual time=0.033..993.210 rows=97187 loops=1)
Output: mail_message.res_id
Buffers: shared hit=767225
-> Index Only Scan using mail_message_model_res_id_idx on public.mail_message (cost=0.57..129884.36 rows=5581595 width=4) (actual time=0.032..730.233 rows=5586467 loops=1)
Output: mail_message.res_id
Index Cond: (mail_message.model = 'mail.channel'::text)
Heap Fetches: 17
Buffers: shared hit=767225
Planning Time: 0.471 ms
Execution Time: 1025.410 ms
(37 rows)
```
</details>
Now, if we remove the superfluous `distinct` clause, for the same
database, data volume, and result, the plan looks like this:
<details>
<summary>The query plan when `distinct` is not used</summary>
```
QUERY PLAN
-------------------------------------------------------------------------------------
Limit (cost=3.44..3.44 rows=1 width=12) (actual time=0.069..0.069 rows=0 loops=1)
Output: mail_channel.id, mail_channel.create_date
Buffers: shared hit=8
-> Sort (cost=3.44..3.44 rows=1 width=12) (actual time=0.068..0.068 rows=0 loops=1)
Output: mail_channel.id, mail_channel.create_date
Sort Key: mail_channel.create_date DESC
Sort Method: quicksort Memory: 25kB
Buffers: shared hit=8
-> Nested Loop Semi Join (cost=0.98..3.43 rows=1 width=12) (actual time=0.061..0.061 rows=0 loops=1)
Output: mail_channel.id, mail_channel.create_date
Buffers: shared hit=8
-> Index Scan using mail_channel_livechat_visitor_id_livechat_channel_id_idx on public.mail_channel (cost=0.41..2.43 rows=1 width=12) (actual time=0.020..0.020 rows=1 loops=1)
Output: mail_channel.id, mail_channel.create_date
Index Cond: ((mail_channel.livechat_visitor_id = 117513256) AND (mail_channel.livechat_channel_id = 1))
Filter: mail_channel.active
Buffers: shared hit=4
-> Index Only Scan using mail_message_model_res_id_idx on public.mail_message (cost=0.57..2.77 rows=10 width=4) (actual time=0.040..0.040 rows=0 loops=1)
Output: mail_message.model, mail_message.res_id
Index Cond: ((mail_message.model = 'mail.channel'::text) AND (mail_message.res_id = mail_channel.id))
Heap Fetches: 0
Buffers: shared hit=4
Planning time: 0.761 ms
Execution time: 0.095 ms
(23 rows)
```
</details>
Total execution time goes from 1000 ms to 0.1ms.
Reference: introduced by 9a01a2953f,
coming from #69812, which was fixing a performance problem.
[1] https://github.com/odoo/odoo/blob/9b224f35f45876c86dc34934379bfa9e8b3e2160/addons/website_livechat/models/website.py#L40-L44closesodoo/odoo#78186
X-original-commit: 3ab87a848c96b284eac3dbbd6f6f2a9ea971876a
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Before this commit: when creating scheduled activity from activity cell
activity type was not passed in context due to which default activity type not
set, to produce: CRM -> Activity View -> Click on existing record of activity
view which will open popover -> click on Scehdule Activity button, this will
open scheduled activity form but it will not have default activity type.
After this commit: when clicking on Scehdule Activity button from activity
popover, default activity type will be passed in context.
task-2568793
closesodoo/odoo#78330
X-original-commit: 17cbafdd1ce4f5f095512677d5b3750e3a8dc889
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Before this commit, it was impossible for a user to invite people to a channel
or a group DM.
This commit add the invite button on the chat windows header only on mobile.
Part of task-2634175
closesodoo/odoo#78267
X-original-commit: 56ab9ffea28dd5f22a74ba269cbd5552c42953e3
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, there were some usages of
RTCPeerConnection.connectionState which is not available on some
browsers, including Firefox.
This commit fixes this issue and make it so that we only use
RTCPeerConnection.iceConnectionState instead.
closesodoo/odoo#78064
X-original-commit: 297442f72e23bc1a03ea857699fcae20b5cd0bbc
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, the server could return outdated information to the
client about the state of their own rtc session.
The server should not return information about the client's own rtc
session as the source of truth is the client-side state.
A case in which this was causing an issue was when a user toggled their
mute state right before their client pinged the server and received
outdated session information before their most recent state could be
sent to the server.
This commit fixes this issue.
closesodoo/odoo#78028
X-original-commit: fe991edd2bca98b58fc5a49494871475c79bc22f
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit will change the way URLs are edited in discuss public view
to preserve URL params in the resulting URL.
Context:
In order to avoid leaking invitation links, URLs are modified in discuss
public view, but this can sometimes hide precious information such as
the debug mode from the URL.
closesodoo/odoo#78019
X-original-commit: 0a3b31c615bb319b4e0d9304e034df3520e8f33c
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Automatically create and open a new channel, then start a call, on click
on the "Start a meeting" button.
Part of task-2651831.
closesodoo/odoo#77946
X-original-commit: cedc8e934bf8c97f94f455389315f9f4c40137c7
Signed-off-by: Samuel Degueldre <sdegueldre@users.noreply.github.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit adds a feature where users can reply to messages of other
users, doing this will show a reduced version of the message that has
been replied to above the message once posted, clicking on this reduced
version will scroll to the original message and highlight it if that
message is already loaded.
task-2362251
closesodoo/odoo#77941
X-original-commit: cec2e69e832072dd699274187ddfa122e29d03f3
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Samuel Degueldre <sdegueldre@users.noreply.github.com>
Before this commit, when an attachment is deleted, there is no notification and
other client do not update the attachment status.
task-2635516
closesodoo/odoo#77937
X-original-commit: aa4d7920574852d0543e22a30fc686a7d41f9867
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit will display the name of the current guest in the thread
view top bar and make it editable.
closesodoo/odoo#77936
X-original-commit: 659c6a83245a396054cf26c204a7fc72fbbb971f
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Click on an attachment from a public thread view will now open it in an
attachment viewer.
closesodoo/odoo#77932
X-original-commit: 550dc40b022cd3b11440a1767df4d857d9fd12a9
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Post a message in the channel each time a guest is added to members of
the channel.
closesodoo/odoo#77915
X-original-commit: bf6af9b629a07d04bf582987b5144a37fa31729e
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Purpose is to assert current behavior as this may change in master. Two
kind of tests are added: performance and multi company.
Task-2661036 (Performance tests data cleanup)
Prepares Task-36879 (MultiCompany Aliases)
closesodoo/odoo#77845
Related: odoo/enterprise#21456
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Let us use existing data for multi-company tests created when calling a specific
method available in mail tools. We may then remove TestMailMultiCompanyCommon
that is used in a single test, with an hardcoded currency_id (hem).
Task-2661036 (Performance tests data cleanup)
Prepares Task-36879 (MultiCompany Aliases)
Part-of: odoo/odoo#77845
Just putting code where it belongs, in sections about access rights / discord
API. After a lot of updated some cleaning is always welcomes. This prepares
future code renaming and improvements.
Task-2661036 (Performance tests data cleanup)
Prepares Task-36879 (MultiCompany Aliases)
Part-of: odoo/odoo#77845
Before this commit, we would reset the audio of a peer before setting a
new one which is not necessary as the track remains the same for the
whole lifetime of the transceiver (and therefore the peerConnection).
Moreover, calling `pause` on the audioElement could lead to a race
condition with the following `play` and lead to a traceback.
closesodoo/odoo#77883
X-original-commit: e0b957cd3cd657ad15168e35fdaaeebccb7be4be
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, the entry in `mailRtc._dataChannels` was not removed
when removing a peer, which meant that `mailRtc._dataChannels` could
contain old closed dataChannels. Moreover, the call to `close()` on the
dataChannel was not guarded, which could lead to tracebacks.
For example, if a peer was removed before creating its dataChannel (like
in crashes or successive connection recovery attempts), `close()` was
called on `undefined`.
this commit fixes this issue.
closesodoo/odoo#77880
X-original-commit: da3fce19157a07fc1abbb6d188746d4a00d3a344
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, when a video track ended unexpectedly, the peers
were not notified that the remote track ended, which made it so that
inactive video elements remained on screen.
This commit fixes this issue.
closesodoo/odoo#77875
X-original-commit: d868582b2b409ec01bc4983429dea723f27f5513
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
* = hr, hr_holidays, sms, snailmail, website_livechat
Message model incorrectly contained data related to a specific component (only
one) even though there can be multiple message components per message model.
This cascaded to adapting related component/models to the same principle.
closesodoo/odoo#76718closesodoo/odoo#77779
Related: odoo/enterprise#20964
Related: odoo/enterprise#21426
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit if you found a message and wanted to open the related record you would need to find it manually by finding the right view and then using the ID stored on the message to open it.
By adding a smartbutton the user can quick-navigate to the related record in a second.
This allows for quickly finding and opening records which is usually handy when debugging things.
Ref Task-2660873
closesodoo/odoo#77675closesodoo/odoo#77803
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Step to follow:
- Create an Asset Models
- Set up the Fixed Asset Account:
Automate Asset -> Create in draft or Create and validate
Asset Model -> The one you have just created
- Create a Vendor bill
Account -> the Fixed Asset Account of the asset model created
Label -> insert a newline
Price -> (do not forget to set a price)
- Validate
- Go to the asset automatically created
- @ mention a user in the chatter
Cause of the issue:
The generated email subject comes from the record_name and it can
contain newlines
Email headers don't allow newlines and an exception is thrown here
https://github.com/python/cpython/blob/60b93d9e4922eeae25052bc15909d1f4152babde/Lib/email/policy.py#L143
Solution
Replace newlines by spaces in the email subject
opw-2522055
closesodoo/odoo#77712
X-original-commit: ed343998d39ff91a3f73cc8012be498d32c91b2f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* = test_discuss_full
Before this commit if 2 persons are joining the call at the exact same time, the
join RPC of each will return the list of RTC sessions without the other person
included.
In more general terms, the server should actually rarely send the full state to
the JS (in this case "use the replace command") because there is no guarantee
that a concurrent transaction is not changing the data at the same time. In
other words, even the python is actually working with partial knowledge
relatively to the database.
Using a DB lock would guarantee it, but we don't want to lock tables and wait on
locks if there are alternatives. In this case it is acceptable to keep obsolete
sessions for a little bit longer, as long as they are cleared eventually.
closesodoo/odoo#77656
X-original-commit: d3a84172fc78f5783f75aa1155f1a25e4f9614b7
Signed-off-by: Samuel Degueldre <sdegueldre@users.noreply.github.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
It could take seconds to annotate a simple stack trace, it is therefore not
suited at all for quick logging as we do in RTC.
It's unfortunate but acceptable to just log the non-annotated stack trace in
that case.
X-original-commit: 8b3495c489c274e878d2a0938ea29b4da17710aa
Part-of: odoo/odoo#77656
This commit removes all the 'extend' initially introduced to avoid code
repetition and ensure visual consistency across Bootstrap and Owl dropdowns.
Despite achieving the desired results, using 'extend' in this context
was seriously impacting the bundle generation time, probably due to an
underestimated amount of Apps' legacy-code applied on these elements.
In order to achieve the same results, the chosen strategy is to add
Bootstrap default classes directly into Owl dropdowns.
Also, it moves code related to bootstrap dropdown in 'webclient.scss',
leaving 'core/dropdown/dropdown.scss' for Owl code only.
Due to the discrepancies between Bootstrap and Owl html
structure, the '.dropdown-item' class could not have been added
directly to Owl's '.o_dropdown_item' itself, without refactoring
the Dropdown component structure.
// ==== Bootstrap 4.6 default Structure ================================
<div class="dropdown-menu">
<button class="dropdown-item" type="button">Action</button>
<a class="dropdown-item" href="#">Another action</a>
</div>
// ==== OWL default Structure before this commit =======================
<ul class="o_dropdown_menu">
<li class="o_dropdown_item">
<span>Action</span>
</li>
<li class="o_dropdown_item">
<a href="#">Another action</a>
</li>
</ul>
// ==== OWL Structure after this commit ================================
<div class="o-dropdown--menu dropdown-menu">
<span class="dropdown-item">Action</span>
<a class="dropdown-item" href="#">Another action</a>
</div>
// ==== web.assets_backend.css Bundle Generation Comparison ============
With all modules installed (enterprise edition over runbot):
Before this commit, bundle took ~2.5s and ~4s to generate and weighted ~322kB (~2.5MB uncompressed)
After this commit, it takes between ~1.2s and ~1.6s and weights ~257kB (~1.6MB uncompressed)
closesodoo/odoo#77649
X-original-commit: 84715436d87bb05b421bc9ccaacda67d07571690
Related: odoo/enterprise#21370
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Co-authored-by: Stefano Rigano <sri@odoo.com>
Co-authored-by: François Georis <fge@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Given that we have a viewport of 320px and, to simplify the explanation,
we discard the height of the <header> (aka. the top navbar).
Since the refactoring of Discuss [1], a global rule was added to the
'.o_action_manager' to allow the flex to shrink the discussion's list
in Discuss on Mobile.
But this rule change the box sizing of '.o_action_manager' as now it
takes the minimum size (e.g. before 3000px became now 320px +/- the
height of the viewport).
Therefore a limit for the sticky-scroll behaviour of control panel is
set at the end of the height of the element.
Then when the viewport goes outside this limit the sticky doesn't work
anymore until the viewport returns before this limit.
(e.g. <= 320px ok, > 320px ko).
The fix is to change the flex basis of the '.o_Discuss_notificationList'
to be 0 which avoids to alter the global '.o_action_manager' and scopes
rules to Discuss' specific classes.
DOM before this commit:
┌───────────────────────────────────────────────────────┐
│ '.o_action_manager' ▲ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ ELEMENT HEIGHT │ │
│ = 'VIEWPORT' │ │
│ 320px │ │
│ ┌────────────────────────────────────────────────┐ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ Control Panel │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ └────────────────────────────────────────────────┘ ▼ │
│ - - - - - - - - LIMIT OF STICKY ELEMENT - - - - - - - │ <- 320px
│ ▲ │
│ │ │
│ OVERFLOW │ │
│ VISIBLE │ │
│ │ │
│ ▼ │
└───────────────────────────────────────────────────────┘
DOM after this commit:
┌───────────────────────────────────────────────────────┐
│ '.o_action_manager' ▲ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ ELEMENT HEIGHT │ │ <- 320px
│ >= 'VIEWPORT' │ │
│ 3000px │ │
│ ┌────────────────────────────────────────────────┐ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ Control Panel │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ └────────────────────────────────────────────────┘ ▼ │
└───────────────────────────────────────────────────────┘
Steps to reproduce:
* Open Odoo on Mobile
* Go to a Kanban view with list height at least twice the screen height
* Scroll to the end of the page (the control panel is hidden)
* Scroll a bit upper => BUG the control panel is not visible until we
scroll in the 'box' of the '.o_action_manager'
Note this behaviour is maybe related to an issue from CSS3 [2]
from MDN [3]
Ref:
[1] odoo/odoo@3fea5b2136
[2] Issue 865 on https://github.com/w3c/csswg-drafts
[3] https://developer.mozilla.org/en-US/docs/Web/CSS/positionclosesodoo/odoo#77660
X-original-commit: fdcfaa7b72a4af0d0c3e308e299638fc8fa19bdb
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
Signed-off-by: rfr-odoo <rfr-odoo@users.noreply.github.com>
Update a specific flow to ensure the record on which session_info is
called has guest in its context. This is needed because session_info
performs some checks on guest to determine if it should add translations
data.
closesodoo/odoo#77433
X-original-commit: bd0940cdbf43131ed8436a5deb3f8afebfbc37ab
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, a user could DM a portal user.
Portal user are not supported and can't chat.
task-2632874
closesodoo/odoo#77568
X-original-commit: a7eda6d7314e7261ddda32620fae817f1d828bae
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
If the name is not known, fallback to the displayName.
closesodoo/odoo#77553
X-original-commit: 50f3581df712d5f2cbb6481f7fcb8c164ebb2da2
Signed-off-by: Samuel Degueldre <sdegueldre@users.noreply.github.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The current threshold seems to high for most people. It is preferable to catch
too much sound and then request people to increase the threshold, than catch too
little and have frustrating experience of not hearing people talking at all.
X-original-commit: 59aa5b3c209bc6717cd95266c62fc8b1abb68475
Part-of: odoo/odoo#77553
Nicolas Lempereur