Partial backport of odoo/odoo@94fa8d9625 keeping only event_crm part as
other changes were done only for Odoo16.
In this commit we try to compare formatted phones of registration and
partner, before checking the actual phone numbers. If only formatting
differs then it is not a different number.
Task-3431124
X-original-commit: 4589eebe4978ac0746fa4bc5c8664cb30d912cc1
Part-of: odoo/odoo#129269
When checking if partner and registration have the same email, better compare
normalized versions if possible as it filters out formatting differences
e.g. if one input has a formatted email with another name.
Task-3431124
X-original-commit: 1f2a08e6b0880d20f877a73badd3b071939bcc13
Part-of: odoo/odoo#129269
When having rules creating leads from registrations, email and phone are
copied from the registration if the linked partner has no value for those
fields. However an error in the code lead to setting phone into email which
is not really correct.
This commit also add tests for event_crm who allowed to spot other issues
which are fixed in the next commits.
Task-3431124
X-original-commit: 9bbf621e8e9cda90a0d29fd44e21cd4b61a54d73
Part-of: odoo/odoo#129269
Purpose is to have a common event class for users and useful stuff (customers,
products, ...) but lessen usage of common test data through sub modules.
Indeed having a "global event type" test data updated in various addons is
actually complicated to maintain.
Sub add-ons are updated to use mainly the ``EventCase`` test class holding
users and side data. Data specific to those modules (event type with some
specific configuration notably) is created and used in tests in the given
module only, and not through generic event_type_complex and event_0 test
data anymore.
With this commit tests are more localized to their add-on and modifying data
in a given add-on has less chances to have unwanted side effect in other event
submodules unit tests.
Task-2703285 (Event performance improvements)
Task-2703289 (Event testing and coverage)
Part-of: odoo/odoo#81068
Purpose of this commit is to ensure side documents are redirected to the
master opportunity when merging leads. Those side documents include
* communication history (mail.message);
* attachments (ir.attachment);
* visitors (website.visitor);
However some documents are currently not specifically handled :
* meetings (calendar.event);
* activities (mail.activity);
* sale orders (sale.order);
* attendees (event.registration);
In this commit we ensure all are attached to the final master opportunity.
That way we prevent loosing access to those documents and ensure we keep
the complete history of all merged leads.
Also tests are added to ensure the merging of leads and its contents.
A new field is added to have the o2m field between leads and calendar events.
In order to clarify naming, ``meeting_count`` is renamed to
``calendar_event_count`` to match naming.
Task Id-2457941
COM PR odoo/odoo#68884
UPG PR odoo/odoo#2494
Related: odoo/upgrade#2494
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Use Case
--------
Have two (or more) rules with mutually exclusive domain for that can be
apply on the same event with lead_creation_basis = order
Create a registration that match one of the rule
Problem
-------
The lead for this rule is created properly but there is also
another lead with the name False - False that is created for the second
rule for which the registration does not match the filter
Solution
--------
Create a lead only when there is a non empty record set in the
registration group
closesodoo/odoo#70590
X-original-commit: 43fc8dac5e21a9aecf7b2950a6c3c77d8142ee45
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Clean the ACLs related to the Event application.
Add a new group to manage the registration in the entrance of an event. This
group should not be able to modify or remove records in Event but should be
able to create and manage the registrations.
Specifications
==============
Now, there are 3 event groups
* ``Registration Desk User``, who can manage the registrations and
read all event-related information;
* ``Event User`` who can create event, sponsor, ticket... His role is
to globally handle events on a day-to-day basis;
* ``Event Administrator`` who can create event type, sponsor type,
ticket type... His role is to manage the way events are managed withint
its company:
Each group implies all previous groups.
Compared to previous event users gain a lot of rules, allowing to update
records like tickets, registrations, ... Low-end event users should now
use the registration desk group.
Links
=====
Task ID-2204364
COM odoo/odoo#57022
ENT odoo/enterprise#13984
UPG odoo/upgrade#1897
PURPOSE
Introduce an automated tool to create leads from event registrations. Events
are a powerful source of leads as they attract attention. This leads to leads
with good quality as they mark interest while gathering contact information
which allows to follow-up.
This merge aims at automating this process by automatically creating leads
based on user-defined rules.
SPECIFICATIONS
Add a new module event_crm. It allows to create leads automatically based on
event registrations. This is done based on rules defined in a new model
event_lead_rule.
Add a new menu "Lead Generation" in the configuration tab of an event. It
allows to create generation rules. Those are a set of conditions to generate
a lead with some pre-filled values as the type of lead, tags or salesperson.
SPECIFICATIONS: CREATION TYPE
There are two types of lead creation:
* per attendee: create a lead for each registration;
* per order: create a lead for a group of registrations;
The last one is only available through interface if it is possible to register
a group of attendees in one action (when event_sale or website_event are
installed). Behavior itself is implemented directly in event_crm.
Basically a group is either a list of registrations belonging to the same
event and created in batch (website_event flow). With event_sale this
definition will be improved to be based on sale_order.
SPECIFICATIONS: CREATION TRIGGERS
There are three options to trigger lead creation. We consider basically that
lead quality increases if attendees confirmed or went to the event. Triggers
allow therefore to run rules:
* at attendee creation;
* at attendee confirmation;
* at attendee venue;
This trigger defines when the rule will run.
SPECIFICATIONS: FILTERING REGISTRATIONS
When a batch of registrations matches the rule trigger we filter them based
on conditions and rules defines on event_lead_rule model. Heuristic is the
following:
* the rule is active;
* if a filter is set: filter registrations based on this filter. This is
done like a search, and filter is a domain;
* if a company is set on the rule, it must match event's company. Note
that multi-company rules apply on event_lead_rule;
* if an event category is set, it must match;
* if an event is set, it must match;
* if both event and category are set, one of them must match (OR). If none
of those are set, it is considered as passing;
If conditions are met, leads are created with pre-filled informations defined
on the rule (type, user_id, team_id). Contact information coming from the
registrations are computed (customer, name, email, phone, mobile, contact_name).
SPECIFICATIONS: OTHER POINTS
Note that all rules matching their conditions are applied. This means more
than one lead can be created depending on the configuration. This is
intended in order to give more freedom to the user using the automatic
lead generation.
Once a lead is created for an event registration, a stat button on the event
is available to show the number of leads generated for this event and to
be able to find them in one click.
Additionally on the lead form, a stat button will be display to show the
registrations linked to this lead. On registrations a stat button is also
displayed to find the leads created from it or from its group.
Most of code has been written to run in batch, in case multiples rules have
to run on a set of new registrations. Tests are added to ensure behavior.
LINKS
Task ID 2166679
PR #52334
Upgrade PR odoo/upgrade#1292
Co-Authored-By: Jérémy Hennecart <jeh@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Thibault Delavallée