| Age | Commit message (Collapse) | Author |
|---|
|
This commit adds the ability to upload and delete
attachments from the chatter.
Task: #1911277
closes odoo/odoo#29702
|
|
Moved the field 'active', 'res_model_name' and 'thumbnail' from
ir.attachment to enterprise's documents.document.
Moved the pdf split feature to enterprise's Documents module.
task: #1908896
|
|
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
|
|
This commit adds a button to discard replying to
a message from the Discuss inbox.
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
|
|
Revision on https://github.com/odoo/odoo/commit/cd34f6de727d5b3858420cff3c9d3c5995c4e75c
Before the commit above, it was possible to reply to a message
from Inbox. Those messages were linked to a document, and replying
to any of them put a response in the related document.
This feature has been broken since the commit above: the reply
icon was only shown on messages linked to a channel, instead of
message linked to a document. Also, it was erroneously prompting
that the message was sent to the channel, even though it was not
the case.
This commit fixes the issue by toggling the visibility of the
reply icon, so that it is shown only for messages that come from
a document. Also, since posting a message requires a thread, this
commit added the possibility to post a message from a mailbox,
which instead posts the message to the related document thread.
Task-ID 1912647
closes odoo/odoo#29028
|
|
|
|
|
|
|
|
closes odoo/odoo#28255
|
|
Before that, the body of the message was never displayed if the message had tracking values. This was annoying for account_asset module, were we prompt the user for some justification when she modifies the depreciation data of an asset, and then call message_post with this text as body, and tracking values reflecting the change that was made.
|
|
Before this commit, a moderator of a moderated channel could see
commands on 'pending moderation' messages in a chat window, although
none of them work in chat windows.
Those commands only work in Discuss. Making them work in chat windows
is not trivial, because some code must be redesigned for this.
This commit disables moderation commands in chat window. Moderators
of such channel now see 'Pending moderation' on such messages in
chat window, and mouse-hovering on this annotation tells the user
to moderate those messages in the Discuss app.
Task-ID 1887963
|
|
|
|
- added two new actions to the form view debug action list,
both opens list (+ form) views of messages and attachments respectively
for which the domain is restricted to the current record.
task: 1860031
|
|
Revision on https://github.com/odoo/odoo/commit/ec8c505bc1c9ec21939e9ffef53a9cc6f63f30c7
The commit above changes the way threads are rendered: the template
now uses a thread object, instead of a list of messages.
However, it was not handling messages that have been filtered from
the searchview. As a result, it was not possible to filter messages
at all.
This commit re-adds the possibility to filter messages, by providing
information on the domain of the thread in the template.
Task-ID 1877502
|
|
From forward port branch saas-11.4, commit 68d36512ef952d52547969b485951d86b1fb761c
|
|
|
|
-removed force_ext from ir.http.
-added signature arg to web/image to differentiate cache entries by URL.
-added an embed youtube viewer for youtube URL's
-added a PDF splitter to the PDF viewer UI
-added tests for mail's Document Viewer
-added a "signature" param to web/image to go around the browser cache
-thumbnail field of ir.attachment is now stored in the filestore
as a distinct attachment.
task 1853490
Co-authored-by: Pierre Paridans <app@odoo.com>
|
|
We need to know if a notification is in failure by
displaying the red envelope in even if all partner are inactive.
This commit also fix the filter in order to display notification
of all active partners if there is an exception.
|
|
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
|
|
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]-------+
|
|
Revision on https://github.com/odoo/odoo/commit/0eab8f6e0b17a4ff6a859d14b14b643212cbadc1
The commit above fixed the definition of ASC/DESC on the rendering
of mail threads.
However, the 'is typing...' notification bar was still partially
using the old definitions. As a result, this notification bar was
not sticking at the visible bottom of the thread when there were
few messages:
+--------[top]--------+ <---- visible top
| 1st message |
| 2nd message |
| 3rd message |
| X is typing... |
| |
| |
| |
+------[bottom]-------+ <---- visible bottom
This commit fixes the issue so that the 'is typing...' notification
bar is always at the bottom of the thread in such case:
+--------[top]--------+ <---- visible top
| 1st message |
| 2nd message |
| 3rd message |
| |
| |
| |
| X is typing... |
+------[bottom]-------+ <---- visible bottom
Note that it fixes the case with 'few messages', without altering the case with
'several' messages:
+--------[top]--------+
| |
| (older messages) |
| |
|- - - - - - - - - - -| <---- visible top
| ... |
| message i |
| message i + 1 |
| ... |
| |
| X is typing... |
|- - - - - - - - - - -| <---- visible bottom
| |
| (newer messages) |
| |
+------[bottom]-------+
|
|
Revision on https://github.com/odoo/odoo/commit/f2302dfb27dd7f6a0dee7c65ab75b62a01706264
The commit above improved the rendering of thread.
However, it wrongly defined ASC and DESC.
This commit fixes this issue by re-arranging so that their
definitions match the meaning of 'ascending' and
'descending'.
Orders are defined from top to bottom. Visually:
_____________ _____________
| | | |
| message 1 | | message n |
| message 2 | | ... |
| ... | | message 2 |
| message n | | message 1 |
|_____________| |_____________|
ORDER: ASC DESC
|
|
Revision on https://github.com/odoo/odoo/commit/e0a51edd856b36bfdf1cacb4d7e8d70fad7884fa
In the commit above, we added an option to Discuss widget
to render threads specifically for PhantomJS. The reason
for this is that a test was failing, because it needs full
support of CSS flexbox to pass.
However, PhantomJS does not support flexbox very well. As
a result, it was messing with the rendering of threads.
We couldn't make the hack just in the test itself, because
it is already at the moment of rendering the thread that
PhantomJS messes the whole process of the test.
PhantomJS has been replaced with Chrome headless [1], So
the hack is no longer be necessary, as Chrome headless
fully supports CSS flexbox.
[1] https://github.com/odoo/odoo/commit/de84ad9c1f4853cb8a748ee1d0c880081dae9fe2
|
|
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
|
|
Before this commit, this test was failing due to phantomjs assuming that
there could be more messages to display on the screen.
The issues comes from the bad support of flexbox with PhantomJS, and this
test broke when we changed a DIV display with 'flex' instead of 'block'.
For instance, this is the expected values:
thread clientHeight: 960
thread scrollHeight: 1629
message clientHeight: 50
With 30 messages, 50 x 30 = 1500 < 1629 and 960 < 1629, so there are
enough messages loaded with this screen and we are not at the top of
the thread (this is the case when clientHeight = scrollHeight).
However, with phantomJS we have the following values:
thread clientHeight: 944
thread scrollHeight: 944
message clientHeight: 259
As a result, with 30 messages, 50 x 30 = 1500 > 944 (looks like
messages do not vertically collide ?) and 944 = 944 so it assumes
we are at the top of the thread, so it fetches for more messages.
This commit fixes this test by enforcing a special rendering of the
thread for phantomJS.
Unfortunately, we can't simply make the hack on the test only. We
have to make discuss and thread aware of this because they should
adapt their rendering right away
|
|
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).
|
|
|
|
'img-rounded' -> 'rounded'
'img-circle' -> 'rounded-circle'
|
|
Odoo made the bad choice of using the 'btn-sm' class for every button
instead of configuring the padding for default 'btn' to be smaller.
In BS4, the style of btn-sm is actually more complex, lowering the
font-size too. Also, btn-xs was removed so we would not have the
possibility to display smaller button than our default ones.
This commit removes btn-sm wherever it was used. Unfortunately, this
might remove it at some places where it made sense but this can be
restored in a second time.
|
|
instantiation, thread `getMessages`/`fetchMessages`, and create mode document thread.
* = im_livechat, im_support
- thread widget now uses abstract thread in `render` method
- thread models have their `init` parameters changed, so that the parent may be optional
- reworked 'creating a new record...' in chatter in create mode:
> new model CreateModeDocumentThread, which basically is a fake document thread
with a fake message for its rendering in create mode of the chatter
> special rendering method of thread_widget for such case: `renderChatterCreateMode`
- renamed thread methods previously named `getMessages` to `fetchMessages`:
> in order to not conflict with `getMessages`, used for rendering
> now, `getMessages` always get messages that are locally,
while `fetchMessages` may fetch messages.
TODO:
- special thread model for im_livechat (rendering is broken ATM)
|
|
With this commit, the template for thread uses a {mail.model.AbstractThread}
object, instead of a list of {mail.model.AbstractMessage[]}.
|
|
Some parameters in the templates were not documented, which is now
the case with this commit.
|
|
- `displayEmptyChannel` thread rendering options becomes `displayEmptyThread`
- classname `o_chat_content` becomes `o_thread-window_content`, as it is used
only for thread windows.
- template `mail.EmptyChannel` has been renamed to `mail.widget.Thread.Empty`
|
|
----------------------
Summary
----------------------
The purpose of this commit is to improve the JS code of the `mail` module.
It applies the new coding guidelines and makes some changes on the design
of some modules, such as the old ChatManager module.
Here is a short summary of the changes that have been made:
1. New coding guidelines
- snake_case to camelCase
- prefix private attributes and methods with '_'
- jsdoc on most methods
- one class per module
2. Rename/Merge some classes
- 'chat manager' becomes 'mail manager' (internal) and 'mail service' (external)
- 'chat window manager' is now included in mail manager
- 'thread' widget now named 'thread widget'
3. New model abstraction for mail objects:
- modules 'mail.model.*'
- modeling:
0..1 0..1 * *
ThreadWindow <------> Thread <-------> Message
/ \
/ \
Thread With Cache Document Thread
/ | \
/ | \
Mailbox Channel Support Channel
|
|
DM
- Thread: the superclass of threads.
- ThreadWindow: the window component of a thread.
- Message: mail objects representing messages.
- Thread With Cache: threads that can be used with search view (Discuss app compatible).
- Document Thread: represents the thread part of a chatter.
- Mailbox: represents what was previously called 'static' channel, e.g. 'Inbox'.
- Channel: mail objects representing channels, including livechat.
- DM: special kind of Channel for 1:1 communication in the backend.
- Support Channel: special channel for im_support module.
This new modeling approach let us easily add features on all threads, such as the
possibility to put any thread in a small window.
----------------------
Known issues
----------------------
[Already Present in Master]
1. When the Discuss app is in the background with 'Inbox' as the selected
Thread, when clicking on a document thread preview in the messaging menu
of the systray, the rainbow man appears.
2. When a document with the chatter is in the background, when receiving an
inbox notification from this document thread, the document thread is
automatically marked as read, which removes the notification right away.
3. Sometimes, opening a DM window from the "blank" thread window does not work.
4. Reply-to feature on Inbox is not working: no message is sent in the document
thread.
5. On the first login of admin user with demo data, the inbox counter is wrong
(it displays 6, instead of 3).
Explanation after investigation:
> On page load, it fetches the correct number of Inbox messages (3),
but the server notifies of 3 needaction messages right away,
so it wrongly assumes these are new needaction messages.
> Not possible for web client to detect that these messages should not
increment the Inbox counter while keeping same API.
6. Notifications for new document thread messages only work when the user sets
'handle with Odoo' for the Notification Management in the preferences.
> due to notifications on the longpoll bus for document thread
messages that come from needaction notifications.
> requires server-side changes to send notification on the longpoll
bus to mentionned user.
[New]
7. When receiving a message on a unjoined channel, thread window flickers
('open' > 'close' > 'open')
Explanation after investigation:
> JS logic:
a) On auto-join, ask server to join the channel and get channel infos.
b) The info tells the channel is not detached, but JS code makes decision
to detach it, and tells server the channel is now detached.
c) From (a), server notifies on longpoll bus the state of channel, which is
not detached. The web client thinks that the window state of the channel
has been changed somewhere else, and the channel is now closed.
d) From (b), server notifies on longpoll bus the state of channel, which is
detached. The web client opens the thread window of this channel.
> The flicker didn't occur before refactoring because the web client was only
updating the model of channel when it receives the longpoll notification.
> Server behaviour on 1st longpoll notification is necessary for cross-tab
synchronization for channel window state.
> New design implies that model and view should be synchronized, hence the
issue now.
> Solution: remove server-side thread window synchronization and replace with
client-side synchronization.
----------------------
Hacks
----------------------
The module `im_livechat` now uses mail objects that are compatible with Message
and Window objects:
Modeling for messages:
AbstractMessage
/ \
/ \
LivechatMessage Message
- AbstractMessage: message compatible with the thread widget.
- LivechatMessage: message used by im_livechat.
- Message: message used with the mail manager.
Modeling for thread windows:
AbstractThreadWindow
/ \
/ \
LivechatWindow ThreadWindow
- AbstractThreadWindow: behaviour share between all types of thread windows.
- LivechatWindow: window used by im_livechat.
- ThreadWindow: window used with mail_manager.
The reason for these hacks are twofold:
1. Use the thread widget in the frontend and livechat external lib bundles.
2. Do not have a dependency with the mail manager in the frontend and external
lib bundles.
|
|
Today, Odoo is really tricky to use without seeing the screen, it must be improved to be usable.
This PR forbid to use labels without a "for" attribute, add some title, rule and aria attributes in HTML. With that, Odoo will be fully usable with a screen reader.
* [IMP] Labels must have a for attribute. Improve accessibility.
* [IMP] Better error message when trying to read a missing cached value
* [FIX] Add some aria-label and title attributes for screen readers.
* [FIX] Template name is not included in the error message in case of SyntaxError in QWeb
* [FIX] Improve the Tour failed at step error message to be more explicit.
* [IMP] Add aria-labels
* [FIX] Add missing aria-label on failing test
* [IMP] aria-hidden means hidden. Fix all bad aria-hidden and hide aria-hidden for all.
* [IMP] Color names on kanban views and many2many tags
* [IMP] Add some checks on views for accessibility.
* [IMP] Add `alt` attribute on `img` tags.
* [IMP] Add aria-label and title on non-described icons
* [IMP] Add button role to widgets with btn class
* [IMP] Translate aria and formatted attributes.
* [IMP] Remove wrong aria-labelledby
* [IMP] Add menu role on dropdowns
* [IMP] Buttons must be focusable
* [IMP] Add aria attributes on progress bars
* [IMP] Improve accessibility of basic widgets
* [IMP] Change main layout to more semantic tags
* [IMP] Add menuitem role when missing
* [IMP] Remove wrong role='presentation'
* [IMP] Improve accessibility of tab panels
* [IMP] Add aria-invalid on invalid fields
* [IMP] Add aria-sort on ordered columns
* [IMP] Add role on alerts
* [IMP] Use dialog role, header, main and footer tags for modals
* [IMP] Add labels on o_status
* [IMP] Improve accessibility of kanban view with feeds and articles
* [IMP] Add alerts in case of new messages
* [IMP] Add widget, navigation or img role to aria-labelled items
|
|
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
|
|
Purpose of this commit is to allow moderation on incoming messages in
discussion channels. On some channels on which moderation is required
messages should be in a pending moderation stage. Moderators can accept
or refuse messages as well as always allow or ban messages coming from
a given set of emails.
Channels now have an option to be moderated. Moderators can be added on
channels. They have access to a specific UI in Discuss to see and take
action on messages waiting for moderation.
Concerning mail.thread message that are pending moderation are not notified.
It means nobody receives a notification about them. Moderation process calls
the notification once the message is validated.
Various features included in this commit :
* a model is added to store the decision about emails, allow or ban;
* access rights are updated so that only moderators can modify moderation
fields on message;
* specific bus notifications are send to moderated people as well as to
moderators on incoming emails as well as when a decision is taken;
* options are added on channels to send explanations to moderated emails;
* options are added on channels to write and send guidelines explaining
why and how moderation is performed;
* a reminder is send daily to moderators with remaining messages to moderate;
* discuss UI is adapted and a new channel is added below Inbox and Starred
giving access to moderation tools;
* chanenl UI is adapted allowing to moderate directly inside channels;
This commit is linked to task ID 29521. Closes #21921.
|
|
|
|
|
|
|
|
viewer and keep focus on chat window input when document viewer is closed (#22741)
If document viewer is opened from chat window and when document viewer is opened then focus
remains on it's modal, pressing escape should set focus back to chat window's input element,
if file selecor dialog is opened and if user press ESCAPE on file selector dialog to cancel file selector
dialog then it should not close chat window instead it should set focus on chat window input and on
second ESCAPE key chat window should be closed
also increase z-index of document viewer dialog so image remain on top of cht window
OPW: 1777937
|
|
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.
|
|
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.
|
|
- Redesign all mimetype icons
- use SVG to reduce file size and improve rendering quality.
- Add a data attribute to attachments to detect the file extension (in somes
cases just mimetype is not accurate)
|
|
With this commit, the attachments displayed in a thread (typically a
chatter) are properly styled.
|
|
|
|
- Improve design
- LESS: use mixing and variables when possible, code formatting
- Solve a minor issue causing images to be not perfectly centered
- Improve visual feedbacks (tooltips, cursors, hover states...)
|
|
After this rev., in Discuss, messages are automatically loaded when
the user scrolls to the top of the channel.
Task 33958
Co-authored-by: Aaron Bohy <aab@odoo.com>
|
|
|
