Change event onboarding rainbow message to something more relevant. Default
message is considered as less user friendly than the new one.

Before this commit the category_id for a tag had no label displayed. We choose
to wrap the category_id field inside a group so that field labels shows up.

In settings, wrap the tag_ids inside a div.o_setting_right_pane so we can have
the left border displayed correctly, like most fields in settings.

Finally remove "Online" template from the event_data since it acts like a
dummy type without pre-defined data.

Task 2257884

closes odoo/odoo#52472

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

PURPOSE

Change the event form view to improve its usability and make it clearer.

SPECIFICATIONS

- Change some stats buttons icons
- Change order of the fields and put the range date field in second
place since it's a mandatory field.

LINKS

Task ID : 2198660
PR : #46659

Notably clean a bit existing event type (data and demo) and add some questions
on conference event type.

LINKS

Task ID 2089156
Community PR #42911

PURPOSE

Integration between event and eCommerce is required only when users handle the
entire selling process online. However users may require ticketing support
while managing payments outside of Odoo. Purpose of this commit is to support
tickets directly in event application without need of sales.

RATIONALE

Remove the need to have event_sale installed to manage basic multi ticket
event type. Integration with eCommerce is needed only when one wants to handle
the entire selling flow online, i.e. order, payment, ... Integration with
Sales is needed only when one wants to create sale orders linked to attendees.

Many event users do not need all of this. Their attendees pay through bank
transfers or they simply manage payments outside of Odoo while still
requiring tickets management.

SPECIFICATIONS

Remove the need to have event_sale installed to manage basic ticketing on
events.

Move ticket model (event.event.ticket) directly into event, copying most
fields from event_sale. Only sale specific fields and behavior should be kept
in event_sale :

  * keep product_id and price information in event_sale;
  * keep sales analysis in event_sale;

We also split tickets model used for event type (event.type.ticket) and
events (event.event.ticket). Indeed previously to this commit both are
modeled in the same table, with the following issues :

  * tickets on templates use only a subset of fields: name, seats availability,
    product, price;
  * a ticket has either an event_id, either an event_type_id, and there are
    constraints to try to avoid having lost tickets. This leads to a strange
    model where m2o fields are required only in some cases with a dual
    behavior;
  * tickets are not shared between event.type and event.event. They are copied
    and having a single model is therefore not necessary;

We therefore choose to have a light model for event.type.ticket. It is linked
to event.type when configuring template tickets. They are copied in the
onchange copying event template configuration to the event itself, leading
to event.event.ticket creation.

Some tests are moved / completed accordingly.

Access rights are copied from website_event_sale to website_even concerning
ticket access for public / portal. Currently they are kept as they are with
some rewording as it is not the purpose of this commit to rewrite them.

LINKS

Task ID 2177281
Community PR odoo/odoo#43488

In this commit we clean some event.type definitions. Indeed there are several
of them without any real use, demo as well as data. It is more important to
have fine-tuned demo and data than a lot of unused or generic demo.

LINKS

Task ID 2177281 (support tickets directly in event)
Prepares Community PR odoo/odoo#43488
Closes Community PR odoo/odoo#44066

Purpose
=======
Remove the state on the event and add a stage.
So, we can have more control on the event flow, and we will have less constrains.

Website event
=============
Before
------
People can register for an event if "seats are available" and if the state is "confirmed".

After
-----
People can register for an event if `event_registrations_open` is True,
- Event: seats are available and the event is not finished
- Event sale:  One or more ticket has `sale_available` set to True

Task #2088538

Currently even module logs a message in all employee channel with a
message telling the module has been installed. It is not interesting
as it gives no real information and is not interesting for users that
do not use event module and/or do not have access to it.

Let us remove that data.

This commit adds several event categories as data in event modules. The
purpose is to help people using the event application with some help
on event configuration done through event categories.

This commit improve event.type (Event Categories) model and views in order
to ease event configuration through more detailed categories. The purpose
is to be able to define categories holding default data for website,
tickets, attendee mailing, ... Choosing a category on a new event takes
those default values to help users creating finely-tuned events.

Main configuration on event.type is

 * auto confirmation, replacing the old system-wide auto confirmation
   parameter
 * seats limitation
 * location: online events, timezone
 * communication: reply-to email address, twitter hashtag, automated
   mailing of attendees
 * ticketing
 * website parameters: display on website, display tracks, allow track
   proposal
 * question to attendees