PURPOSE

Provide some fixes after internal test deployment of event online features.
Notably: user registration flow, various fixes in templates.

Also add some unit tests to avoid regressions while working on event features.

LINKS

Task ID-2169118
odoo/odoo#55967
odoo/enterprise#12438

X-original-commit: e66684b23eebaadc3df7b908427d3d7a83d4f0a0

This commit changes the display name for the model event.type from
"Event Category" to "Event Template"

This change was needed before introducing the new model event.tag.category
which will be used to group tags (event.tag)

This commit introduces two new models: event.tag.category & event.tag

The tags will be grouped by category and will be used to filter events.

In the front-end, if the user activates the "filter by categories", each
event.tag.category will generate a new dropdown of related tags.
Clicking on one of these tags will add a new "tag badge" above the events
(same way as in eLearning).

LINKS:

TaskID:2162438
PR: #43856

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

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

OPW 1859364

We need to fix a problem with the users where someone might get
informations on registrations.

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

 * reporting: remove report.event.registration as it can be replaced by
   pivot and graph views on event.registration model directly. The
   custom SQL view does not add any valuable information;
 * event: correctly take limitations from event category and check
   minimum seats is lesser or equal to maximum seats;
 * event: reorganize a bit the form view

  * avoid some kind of random ordering of buttons;
  * move seats availability directly in the form view;
  * ticket page is now used only for ticketing purpose, not a mismatch
    with seats;

 * registration: attendees can be set as done only for confirmed events
   to avoid confusion when working with draft events;

Misc usability

 * event.type: rename event type to event category to have a unified
   term across various event addons;
 * event: stop tracking active field as it does not add interesting
   information; it should not toggle everyday;
 * event: track location as it does add valuable information;
 * event: rename some labels to ease user experience;
 * event.mail: add missing description and rec name;