This commit introduces a new badge report displayed on a full A4 page.
This report is meant to be printed for the attendee and contains more
detailed information that the existing "badge report", which is only meant to
be folded and used as a badge.
We use a lot of custom layout and classes to create a "ticket-feeling" to the
report and make it look good visually.
We also introduce a new field that allows easily customizing (outside of
studio) this report by adding "extra instructions" (how to use your ticket /
directions on how to get to the event / ...).
Side note: scss disclaimer
As the reporting engine does not allow complex class/rules building, we had to
implement this nice layout using very well placed background-image and
"pixel perfect" sized elements.
LINKS
ENT PR odoo/enterprise#19349
UPG PR odoo/upgrade#2599
Task-26779
PURPOSE
The event foldable badge is currently not very user-friendly in terms of usage
and style.
This commit aims to re-work it visually as well as getting rid of multiple
technical flows (unnecessary fields / no studio anchors / ...).
SPECS
Preliminary cleaning : Unify both foldable badge templates into one.
The "event badges" report can be printed from 2 different sources, from the
event.event itself as a preview and from the event.registration as an actual
badge for a specific attendee.
The implementation was done using two different templates, leading to a lot of
duplicated code and potential issues when editing one template that would not
modify the other accordingly.
This commit unifies both templates into one.
When the report is printed from the event as a "preview", we simply check that
the attendee variable is missing and print placeholders instead.
Main changes : Rework the whole foldable badge template
1. Get rid of unnecessary fields
The foldable badge template used several fields on the event.event model itself
that would allow customizing the report per event.
However, there were actually no way for the user to access and edit those
fields, as they are not part of any views.
We therefore removed them (badge_front, badge_back, badge_innerleft,
badge_innerright, event_logo).
And instead offer a single new field (ticket_extra_instructions), available on
the form view of the event, that allows to easily customize the foldable badge
and adding instructions specific to this event (how to come / what to bring /
...).
2. Visual changes
The report was re-worked to make it look a bit more recent, as the previous
look was very basic and was not very attractive.
This was done using a specific scss file that allows defining rules without
bloating the template with long style attributes.
In addition, we added some pictures that help the attendee understanding how to
correctly fold the printed A4 sheet into a badge and slide it into the holder.
All the information that were previously on the report should still be there.
3. Relocate action from website_event to event
As a bonus, we moved the reporting action from website_event to event, in order
to have everything that is related to this foldable badge in the same module.
Side note: scss disclaimer
As the reporting engine does not allow complex class/rules building, we had to
implement this nice layout using very well placed background-image and
"pixel perfect" sized elements.
You will see a lot of hardcoded numbers, mainly on heights, but it can't be
helped.
LINKS
ENT PR odoo/enterprise#19349
UPG PR odoo/upgrade#2599
Task-26779
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Conversion of all modules to the new manifest assets declaration.
Part of task: 2352566
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
Purpose
=======
Show an icon representing the state of the event mail and number of contacted
registrations instead of the simple checkbox "sent".
Specifications
==============
Instead of the checkbox "sent", an event mail can have 3 values
1. Sent, if all the mails has been sent;
2. Scheduled, if scheduled but no attendee have been contacted;
3. Running, if not all attendees have been contacted;
Note that communication targeting "after registration" are always considered
as being "running" as any new registration triggers a new communication.
A new widget is added that displays an icon depending on the state.
A new field holding contact count is added. When scheduler send emails it is
updated to keep a count of sent communications.
LINKS
Task ID-2414658
COM PR odoo/odoo#63093
UPG PR odoo/upgrade#2014
RATIONALE
Events often have sponsors displayed on their front page. This should be
a real standalone feature of Online Event application. However currently it
cannot be used without tracks managements
PURPOSE
Purpose of this task is to allow to use and display sponsors on an Event front
page without using tracks. Moreover online and chat capabilities should be
part of a sponsor feature, located within website_event_exhibitor module.
SPECIFICATIONS
Merge website_event_track_exhibitor into website_event_exhibitor and remove
dependency on website_event_track. That way all features related to sponsors
are now located within website_event_exhibitor.
LINKS
Task ID-2326433
COM PR odoo/odoo#61781
ENT pr odoo/enterprise#14752
UPG PR odoo/upgrade#1931
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
PURPOSE
Clean organization and models linked to Event Online feature introduced in
semi stable saas-13.3 at odoo/odoo@981f95bbf4 and odoo/enterprise@14722028ae
Also clean website event menu not being available in website event but only
in website event track, which implies some extra-code to manage it.
In short: merge website_event_online in website_event, website_event_track
_(online/session) in website_event_track.
RATIONALE
_online modules have been added to extend content of website_event and
website_event_track without having any impact on those module. First step
of cleaning is to move this content directly in base module.
track_session module is mainly a rewrite of track module. Second step of
cleaning is to move its content directly in website_event_track.
SPECIFICATIONS
Move event.tag color field from website event online to event. This field is
part of standard event models.
LINKS
Task ID-2319779
COM odoo/odoo#56067
ENT odoo/enterprise#12520
UPG odoo/upgrade#1654
RATIONALE
Even will soon gain a major update called Event Online, allowing to better
support full-online events. In order to prepare its merge, preparatory merge
are done to lessen the final diff.
PURPOSE
As new "Online Event" support is about to land, new and improved demo data
is necessary to showcase it. Improve online event demo data: have more tracks,
tags, colors, speakers, partners, descriptions, ... Make it WOW and AMAZING.
Improve demo data, especially track-related demo data: more tracks, better
datetimes, titles, tags, ... in order to have at least one event that looks
like a real event.
LINKS
PR #55260
Task ID-2310491 (Event Online Preparation 5)
Part of Task ID-2252655 (Main Online Event task)
Part of Task ID-2283796 (Event B2Basics / Registration Flow)
Co-Authored-By: Aurélien Warnon <awa@odoo.com>
Co-Authored-By: David Beguin <dbe@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
This commit will clean the code by removing the field
'color' from model 'event.event' since the field is
not used/needed anymore.
Task ID 2243918
closesodoo/odoo#50155
Related: odoo/upgrade#1124
Related: odoo/enterprise#10199
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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
Allow to use UTMs directly in event, notably to be able to sort or make
statistics on registrations.
SPECIFICATIONS
Move all UTMs fields definition to event. In base event module they are
set by hand or through links (when using mass mailing for example).Shared
links with utm bits defined in it allows to track marketing statistics
on registrations.
In event_sale registrations can be linked to a sale order. UTM information
are copied from the sale order to the registration itself. Order defined utm
always erase default one coming from event.
LINKS
Task ID 2212297
Community PR odoo/odoo#47229
Related: odoo/upgrade#913
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In order to have an easier and better time showcasing the functionalities of
event, demo data had to be improved.
LINKS
closes odoo/odoo#45372
Taskid: 2170834
Pr: #45372
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
This field is deprecated. Since its usage was to trigger a warning when
trying to confirm an event and confirming an event is not done anymore,
it has become obsolete.
SPECIFICATION
remove seats_min field and usage from event.event
remove default_registration_min field and usage from event.type
LINKS
Task ID : 2192652
PR : #44938
PURPOSE
This commit is part of ticket model support directly in event application.
SPECIFICATIONS
Some demo data is updated in order to be able to show directly tickets
feature in event, with some registrations already configured. Some basic
demo for questions is also added on first event demo in order to have a
complex event usable in demo mode.
LINKS
Task ID 2177281
Community PR #43488
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
This commit is part of ticket model support directly in event application.
SPECIFICATIONS
In this commit we move menu definitions in their own file. It eases views
split and move, as otherwise there are dependencies between files that are
complicated to solve. Better to have menus defined in a main file, and updating
them at will afterwards.
We also improve menus sequences and groups, as some were missing or badly
defined.
Registration tree view is slightly updated to include phone and mobile numbers
as those are used notably for communication. They are hidden by default
like email.
Finally a small tweak of event kanban view is performed, notably to have
a better display with dependencies installed. We ensure all cards have the
same height.
LINKS
Task ID 2177281
Community PR #43488
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Co-Authored-By: Stéphane Debauche <std@odoo.com>
PURPOSE
As event will soon evolve (onchange -> compute, code improvements, addition of
new features) cleaning and improving tests is necessary to help avoid issues.
SPECIFICATIONS
Use _tz_get for tz-based selection fields from partner as it smartly order
available timezones.
Remove a strange "event.confirm" wizard that calls an unexisting method,
is not reachable and is actually completely unnecessary.
Reorganize ticket fields to ease future improvements and perform some
public -> private method cleaning.
Remove duplicated code in event_sale.
LINKS
Side effect of Task ID 2089156 (event onchange to compute)
Community PR odoo/odoo#43127
Enterprise PR odoo/enterprise#7656
prout
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
Purpose
=======
Access group terminology is missleading. Yous have to be manager to administrate
an application. This task consists to rename groups to be understandable for everyone.
Groups should be reorganised on the users form to be more explicit.
Specification
=============
1/ Rename 'Manager' to 'Administrator' in users groups.
2/ Define a hierarchy on access groups by using the category_id in the manifests
A category 'Operations/Project' will create a category Project with a parent
category 'Operations', and something smart is already developed (in modules/db.py)
to avoid duplicating categories.
3/ Add a group in expenses to be able to approve expenses reports for my team.
4/ Add a group in timesheets to be able to approve timesheets for my team.
5/ Remove partially the useless crap in ir_module_category_data.xml
6/ Sort access rights groups on users form according to its parent category
closesodoo/odoo#29362
Signed-off-by: "Yannick Tivisse (yti)" <yti@odoo.com>
Ics file generation should be possible even when only event is
installed as it is a basic feature of events.
Moreover we need to be able to generate such files in order to replace
the old outlook api used in the event templates, api which is not
supported anymore.
We decided to use ics files because it is supported by most calendar
schedulers hence working with outlook.
Linked to task #1853063closesodoo/odoo#28477
The reified view on the res users will be dropped in the following commit.
The previous commit adds support to define each group as a computed field on the res users.
This commit defines:
- A boolean field for each 'isolated' res.group, i.e. a group in the hidden category.
- A selection field for each 'Application' res.group, i.e. a group in a application category.
Example:
- The group to manage pricelist in sales becomes a boolean field
- The groups project user/manager become a selection field
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.
* 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;
Aurélien Warnon