The goal of the module was to communicate with livechat operators on our
production server, except the feature is disabled on our prod and we don't plan
to reactivate it any time soon.

closes odoo/odoo#52691

Related: odoo/upgrade#1313
Signed-off-by: Christophe Simonis <chs@odoo.com>

The im_support module was broken in 12.0 after bus refactorings between
11.0 and 12.0.

closes odoo/odoo#38838

X-original-commit: db37e0cedcd0da46bd57686a076a8165e60d6c3b
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Co-authored-by: @alexkuhn

Part of task 1896658

Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
Co-authored-by: svs-odoo <svs@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>

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).

- updated docstring
- move function to abstract thread (generalization behaviour for all threads)
- simplify code

* = 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)

----------------------
 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.