| 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.
|
|
This reverts commit c778de44c7cd9b7ef5a9a91738164ab0ebd0ca06.
|
|
- The code to remove mentionned users on the chatter isn't robust enough.
It crashes when trying to remove a link added from a copy/paste as if it was a mention.
Mentions have an id defined on their "a" html node, linked copied and pasted don't.
Which crashes the javascript code because it is trying to use the id.
This fix, make sure to delete the node without using its id (we already have the node) and make sure to remove it only if it starts with a '@' (meaning it is a mention).
|
|
|
|
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
|
|
|
|
This commit back-port some fixes from saas-11.2 on composer.
Tests are available only in saas-11.2 and up.
List of fixes:
1. Pressing TAB with @ mention propositions should cycle through them
(see https://github.com/odoo/odoo/commit/497a44ab7f04e377decf5fde42f075616f764f26)
2. Prevent a crash when focusing out the emoji button
(see https://github.com/odoo/odoo/commit/1753017255f3f078ede05a68842f440e02b64630)
|
|
Before this commit, on a clear session, there was a traceback
after focusing out the emoji button next to the composer.
This is due to a DOM element that exists only after clicking on
the emoji button, and it was wrongly assumed that focusout cannot
occur without a preceding click. Indeed, we can press TAB to move
between focusable elements, so that we can have the focus in/out
on the button without clicking on it.
|
|
Before this commit, when the partner mention propositions dropup was visible
on discuss composer, pressing on TAB result in selecting the next focusable DOM
element after the composer input, which is usually the 'Send' or 'Log' button.
This behaviour is confusing, because users expect that TAB either autofill the
input or cycle through the propositions.
We decided to align on Slack's behaviour of TAB, which is to cycle through
the mention popositions from top to bottom.
|
|
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.
|
|
- Whitespace trailing
- Split long lines
- Replace some 'self' to 'this'
- Improved some JS docs
- DRY in tests using services
|
|
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'.
|
|
When someone mentions another person in discuss/chat window, the
mentioned name was displayed just as a text, which may be unclear. With
this commit, we display mentions with the same style as mentions in a
message.
To do that, the main idea is to change the input by a div with
contenteditable set to true. This allows us to add <a>...</a> inside.
|
|
Closes #20277
|
|
Rev. 2728fe1 introduced an attempt of restoring the focus on the
currently focused field in an x2many list after an onchange
returned, and the list has been updated. However, it was often
wrong (e.g. leaving a field by pressing tab/shift+tab, clicking on
another field...) and reset the focus on an unexpected field.
In addition to fixing this issue, this rev. also unifies the helper
functions to get and set the cursor positions in an input or
textarea, as they were duplicated between mail and web.
|
|
The `isMobile` variable was defined at the right place (`config.device`)
but was set at the wrong place (`config`).
Thank you for making me author of all the `isMobile` lines by
the way... :)
|
|
- Fix several contexts where the emoji popover was hidden by a webclient
element (control panel / ...). To solve this bug, the design has been
improved to not use popover but instead use custom design (better
integrated with new chatter design)
- Chat window is now still usable when a modal is opened
- Simplify chatter LESS
|
|
- Extract mobile specific code for the client action to a specific
file
- Massive clean of less rules
- Unify channels preview of the systray dropdown and the mobile UI
of Discuss
- Ensure to only load the last message of each channel in mobile,
as this is not used in desktop (unless the user opens the systray
menu)
- Make livechat available in Discuss mobile UI
|
|
- Brand new UI for Discuss client action (with tabs for Inbox,
chats, channels...)
- In mobile, conversations always open in Chat Windows
- Chat window UI improved (both mobile and desktop)
- Channels preview (used in the systray menu, and now in the mobile
UI of Discuss) improved
- Other minor less tweaks
|
|
|
|
Purpose
=======
The goal is that when you click on an attachment, you should get a preview of it and then you get the possibility to download it.
|
|
- Use classes instead of repeated mixins
- Add real user avatar instead of fake one
- Reorganize LESS rules
|
|
Closes task 32316
|
|
Caused by a stupid programming error.
Also refactor a bit the code that performs mention RPCs (that are
throttled) to allow to override the throttling value for the tests.
|
|
Since the new views merge, a lot of design elements were broken. This
was particularly impacting the fields in the editable list view; indeed
the editable list view is not using an inline form view anymore so the
fields in the list were not properly styled as the LESS was still
defined assuming the form view environment (for example the invalid
fields were red for o2m fields in form view but not in editable list
view even though they got the right CSS class).
This commit refactor the LESS following these rules:
- No more division of non-layout and layout rules. Dividing LESS rules
in x_layout.less and x.less was a mistake. Many rules can be
considered to be layout and not layout at the same time, developers
always have to switch from one file part to the other, many CSS
selectors (and rules!) are duplicated for nothing, ...
- Field style is extracted from x_view.less and put in the new
fields.less file. As before, the fields_extra.less will contain the
rules specific to community so that the enterprise repo can override
those by replacing the whole file.
- Many classes have been renamed so that o_form_x_y becomes o_x_y as
many classes can now be applied outside of form view. These classes
should not be used in templates anyway.
The commit also changes the DOM of fields so that it is more minimalist
(no useless parent div, etc).
Input elements are not automatically styled anymore, they have to get
the o_input class explicitely. This allows to fix lots of small style
bugs of previous versions (required monetary field had not the proper
style, readonly m2m tags appeared as editable, ...). This also improves
the LESS code.
The editable list view should also completely stop flickering on chrome
and firefox.
The commit also removes the orange outline on list view dirty cells.
The commit also removes deprecated static xml, LESS and other code.
Notice there are still styles to restore/fix and LESS to improve.
|
|
The RPC system was not completely satisfactory, we decided to prepare
the future and do it properly. This commit introduces the new rpc
system, which replace the previous new one. We now simply have a
method, this._rpc, which takes a dictionary of parameters. The idea is
that depending on the parameters, it is able to add correct default
value when necessary.
For situations where we don't have the this._rpc method, we can use the
rpc.query method, which takes the same arguments, but directly calls
ajax.rpc instead of triggering up some events.
|
|
The _rpc method is now the preferred method to do a rpc, so we need to
update all calls.
|
|
Use this.rpc instead of Model object, with web.ajax if necessary.
nb: EventDispatcherMixin include now the custom_events managment instead
of widget
|
|
This commit introduce a full redesign of all JS views. We started
basically from scratch. The goal was to unify all the various views
under a common framework, to make them testable, to make then usable in
different conditions (in studio, or in the frontend), and to make our
lives easier.
Some important points are:
- we introduced new coding guidelines (camelCase, 80 chars width, ...)
- we have a brand new testing framework (still QUnit based)
- kanban view moved to the web addon
- calendar view (formerly web_calender) moved to web as well
- the tree view was removed
- all new code should be documented
We hope that this code is the start of a new era for the Odoo web
client, we want to have a high quality codebase, well documented, well
tested, well designed.
Work done by the framework team: mostly aab, ged, chm, dmo, qsm
|
|
|
|
|
|
If after inserting a mention (eg: `@Guy`) and we eg. backspace and
change it (eg: to `@GuyFawkes`) the `@Guy` mention will still be
linkified but the partner is not subscribed.
This happened because the linkifying was not requiring a space to follow
the mention, but when getting the used mentions (and commands, ...) in
the message they were required (unless the mention was exactly at the
end of the message).
With this commit, a space is always required after a mention for it to
be working.
opw-705267
|
|
|
|
|
|
When a message is sent on the chatter and the call fails (for example
because of an internet connection failure), the message was still
cleared so the content was lost.
This change keep the same behavior for chat window and discuss, but
change the behavior in a chatter so the message is only cleared if the
rpc has passed.
closes #14759
opw-696971
|
|
In chat window, a chatter and discuss, the text zone appear as a pure
text zone but is transformed later on in HTML to add mentions links and
possibly other features.
Thus, when we wrote multiple spaces or a space at the next to html tag,
with how html worked they were collpased into one (or zero).
To keep them, we need to wrap the content with `<pre />` tag or replace
spaces with ` `.
closes #14593
opw-695535
|
|
|
|
* Tip are never destroyed when change view mode
* unbind methods
* mail: memory leak with unbind methods
* web: memory leak because 'ui-autocomplete' is never destroyed
* web_editor: memory leak for wrong unbind on destroy
* web: memory leak: must remove fileupload handler
* bus: memory leak: correctly debind handlers on window in bus.Bus
* remove handlers on switch buttons and views $buttons
* remove handlers on breadcrumbs
* web: memory leak: correctly debind handlers
* im_odoo_support: memory leak: remove fileupload handler odoo_support
Note: part of this commit was actually authored by aab
|
|
|
|
|
|
Closes #11929
opw-676854
|
|
|
|
|
|
Use the mention mechanism to autocomplete on commands (keyword /).
A first command /help has been implemented.
|
|
Use the mention mechanism of the composer to autocomplete on canned responses
(keyword :) with fuzzy search.
Directly perform the string replacement in the composer, instead of
server-side as before.
Add a menu item to access an editable list view to create and edit canned
responses.
Add two canned responses as demo data.
|
|
|
|
A 200ms delay is set on lookups for mention suggestions to prevent triggering
RPCs when the user is still typing. However, there shouldn't be a delay when
the suggestions are looked up in the prefetched suggestions.
Also fixes a bug that might occur when the user starts typing a mention which
triggers an RPC, but erase it before the RPC returns.
|
|
The BasicComposer widget is now used in chat windows, which enables the mention
feature. This is only for the backend, as for the livechat windows in the
frontend, the composer is still a simple input.
Classname 'o_chat_input' has been renamed into 'o_chat_composer' (the root
classname of the basic composer) for uniformity in the JS and LESS code of
chat windows.
|
|
to prevent crashes if the user types, e.g. a \, when mentionning someone.
|
|
|
