| Age | Commit message (Collapse) | Author |
|---|
|
----------------------
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.
|
|
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.
|
|
|
|
content_subtype was a parameter to message_post allowing to give plaintext
content instead of html content. It has been removed at 74d4b3902d51bf805f87bfd853f54407137b0ac3. This
commit cleans some leftover bits referencing this now removed parameter.
|
|
|
|
|
|
|
|
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.
|
|
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
|
|
Before this commit:
Clicking on 'unstar all' button removes all messages from starred channel
but it only decreases the counter as many as there are displayed messages
on screen.
For example, if there are 40 messages starred, only 30 messages
are on screen (default limit) but unstar all will decrease counter
only for those messages instead of 40.
After this commit:
clicking on 'unstar all' button will correctly take in account all
fetched messages and not only displayed messages.
So now, after clicking on 'unstar all' button will update the starred
counter to 0.
task-ID: 33958
|
|
The feature has been broken by rev. 02ec09cb1.
|
|
Before this commit, when mentioning a user at the end of a message,
no link was shown.
The cause is that any mention should end with whitespace, but during
the preprocessing of a message, the message is trimmed, which removes
the final whitespace of the mention.
We would like to keep trimming at the preprocessing of the message,
but we can relax a bit the regex to detect a mention, so that it is
not necessary to have a whitespace at the end of a matched mention.
|
|
Revision on recent JS refactoring: https://github.com/odoo/odoo/commit/02ec09cb1c3e2d7bc7968f40c18f2208d7f3f498
Intermediary changes have not been updated with final way of communicating
with JS services. In particular, widgets must now explicitly call the
service with this.call instead of relying on a mixin that hides the service call
(e.g. the chat_mixin that has been removed)
|
|
Rev. on this commit: https://github.com/odoo/odoo/commit/02ec09cb1c3e2d7bc7968f40c18f2208d7f3f498
A consequence of the above commit is that @ mention were broken:
the dropup menu with partner propositions was not displaying when
the user typed the first characters to mention a user (e.g. by typing
"[at]demo" in order to show the proposed mention "[at]Demo User" in a dropup
menu).
This commit fixes the issue by reverting the logic of how mentions are provided
by the chat_manager, while removing some dead code.
note: [at] = @
|
|
|
|
- Whitespace trailing
- Split long lines
- Replace some 'self' to 'this'
- Improved some JS docs
- DRY in tests using services
|
|
Fix over this commit: https://github.com/odoo/odoo/commit/02ec09cb1c3e2d7bc7968f40c18f2208d7f3f498
In mobile, when discuss is installed, there is a traceback.
This is a consequence on an issue with JS services, where some of them
are not registered in the service provider.
For instance, the webclient (the service provider) was instantiated before
chat_manager (a service), so it was not aware of this service.
To solve this issue, service providers now listen on newly registered services.
Also improving deployment of JS services by not relying on topological sort.
|
|
This commit improves the JS code of the mail module,
which comes maily from the new coding guidelines
and the addition of "JS services".
JS services are important objects that do not fit
well in the component tree, such as chat_manager
or ajax.
The benefits of JS services are improved readability
of the code, reduced coupling, and more testable
modules. In particular, discuss was hard to
Summary of the changes:
- ClientAction has been renamed into Discuss
- Clear instantiation of chatManager
- New coding guidelines in most mail modules
- JS Services can interact with each other
- Chat Manager and Window Manager are services
- Window Manager renamed to Chat Window Manager
- bus.bus is now encapsulated in Bus Service (a service)
- The test infrastructure has been tweaked with JS Services
- Chat Mixin has been removed
A future improvement would be to translate some 'trigger' into 'trigger_up'.
|
