TL;DR A bit of magic and ... Pouf ... all virtual events are now real records.

Purpose
=======
The current implementation of recurring events uses "virtual events" to represents all
events in the recurrence. Only one event is stored in the database. All other events are
dynamically built and sent to the web client which sees them as real records.
This implementation is old, difficult to read (6 years of changes and bug fixes) and
has become more and more difficult to maintain.
A fresh start would be welcome.

Specification
=============
When creating a recurring event, a `calendar.recurrence.rule` record should be created.
This model holds the rrule configuration and is responsible to manage events that result
from the rrule.
When a new recurrence is created, all resulting events are also created (stored in the
database). No more virtual events.
To avoid an explosion of events, a maximum of 720 events is created. With 720 events,
a daily recurrence lasts for 2 years and a weekly recurrence lasts for 15 years.
This strategy is used by Google Calendar and seems acceptable in most cases.
A cron job could eventually be introduced to generated more events as the end comes.

This allows to introduce an new rrule end type: 'Forever'. This is actually a shortcut
to create a recurrence running for 720 events.

Inspired by Google Calendar, new possibilities are introduced when modifying a recurring
event (e.g. change the name, add an attendee):
- Modify only this particular event (the event is still part of the recurrence)
- Modify this and following events (events are still in the same recurrence)
- Modify all events

In a similar way, when updating the rrule of an event (e.g. from every Monday to every
Tuesday), the user can choose to:
- Modify this and following events: the recurrence is split. The first part remains
  unchanged but now ends when the second recurrence begins. The second parts is the
  updated rrule.
- Modify only this particular event.
- Modify all events: Forbidden (same as Google Calendar)

Note: when events are "moved" because the rrule changed, the events are not actually
moved. They are unlinked and new events are created (See "Some design choices explained"
section).

Some design choices explained
=============================

Where to store the rrule?
-------------------------
Two options were considered.
1) Store the rrule on an event, each event of the recurrence having a Many2one
to the parent_id, aka the Master Event of the recurrence.

2) Store the rrule on another model: `calendar.recurrence.rule`. Each event in the
recurrence having a Many2one to the recurrence record.

Both options have pros & cons. But there is no clear winner.
However the actual business logic of handling the recurrence creation/update
would be the same.
Where the rrule configuration is stored is the only main difference between both options.
And this is probably the easiest part of implementing recurring events.

With that in mind, option 2) is chosen. It allows to clearly separate recurrence
logic from the events themselves. It is also the "correct" way of modeling data to avoid
many empty columns for most records.

Reusing events on rrule update
------------------------------
When an rrule is modified, events should also be updated.
In most cases, current events are unlinked and new events are created from scratch.
Only events exactly at the same time before and after the rrule update are kept.
Trying to reuse other events would require an obscure and arbitrary heuristic.
(Imagine an rrule every Monday that is changed to every Tuesday and every Friday.
What would you do?).
This implies that any change to a specific event (name change, attendee added, chatter
messages) is lost. This tradeoff seems acceptable as updating an rrule should not be
that frequent. Moreover, Google Calendar also works that way so why not Odoo?

Reusing events on events shifts
-------------------------------
On the calendar view, drag and drop an event to shift the entire recurrence.

One way to handle the recurrence shift is to apply the same timedelta to all events.
Now events are correctly positioned... except for events that were specifically
moved. Those outliers needs special handling.
This also introduces some behavior inconsistencies:
when an rrule is directly modified, events are not reused, but when the rrule is
modified by drag & dropping an event, events are reused. This option needs more code to
handle the shift and the behaviors are not consistent.

The chosen option is to find the rrule configuration from the dragged event (this is
easy) and update the recurrence with those new rrule values. This brings us back to
an rrule update (see above): code reusability yeah; one behavior to rule them all yeah.
One downside is that outliers are lost (but Google Calendar also works that way).

Task 2126717
PR #42031
PR Enterprise odoo/enterprise#8006

Before this commit, when user attempts to edit or delete a private
event without being an attendee, it raises an access right error.

This commit disables edit and delete buttons in this case, in
addition to hide event details.

task-2151150

Closes https://github.com/odoo/odoo/pull/42569

closes odoo/odoo#42569

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>

The whole cell is now clickable, not only the first line and it opens
the calendar view.

The meeting title is now displayed on the left, and the time on the right.
Morever, the exact hour is now displayed, not "In 4 hours".

The next activity background color has also been adapted (goes to white).

Task 1948737

closes odoo/odoo#32215

Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>

* barcodes, calendar, partner_autocomplete, web_settings_dashboard

Make the notification system better, using bootstrap toast component,
and make it available in the frontend.

The toast component allowed to remove some JS code and made the
component customizable by themes but it had to be reviewed/fixed to make
it functional (maybe bootstrap will review its work in next versions).

This work should still be improved because there are still too many
ways (deprecated and not deprecated) to instantiate toasts in the
backend. The goal here was however to make the toasts more modern and
make them available in the frontend.

This work is needed for some tasks. @kig-odoo and @fja-odoo made a
pre-work to instantiate toasts in the frontend for their respective
tasks. This commit unifies the system.

Part of https://github.com/odoo/odoo/pull/32793
task-1970731

closes odoo/odoo#32793

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

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.

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