*: website_event{_meet}{_track}{_track_live}
Purpose
=======
Improve event related module UI
Specifications
==============
- The reporting fields, the chat room and the participant count
of the meeting room form should not be showed while the record
is not created.
- Rewording on event track "Button appears" and "Color" field.
- Remove unnecessary helpers in event track form.
- Remove "Wishlisted By" stat button when the count is equal to 0.
- Add many2one widget avatar on lead rule "Saleperson" field and
event track "Responsible" field.
- Add placeholders in event booth form view, event location
tree view, event tags categories form view and event stages
form view.
Task-3280602
Part-of: odoo/odoo#119321
The type fields of actions already defaults to
the model name in the base model definition.
Therefore, specifying `ir.actions.server`, `ir.actions.act_window`
& so on as type is useless (and adds noise since it's the same as
the action model).
closesodoo/odoo#114539
Related: odoo/enterprise#37855
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Purpose: fix domain widget rendering that was broken inside a group
with nolabel="1".
Task-
closesodoo/odoo#102722
X-original-commit: 7d8c1bc64a0accc2e875cd336d2800514973c5c6
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This revision is to make uniform the behavior of the `groups` attribute
on the Python model fields
and on the node in the view architecture.
In both cases, remove the node from the view completely.
Before this revision,
in a back-end view:
- In the Python model, if a field has the `groups` attribute set
and the user is not part of
the groups, the field is removed, completely, from the view.
- In the view architecture, if a node has the `groups` attribute set
and the user is not part of
the groups, the node is made invisible (not completely removed, just
made invisible).
in a front-end view:
- if a node has a "groups" or "t-groups" set and the user
is not part of the groups, the node is removed from the view.
So it's 2/3 cases removing nodes restricted to a group.
and 1/3 case making invisible nodes restricted to a group.
It's simpler to have a uniform behavior for the 3 cases,
simpler to understandard for developers.
In addition, this will help for the goal to cache back-end views.
It makes possible to convert views using the `groups_id` field
by moving the content of these views directly
in the view to which they add content which is suppose to be completely
removed when the user has not the according group.
By getting rid of the `groups_id` many2many field on `ir.ui.view`,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the `groups_id` groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
closesodoo/odoo#95729
Related: odoo/enterprise#29592
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
This commit improves the view inheritance priority and xpaths for
the inherited form views of event to arrange the stat buttons in
logical manner, regardless of installation order of the modules.
The stat button order should always be:
- Attendees
- Leads
- Sales
- Tracks
- Sponsors
- Rooms
Task-2585998
EnterprisePR-https://github.com/odoo/enterprise/pull/20082closesodoo/odoo#74203
Related: odoo/enterprise#20082
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Duplicate lead records are an issue for CRM users
To prevent sales representatives from contacting a prospect that:
- Already refused an offer from another sales
- Already accepted an offer from another sales
- Is already discussing with another sales
The purpose of this task is to inform the CRM user that there are
some possible duplicates for one lead and let the user decide how
to handle the case.
SPECIFICATION
- Add a computed field to count the number of potential duplicates.
- Add a stat button on the form view of a lead to display the number
of potential duplicates. When the user clicks on it, the leads
considered as duplicate will be displayed in a kanban view.
- Add a lost ribbon on the kanban view to quickly visualize the lead
state since the duplicates can be lost leads.
LINKS
Task ID : 2151017
closesodoo/odoo#61834
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps:
- Login as an admin user
- On a fresh branch install event_crm
- Give a "test" user access rights of "Own Document only" in the "Sales"
app, nothing in "Events"
- Assign any lead to "test" user
- Login as "test" user and try to access your own leads
Bug:
Error: While parsing modifiers for button: for modifier "invisible":
Unknown field registration_count in domain
Explanation:
The button `event_registration_action_from_lead` tries to access event
registrations even if the user doesn't have access to events.
opw:2462127
closesodoo/odoo#66599
X-original-commit: 29be97615554337591f0b31ba34942c2d728cbef
Signed-off-by: backspac <backspac@users.noreply.github.com>
* account, analytic, calendar, coupon, crm, crm_iap_lead_website,
delivery, digest, event, event_crm, fleet, gamification, hr,
hr_expense, hr_skills, im_livechat, lunch, mail, maintenance,
mass_mailing, membership, mrp, point_of_sale, pos_mercury, product,
purchase, purchase_requisition, sale_management, sales_team, sms,
stock, stock_landed_costs, survey, website_crm_partner_assign,
website_event_exhibitor, website_event_track, website_forum,
website_slides, base
This commit removes oe_edit_only labels and adds placeholder
on fields in form views from a lot of apps to minimize the
shift when switching mode.
task 2330101
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>
Elisabeth Dickinson