| Age | Commit message (Collapse) | Author |
|---|
|
When a user sends a plaintext email to a mail-enabled channel, the
rendering of this message in Discuss have present a horizontal scroll
when the text contains long sentences.
This commit fixes it by enabling wrapping of the line's word to fit its
container size and prevent horizontal scrolling.
Note: the required CSS rules were already present since odoo/odoo@0e7e18ff71f3b490522358fa689ada7635dcd26a
but a wrapper element (with the class `.o_thread_message_content`) was
introduced in odoo/odoo@4685e4bc7f19f964697bf0dbd7dfdf254b6c5628 and
merged between the testing of the fix above and its actual merging in the
Odoo codebase, making it ineffective. We only have to properly re-enable
it.
opw-2341485
Related task ID: 34931
closes odoo/odoo#59689
X-original-commit: a8b64a74ef5575b783d1b314616f0a89bdce3732
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
|
|
This commit is a significant rewriting of client-side discuss, chatter,
chat window, and messaging menu using OWL. The behavior should be broadly
the same, with some slight functional changes here and there.
From a technical standpoint, the code of messaging is mainly organized in 2
main groups of modules:
- models, which are logical entities that depict the client-side state of
messaging as a whole.
- components, which are in charge of displaying information from models.
This refactoring also introduces new JS guidelines regarding folder structure
(/static) and naming rules for JS modules.
Community PR: https://github.com/odoo/odoo/pull/39023
Enterprise PR: https://github.com/odoo/enterprise/pull/6249
Task-1914207
This PR is a collaborative work by Alexandre, Julien, Sébastien and Xavier,
with the precious help of Lucas to speed it up towards the end.
closes odoo/odoo#39023
Related: odoo/enterprise#6249
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Co-authored-by: Alexandre Kühn <aku@odoo.com>
Co-authored-by: Julien Giannone <jgi@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
Co-authored-by: Xavier Dubuc <xdu@odoo.com>
|
|
The purpose is to have more common code for failure and notifications, with less
override in `sms` and `snailmail`.
task-2176017
closes odoo/odoo#44170
Related: odoo/enterprise#9140
Related: odoo/upgrade#918
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
|
|
This reverts commit ff1c35513aecef5fbc30f7c2f3834450e719714e.
closes odoo/odoo#41480
X-original-commit: 116057b26e71db4692280463669f3e80d813ddcc
Related: odoo/enterprise#7110
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
FontAwesome 5 introduced new names for some icons as described on
https://fontawesome.com/how-to-use/on-the-web/setup/upgrading-from-version-4#name-changes
This commit replaces the old names to the new ones.
closes odoo/odoo#35826
Taskid: 2050241
Related: odoo/enterprise#5180
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
Revision on https://github.com/odoo/odoo/commit/9a66619db33fca5f0cb81d9f6bfeb0fb0290cf68
Commit above improves the web client startup by not having to wait
for discuss widgets to fully load beforehand.
However, it introduced an issue with chatter when the 1st rendering
happens before messaging becomes ready: it displays
"Creating a record..." instead of the whole history of messages.
This happens because when messaging is ready, it updates data from
the chatter but it does not trigger a re-render.
This commit fixes the issue by triggering a re-render on messaging
ready. When messaging is not ready, thread field now displays
"Loading..." instead of the message "Creating a record...".
Task-Id 2078193
closes odoo/odoo#38751
X-original-commit: 93bdd7c91095025f4d6e7a058e0ab1c4e1a0ad60
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
|
|
Since 1d766c067d2a76efe272de0ba71ca5b23ffbf57b the attachment icon was
missing when it wasn't a pdf or image type file.
opw-2064128
closes odoo/odoo#37687
X-original-commit: c44cec7e5ed9de3be495eb44b351eda6b0f6aeee
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
|
|
There are too many image sizes. Since they are stored resized this takes time to
generate when saving a new image, it's more rows on the attachment table, more
files on the disk, ...
64px is close enough to 128px that it can be removed without a big impact on
download size.
It will even reduce download and number of requests when both images are
displayed because now only one has to be downloaded and then benefit from cache.
The difference between the two is typically around 1.5kB which is negligible
these days, especially when the request overhead is around 0.5kB already, not
even taking into account other factors such as latency.
If a 64px image must absolutely be returned, it is still possible to pass the
size parameters to the image route. But the current guideline is to handle
resizing in the views when necessary.
Views
=====
- remove width and height attributes when existing CSS rules are overriding them
(eg. `.oe_kanban_avatar` in the right context)
- add CSS rules instead of width and height attributes when possible
- use `object-fit: cover;` where width and height are forced to avoid distortion
of non-square images
- for products, use `object-fit: contain;` instead, keep ratio but without crop
- add new CSS rules where the expected size was max 64px*64px before due to the
image size itself
- remove `img-fluid` where using size classes to avoid conflicting rules
task-2060865
closes odoo/odoo#36147
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
|
|
closes odoo/odoo#36721
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
|
|
|
|
This commit adds a new mailbox in the Discuss app called 'History'.
Messages that have been marked as read are moved to 'History'.
Notifications are required to link history messages to users. So
notifications are now deleted after they are more tha 6 months old.
This means History mailbox keeps less than 6 months old messages.
Note that this feature only works when user notifications are handled
in Odoo. This can be set in the user preferences, under the
"Notification Management" section.
Task-ID 402597
|
|
Revision on https://github.com/odoo/odoo/commit/07a261db7196d3f7aa7d50d98575c5b6efca9242
When a user is offline, the icon status should be an outline bullet.
However, since the commit above, the offline icon was a plain bullet.
Also, the offline icon is hidden when displayed next to user avatar.
Task-ID 1957966
closes odoo/odoo#31970
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
|
|
|
|
- correctly align 'seen' icon
- purple 'seen' icon
closes odoo/odoo#31240
|
|
In a chat window with a single usert (dm_chat) the ooo status of the
other user is displayed on the top when set.
Task: 1856205
|
|
This commit adds the seen icon next to a message for all channels
except livechat.
It tracks received and seen messages for all members of the channel.
Icon is either 1 or 2 check(s) ('v' or 'vv').
Those are the different states of this 'seen' icon:
ICON: DESCRIPTION:
no check .................. no one has received the message.
1 check ................... some members have received the
message, no one has seen it.
2 checks (greyed-out) ..... some members have seen the message,
some or everyone has received it
2 checks (green) .......... all members have seen the message
This icon is not shown for messages preceding the last message seen
by everyone, in order to reduce visual noise.
Task-ID 1881001
|
|
With this commit, the UI for "is typing..." notifications
has changed.
** before **:
In Discuss & chat windows, "is typing..." notification bar
at the bottom of the thread, inside the conversation.
** after **
In chat windows, animated '...' next to conversation name.
In Discuss, animated '...' next to conversation name in sidebar,
and text below the composer.
Task-ID 1881001
|
|
Feedback should be the first part of the message without title
to make it more concise.
If the activity has a note, the note should be displayed
but after the feedback.
We can also remove the field feedback that was not so useful
since it was only written just before unlink. Feedback is now
passed as another parameter to the template.
Task: 1918392
closes odoo/odoo#29605
|
|
* mail
|
|
|
|
Only o_thread_message_email_exception red envelope was clickable.
We should be able to resend bounce too.
|
|
This commit improves the style of the tooltip on the mail envelop
icon next to a message related to an email. To do so, we have removed
existing CSS and custom tooltip UI and replaced them with boostrap
popover.
This commit also removes most flickering issue when mouse hovering
on gaps between the tooltip and message icons.
Note that there are still corner cases that produce flickers.
This is unfortunately a known issue with bootstrap 4, as this glitch
can also be observed on bootstrap website.
Task-ID 1879282
Closes #26546
|
|
Revision on https://github.com/odoo/odoo/commit/4fa071339a8f381b1336fe326577c9decc04a1e1
There was a typo in the style of the 'is typing...' notification bar,
which resulted in applying the wrong sticky behaviour to ASC and no
sticky behaviour at all for DESC.
This commit applies the correct sticky behaviours to the notification
bar in both configurations:
ORDER: ASC DESC
+--------[top]--------+ +--------[top]--------+
| | | |
| (older messages) | | (newer messages) |
| | | |
visible top ----> |- - - - - - - - - - -| |- - - - - - - - - - -|
| | | X is typing... |
| ... | | ... |
| message i | | message i + 1 |
| message i + 1 | | message i |
| ... | | ... |
| X is typing... | | |
visible bottom ----> |- - - - - - - - - - -| |- - - - - - - - - - -|
| | | |
| (newer messages) | | (older messages) |
| | | |
+------[bottom]-------+ +------[bottom]-------+
|
|
Before this commit, the 'is typing...' notification bar was sticky
to the bottom of the thread, independently of the ASC or DESC mode
order of threads.
This is okay for ASC, but not for DESC: it should stick to the
visible top of the thread for DESC.
As a result, this notification bar was always at the top of the
thread, without the 'sticky' behaviour:
+--------[top]--------+
| X is typing... |
| |
| (newer messages) |
| |
|- - - - - - - - - - -| <---- visible top
| |
| ... |
| message i + 1 |
| message i |
| ... |
| |
|- - - - - - - - - - -| <---- visible bottom
| |
| (older messages) |
| |
+------[bottom]-------+
With this commit, the 'is typing...' notification bar sticks
to the visible top of DESC threads:
+--------[top]--------+
| |
| (newer messages) |
| |
|- - - - - - - - - - -| <---- visible top
| X is typing... |
| ... |
| message i + 1 |
| message i |
| ... |
| |
|- - - - - - - - - - -| <---- visible bottom
| |
| (older messages) |
| |
+------[bottom]-------+
|
|
With this commit, most threads show an indicator when a member is typing
something. e.g.
"Mitchell Stephens is typing..."
Supported threads:
- DM
- (public & private) channels
- Livechat (Website & Backend)
Unsupported threads:
- mailboxes (e.g. 'Inbox')
- document thread (= 'Chatter')
- support channel (with `im_support` module)
Some technical details:
- This is a mix between 'start'/'stop' and 'regular notify' strategies.
- On typing text in composer: notify 'start typing' to all members of
thread.
- On clearing text in composer: notify 'stop typing' to all members of
thread.
- A member can only notify once every 2.5 seconds to the server when he
starts or stops typing something (throttled, buffered notify call).
- On receiving a message from someone that is typing: determine that he is
no longer typing.
- On non-empty and unchanged composer text for 5.0 seconds: automatically
notifies all members of thread that he is no longer typing anything.
(This is like a 'soft / cooperative sender' timeout).
- On non-receiving a typing notification of someone after 60 seconds:
determine that he is not longer typing something (This is like a
'hard / receiver assumption' timeout).
- When some types for more than 50 seconds straight: notify that he is
still typing something (again and again every 50 seconds).
- When two or more people are typing something (Multi-User channels), it
displays at most 2 typing users (ordering rule: longer typers first):
"Mitchell Stephens, Marc Brown and more are typing..."
- Timing summary:
- Usually 2.5 seconds uncertainty.
- Up to 5.0 seconds uncertainty on typer inactivity.
- Up to 60 seconds uncertainty on typer page reload / browser tab
closed / etc.
Future Improvements:
- Detect page reload or browser tab close with loose of longpolling
connection
Task-ID 28188
|
|
- no more bootstrap `o-flex` mixin
- no `$gray-light` (replaced with `gray('600')`)
- replace event `click` with `show.bs.dropdown` for dropdown
- use `!important` on previous `hidden-xs` (because `d-*` use `!important`)
|
|
This commit makes a lot of small improvements of the JS of mail and
related modules.
A. Mail Manager
---------------
im_support:
- [REF] Slightly more robust way to determine a support
message, so that it more reliably falls back on
default kind of message (i.e. support channel UUID
should be clearly set).
mail:
- [REF] Improved method names for readability purposes.
Some examples:
- `fetchFromServer` becomes `fetchMailStateFromServer`
- `_initialize{*}` becomes `_update{*}FromServer`
- `_isModerator` becomes `_isMyselfModerator`
- [REF] Use 'template' pattern design to make Include on
Mail Manager much more robust. In particular,
the flow is always as follow:
1. Initialize internal state.
2. Listen on buses.
3. Fetch mail data from server.
- [REF] Improved workflow for thread window workflow
(Shorter & more readable).
B. Mail Tests
-------------
- [REF] Thread Window Tests crashes with clean message when
there are some thread windows open before running the
tests.
C. (Model) Message
------------------
- [REF] Improved method names for readability purposes
(e.g. `isAuthor` becomes `isMyselfAuthor`).
D. (Model) Thread
-----------------
- [REF] Improved `init` parameters on each kind of thread.
- [REF] 'Thread With Cache' has been renamed to 'Searchable
Thread': it embraces all kinds of threads that can
be used with the search view.
- [REF] 'DM' has been renamed to 'DM Chat' (for clarity).
- [IMP] New Livechat model in the backend.
- [REF] No more direct instances of the Channel class: public
and private channels are now 'Multi-User' channels,
while DM Chat and Livechat are 'Two-User' channels:
This change has been made so that instances of classes
always have direct classes as "leaf" in the Class
modeling. It eases making changes to a certain model
without being too constrained by another model.
- [REF] As a consequence of above changed, the method `isChat`
has been renamed to `isTwoUserThread`.
This is to avoid confusion with the terminology
'chat', which is more like a shortcut for 'quick real-
time conversation'. In other words, the property of
'chat' depends of the way to interact on a thread, not
of the intrinsic type of the thread.
Still, some parts have kept the terminology 'chat',
such as in the systray messagin menu.
- [IMP] Added `message_added` and `message_posted` hooks,
which may be useful to easily hook on those events.
E. Thread Widget
----------------
- [REF] Now uses a `mail.model.AbstractThread` for the
rendering of a thread, instead of a list of
`{mail.model.AbstractMessage}`.
- [FIX] Stick thread scroll height to bottom on new rendering,
if it was previously at the bottom of the thread.
- [REF] Option ORDER has its meaning changed: it now refers
to the chronological order of messages in the thread,
in which DESC means 'from top to bottom', while ASC
means 'from bottom to top'.
- [REF] Improved doc on templates, in particular with the
option `ORDER`.
F. Thread Window
----------------
- [REF] Moved more logic to thread windows, which were
previously in Mail Window Manager.
- [REF] Now hides the thread widget attribute. So instead of
`threadWindow.threadWidget.isAtBottom()`, it uses
`threadWindow.isAtBottom()`.
- [FIX] New received messages when not having focus on Odoo
tab should always make the corresponding thread
windows "passive" (i.e. windows that keep threads
unread until click on them).
- [FIX] Blank thread window (i.e. 'New message' TW) correctly
opens Discuss with 'Inbox' when clicking on 'Expand'
Button in the title
- [FIX] Do not display the composer for channels with property
'mass-mailing' set in thread windows.
G. (Website) Livechat
---------------------
- [REF] Some `trigger` have been turned into `trigger_up`.
- [REF] Some logic has been moved to models (e.g.
`{im_livechat.model.WebsiteLivechat}`), from
`{im_livechat.im_livechat.LivechatButton}`.
- [FIX] New messages should be received in real-time. The
longpolling was broken with a recent refactoring on
bus service (6448420c5dd160470e465dee7729d19d8d5e7bab).
|
|
See previous commit for more explanation.
|
|
Odoo used to declare two main colors: primary and optional (which are
purple and turquoise in enterprise). Those were respectively assigned
to the 'primary' bootstrap variable and the 'btn-primary' bootstrap
variable.
BS4, however, does not allow to have a different primary color for
buttons. Instead, the 'primary' color is used for all 'primary' related
components and utility classes, same as for all other colors. So, if we
want to keep our enterprise buttons green, our 'optional' colors had to
become our 'primary' color. The old odoo primary is then renamed to the
'odoo' color.
The palette of grays is now larger by default and is numbered from 100 to
900 alongside the $black and $white variables. The equivalence for older
variables and the way we used them is:
$gray-darker -> gray 900 (unused before)
$gray-dark -> gray 900
$gray -> gray 700
$gray-light -> gray 600
$gray-lighter-darker -> gray 400 (the old variable was created by us)
$gray-lighter-dark -> gray 300 (the old variable was created by us)
$gray-lighter -> gray 200
Fortunately, the 'lighter' variations we created fit well in the default
BS4 system ! Unfortunately, our $gray-lighter which carried the same
function as $gray-200 (see above) is very close to the new default
$gray-100 and quite distant from the new $gray-200. This will be handled
in the next commit.
|
|
media queries that target a specific screen size handled by bootstrap
have now a more convenient way to be defined:
```
@media (min-width: $screen-sm-min) { ... }
->
@include media-breakpoint-up(sm) { ... }
```
```
@media (max-width: $screen-sm-max) { ... }
->
@include media-breakpoint-down(sm) { ... }
```
```
@media (min-width: $screen-sm-min) and (max-width: $screen-sm-max) { ... }
->
@include media-breakpoint-only(sm) { ... }
```
```
@media (min-width: $screen-sm-min) and (max-width: $screen-md-max) { ... }
->
@include media-breakpoint-between(sm, md) { ... }
```
Also, bootstrap has changed the values for its default screen sizes:
------------------
| BS3 | BS4 |
------------------
0 | XS | XS | -> Portrait Mobile
576 | / | SM | -> Landscape Mobile
768 | SM | MD | -> Portrait Tablet
992 | MD | LG | -> Landscape Tablet / Small Desktop
1200 | LG | XL | -> Desktop
------------------
While it is possible to configure BS variables to behave as BS3, we took
the decision to keep the BS4 variables untouched. BS4 system seems
indeed better and having the purest bootstrap possible is better for
Odoo to be used as a framework.
|
|
BS4 do not provide vendor prefixes scss mixins anymore as it is meant
to be used with the 'autoprefixer' library. As we only support the last
version of every major browsers in Odoo, we took the decision to not
use the library as it was also complex to integrate in Odoo. We decided
to do the library's work by hand if it ever become necessary.
|
|
When a mail is in failure state, a red envelope appears next to the message
in a thread but it was difficult to send the mail again.
This tasks will allow users to send mail again easily, or mark notification
as cancelled if the user want to ignore this failure.
A notification will appear in sender systray while mail are in failure.
Task: #46158
PR: #24628
|
|
Unlike LESS, SCSS variables are not lazy loaded. Our system has thus
to be updated. This commit creates new templates which are t-called
in assets bundles (to replace the old less_helpers template):
- web._assets_utils: regroups the mixins and functions which *can*
(and so should) be available in every asset bundle
- web._assets_primary_variables: regroups the variables (or mixins
used as variables) which *can* (and so should) be available in
every asset bundle
- web._assets_secondary_variables: same as above but provides an
environnement where all the 'primary' ones are accessible. This is
for example useful to handle the community/enterprise split:
// Community primary variables
$o-pink-color: pink; // enterprise color
$o-brand-primary: blue;
// Enterprise primary variables
$o-brand-primary: $o-pink-color;
// Community secondary variables
$o-my-darker-primary: darken($o-brand-primary, 5%);
=> If there was only one variable template, enterprise edition would
have been able to define its primary color at the end but the
darker primary would not have been updated. Using the "!default"
system and putting enterprise definition above would not have
solved the problem as the $o-pink-color would not have been
accessible.
- web._assets_backend_helpers: regroups the variables, mixins and
functions which *can* (and so should) be available in the backend
asset bundle only. This is especially (only?) useful for bootstrap
variables overriddes.
- web._assets_frontend_helpers: regroups the variables, mixins and
functions which *can* (and so should) be available in the frontend
asset bundle only. This is especially (only?) useful for bootstrap
variables overriddes.
Note: bootstrap variables are not accessible in any of those anymore.
If you have variables that should depend on bootstrap, you have 3
solutions:
- Find another way: your variable is probably useless, use bootstrap
variables directly or create a variable that will influence the
value of bootstrap variables. E.g. instead of declaring:
`$myvar: $bootstrapvar * 3`
and using $myvar alone, declare:
`$myvar: 3` and use `$myvar * $bootstrapvar` where needed.
- Declare a copy of the bootstrap variable and use that one. In that
case, you should also force-set the real bootstrap one to be sure
they match (this should be done in appropriate templates mentioned
above). E.g.
```
$o-boostrapvar: 5;
...
$boostrapvar: $o-bootstrapvar;
```
- Set your variable to null and set it to your bootstrap expression
in the file you will need it (where bootstrap variables are accessible)
without forgetting to add the !default flag to allow overriddes.
```
$myvar: null;
...
$myvar: $bootstrapvar * 5 !default;
```
This commit also partly changes the variable names to follow the
convention:
$o-<app_id>-<name> where 'app_id' is the current's app name or a
meaningful unique identifier ("theme" for all themes for example, as
no multiple themes can be installed).
|
|
During first scss convertion, classes called as mixins were changed to
an @extend instruction which was the best approximation given the fact
there is no equivalent in sass to do that. The problem is that the
instruction is slowing the scss computation a lot and might also break
the style in unexpected ways because of the complex unwanted selectors
the instruction induces.
This commit removes the need of extends. This is done case per case.
Sometimes this involves adding classes in xml, sometimes to change the
style a little, ... The button rendering refactoring which was made
at the start of the LESS to SASS merge was also done in prevision of
this.
After this commit, sass computation is like 5-6 times faster than less
computation while it was like 10 times *slower* before this commit.
|
|
Convert content so that the assets compile on app installation. The
style is still broken after this as the variables/mixins/... are not
defined in the right order (as it did not matter in LESS but does in
SCSS).
This commit basically changes:
- Variables: @var_hello -> $var-hello
- Mixins: .mixin_world() {} -> @mixin mixin-world {}
- Classes used as mixin: .my_class() -> @extend .my_class
- Here there were no other solution than to convert the use of
a mixin call by the use of an extend as a first approximation
- LESS functions -> SCSS functions (e.g. fade -> rgba)
- Move first variable definition before the variable is used
- Still need to make sure last variable definition is at the
right place
|
|
This is a simple renaming without adaptation.
|
