Add QR code on top left corner of the confirmation mail.
It also modifies confirmation page
by showing phone number of organizer and contact mail.
Part-of: odoo/odoo#135153
Before, event badges were an a4 page divided in 4
quarters, meant to be foldable into a single badge.
It contained folding instructions, event instructions
and was white mostly everywhere.
We want to introduce some customization to allow
different colors between ticket types and a background
image.
Therefore, we introduce 3 different formats to print badges
(also sent to attendees through event communication)
- a4 foldable (french fold) (~ previous one but redesigned)
- a6
- a4 4 per page
The templates are intensively redesigned to a new style.
New templates are introduced to match new formats.
Example tickets are still managed, printing an appropriate
example ticket according to the event format.
Printing several event example tickets will still use each
event format appropriately
Models:
- event.event receives a selection field badge_format
and an image field badge_image. This will be printed
on the background of badge cards.
- event.event.ticket receives a color char field. It
can be picked from the event form view with a color picker,
and will be the backgroud of a band on the bottom of badge cards.
Renaming:
Scss file, records and templates are renamed from "_foldable_badge"
to "_badge", as now badges are not always foldable. Namespaces
of selectors follow the same logic. We still have specific
styling for the foldable version so there are still selectors
using a 'foldable' name.
Task-3473293
ENT PR: odoo/enterprise#46163
UPG PR: odoo/upgrade#5126closesodoo/odoo#132855
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
The tickets are reworked, made easier to print and have
their structure reworked for qr code addition (in ENT branch).
Also they are easier to download as buttons are added to do so.
1. Design
Tickets have their background removed in order to ease
their printing. More room is given to details, the design
is simplified.
New RESPONSIVE HTML TICKET
The confirmation email will now contain a link "See tickets"
leading to a new version of the full page ticket, called
"responsive_html". It does not generate / download PDF but rather
leads to a rendered qweb html page, with design working
properly on different screen sizes. The design is a tweaked
version of the full_page ticket template, simplified. It allows
users to see their ticket directly without needing a pdf viewer.
2. Download Tickets Buttons
"Download / See Tickets" Buttons are added in
- Email Templates (Ticket and Badge)
- The SO confirmation (if payment). All tickets, per event.
- The registration confirmation (if no payment). All tickets
in the same PDF. They are for the same event.
In order to access tickets, a route event/my_tickets is added
in the controller. It takes an event_id, registration_ids and
a hash based on those plus the database secret using tools.hmac.
The groundtruth hash is obtained for given registration ids in the
method _get_tickets_access_hash on event.event. The route is
used in all places listed above. The hash must be valid and attendees
must exist.
No condition on payment is set in my_tickets as we want the download
tickets link to work for non-free tickets as well at the end of the
sale process, and as the sale order could not be linked to any invoice
at that stage (if automatic invoices is not set in the settings),
registrations being 'not paid' at that point. This could be cleaned
in further work as different states are to be clarified.
The route must be public as it must work even for public users.
(from email or as public user registering on front-end) Also,
we give sudo access to the course in the case of invitation to
a course that is not yet published, as long as the hash and
registration are valid.
3. Email Templates
In order to have similar mail templates for badge and tickets,
Registration Badge content is duplicated from Registration
Confirmation and slightly tweaked, replacing existing body.
Also, the info of the payment / order moved from full page ticket
to the body of the confirmation email.
PR ENT - odoo/enterprise#41164
PR UPG - odoo/upgrade#5007
Task-3061851
closesodoo/odoo#120933
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In order to allow all communication to be sent in
a chosen language, a 'lang' field is added on the
event.event model. If set (amongst the installed languages)
this language will be used to translate email templates
instead of the partner's one (which is still the default one)
The field is added on the event form view.
Task-3357099
closesodoo/odoo#127540
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
This commit changes the way the identification questions (name,
email, phone) are asked when registering to an event. They aren't
hardcoded anymore and can be created per event the same way other
questions can be. They can be set as mandatory or not and the order
can be changed. One can now also ask for the attendee company name.
Task-3056380
closesodoo/odoo#112164
Related: odoo/upgrade#4313
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Many templates use the company logo that is set by default on
database creation. As that logo is clearly a placeholder and the user
isn't necesserely prompted to update it. It's possible for a user to
inadvertently start sending emails with "your logo" placeholders
plastered all over.
This removes the default logo of the company and removes it from
templates conditionally.
The logo isn't simply replaced with a transparent PNG as the templates
set a fixed height for the logo, which would look weird.
task-3067315
Part-of: odoo/odoo#106307
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#114533
Related: odoo/enterprise#37853
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Google now requires an API key for the static maps API.
As API calls cost money, and we cannot restrict the domain of the caller
with the API key in emails, as the domain may vary vastly,
the signing of static API URLs is implemented in the existing
'google_map_img' of partners.
This in turn can be used to get a url for an existing location.
While preventing anyone from stealing the API key for their own purposes
task - 3079113
Part-of: odoo/odoo#107200
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Update report_template field on template model to be a many2many field instead
of a many2one. It allows to attach multiple dynamic reports to a given template
instead of being limited to a single one.
Name should now come from the report itself, which should be considered as
complete by itself. Template cannot override report naming anymore.
Task-2868153 (Mail: Allow multi reports in mail templates)
Part-of: odoo/odoo#99482
Note:
This is not fixed earlier because this in invalidates
template translations and this isn't a major issue.
Invalidating translations on 16.0 should still be
fine as of writing this.
Issue:
Google recently added a requirement for an API key
to their static maps API. This means we can no longer generate
<img> tags linking to the google API without using a key.
As we send that key inside emails, it cannot be protected
by origin policies to prevent people from using the key outside
of the domain of the database. Protecting it would require
implementing signed google API requests, which cannot be
done both quickly and sanely on stable.
Fix:
This commit replaces the image with a generic string to get rid of the
'missing image' icon. A better fix/imp may be introduced on the master
branch at a later time.
task - 3079113
closesodoo/odoo#109797
X-original-commit: a730c9920bc82a6637882f325ca3d947ca0ddd78
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
* = event, event_booth, website_event_questions
We used to provide data for the event templates (event.type) to provide a basic
configuration to play with. However, they are not much helpful, and sometimes
can confuse the users.
This commit removes the data records for the event templates, and on the
m2o field on event, now we let users create/edit them on the fly so that
they can explore the feature by themselves.
We have also added demo data to the 'Exhibition' and 'Sport' templates,
having booths and questions, respectively. Along with that, we have added
relevant data to the demo events where both templates were used; and set
auto-confirm to be false by default when creating a new event template.
taskID-2854123
closesodoo/odoo#99421
Related: odoo/upgrade#3849
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When the price and the event are the same, nothing allows
ordering tickets in event_sale. Therefore, add a sequence
number and handle widget to the tickets (in data as well).
Also do it for ticket templates. Also, order the tickets
(on events and templates) by name before id.
Since event type tickets are not linked to any event, the
order does not include the event_id. However, event event
tickets are, and if they appear in the same list / reporting
someday, it makes sense to order them by event_id first.
In event_sale, we make sure the price is also in the order.
As the price is in the copied fields on the event when
using an event template, we add the price on the event
type tickets ordering to align with the event event tickets.
Add default value to sequence and sequence number to data
for event.type model. They were sequenced but demo data had
none, hence not really ordered.
We also add the id in the event.event _order value, otherwise
when ordering on the event (for instance ordering on event_id
for event.event.tickets), the order is random for events
having the same date_begin. We prevent this from happening.
Also make description optional hide on event types.
Task-2997391
closesodoo/odoo#101384
Signed-off-by: David Beguin (dbe) <dbe@odoo.com>
Allow our users to modify mail template more easily
- make the list accessible from the settings
- give them a link to update relevant views to update header/footer
- make the list and form of templates more readable
- add a description on templates, allowing to describe their usage
In order to better filter templates, a new category field is added that
is computed based on active flag, description being set and the template
having an xml ID. Master templates are active, with a description and an
xml ID.
Update master data to add description on some templates.
task-2944770
closesodoo/odoo#101730
X-original-commit: dfa867343ee8842f3f127ac62584fd471b41dde1
Related: odoo/enterprise#32079
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
As an event manager, it can be difficult to estimate how much of the revenue
was generated by the events. To give clear insights, we will add new reports
to the 'event' module.
With those new reports, the user can group the revenues by event (type),
ticket, product, etc. The user will then be able to quickly see which tickets
and events are the most profitable ones. The reports will be accessible only if
the user installed the 'sale' module.
Task-2679881
See odoo/enterprise#24472
Part-of: odoo/odoo#81583
Co-authored-by: Florian Charlier <flch@odoo.com>
Co-authored-by: Julien Banken <jbn@odoo.com>
* = website
Change the wording of the sms reminder template to make it sound friendlier and
more complete. The sms will include the event address if it is defined.
Otherwise, it will link to the event page if website is installed.
A one line-formatted version of the venue is added to the model to be used in
the template and other places.
This required to update `event_registration.get_date_range_str` to not include
the time when describing an event happening more than a month from the current
date, which makes sense as there is no reason to specify the time only in that
case, and we add the time somewhere else when it's useful anyway.
For consistency, Wembley Stadium is updated to London timezone in the demo
data.
Task-2777183
closesodoo/odoo#85664
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Cleanup all the places where an hour or a datetime is been used
to display with the date the corresponding timezone.
The goal is to know the timezone used where a datetime is displayed
on the event pages.
task-2458013
COM PR: odoo#78049
Part-of: odoo/odoo#78049
Jinja as a templating engine was problematic in differents respect:
- introduce external dependency to Odoo (less controll)
- add another templating mechanism in the stack
- specific feature in qweb cannot be reused
- difficulty in rendering easily editable templates
- more knowledge required with no betterment
By replacing jinja with qweb we can now build tools to edit a qweb
that will work with the previously jinja encoded document
(essentially `mail.template` records).
There is a catch however. Some email fields (eg. email_to) used jinja
syntax for rendering dynamic variables (ie. ${object.something} and
${object.something_that_should_not_be_escaped | safe}).
We still want user to use dynamic variables for some char fields (eg.
subject, from, to, ...). We made a new rendering engine called
"inline_template" that will render an expression enclosed by `{{` and
`}}`.
To be able to edit the templates from the backend interface, a
plugin to the Odoo editor has been made for seamlessly edit the
document.
This qweb plugin includes:
- make dynamic variables (eg. `<t t-out="variable"/>`) not editable
(for preventing the user to shoot himself in the foot)
- group and hide related logical branching (ie. t-if, t-elif, and t-else)
in order to see only one at once
- a floating select input to switch visibility of a particular logical
branching
Task-27033
X-original-commit: odoo/odoo@68182baff4
Part-of: odoo/odoo#77377
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
Purpose
=======
A new module "Event Social" will be added in the enterprise PR. This
new module will use a new template type, the "Social Post Template"
adding one more column in the communication tab...
We want to have only one column to select the template (Mail, SMS or
Post template) and therefor we need to use a reference field.
Technical
=========
As we can not set a domain on a reference field, we added a context key
and in the `_name_search` of the `mail/sms.template` we filter with the
domain we want if the key exists.
Links
=====
Task-2127615
See odoo/odoo/pull/46304
See odoo/enterprise/pull/7701
See odoo/upgrade/pull/848
changed the start/end date fields to datetime fields, in order to allow more
flexibility for the user and enable them to set a precise point in time at
which ticket sales should start/end, because otherwise ticket sales/end would
always be set at midnight which is not very flexible.
Task-2431440
closesodoo/odoo#65133
Related: odoo/upgrade#2126
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to remove the "done" field computation. Indeed
it is based on either
* mail_sent field if scheduler is global to the event (before or after
event). This computation is light as this field changes only once
when emails are scheduled and sent;
* status of event registrations compared to all sent communication on
those registrations. This is costly as adding a new registration changes
In this commit we therefore
* rename ``done`` to ``mail_done`` to ease grep and understanding;
* remove ``mail_sent`` as it is integrated within ``done``;
* manually update ``mail_done`` when updating schedulers instead of doing
it through a compute method;
Some code cleaning is performed to make it clearer and easier to understand.
LINKS
Task ID-2414658
COM PR odoo/odoo#63093
UPG PR odoo/upgrade#2014
this commit aims at refining the UX for events, notably:
- create a helper for the magic button on the event_track form, because without
this the user won't be able to understand what the button does.
- on stage update, the kanban state will be automatically set to "gray"
beacause when changing stages it does not make sense to keep the previous
kanban state especially when it is set to "green" or to "red".
- make the cost of the event registration product demo data lower then the sale
price as it is not normal to have a sale price lower then the cost.
- change the style of the "discover all our events" marketing link in the event
reminder email template in order to make it pop a bit more for the user as
this is an important link
Task-2451125
closesodoo/odoo#65613
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In the change 6ba81c99 there was an issue with timezone with Google
because we were now sending "20201217T123000+0000" instead of
"20201217T123124Z".
When google received formatted date ending in Z it would treat it as
UTC, but with +0000 ending he treats it as a locale time thus get it
wrong if locale timezone is different than UTC.
opw-2370895
closes#62943closesodoo/odoo#62970
X-original-commit: b68ca9fb1d3f8c0a6346fa1d3d6cce28f4977bbd
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
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
Issue
- Install 'Event' module
- Go to 'Event' and select any event
- Click on "Attendees" stat button
- Click on any attendee ( or create one if not any)
- Confirm ( if not already confirm) registration
- Click on "Send by email"
- Change template to 'Event: Registration' then send
- In the chatter, check Google or Yahoo calendar link
Bad link.
Cause
Wrong 'dt_format' pattern generate a broken datetime value;
current format work with time.strftime() but not 'babel' library.
Solution
Update 'dt_format' pattern to match with babel library since it's the
one used in 'format_datetime' func.
> Note that Babel uses different patterns for specifying number and date formats compared to the Python equivalents (such as time.strftime()), which have mostly been inherited from C and POSIX
ref : http://babel.pocoo.org/en/latest/dates.html#pattern-syntax
opw-2370895
closesodoo/odoo#61394
X-original-commit: ab03fa39c716f717ee78c30e41727a85234b5c9d
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
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>
RATIONALE
Events are sometimes held online, gathering a community. In this merge we
improve Event application to better support full-online events with improved
tracks, wishlists, chat rooms, ...
PURPOSE
Prepare Event Online support by providing fixes in registration and event
frontend flows. Also provide a quick back2basic in backend views to prepare
addition of Online sub modules.
SPECIFICATIONS: CONFIRMATION / REMINDER EMAIL
Reorder a bit content: add links to add to calendar directly in header
text, between confirmation and signature.
Add a section holding a link to PWA in order to showcase it to customers.
Apply fixes :
* correctly use 50% width only for date / location display when location
is not set;
* correctly put jinja tags to make valid html, otherwise edit / save template
breaks it when browse move jinja tags a bit randomly (e.g. %if between
tr tag is not valid html and broken by design);
* correctly compute horizontal separation lines, display them only when there
is actually some content to separate;
* correctly support organizer / no organizer, address / no address and
online / not online in all template;
Notes: this require to re-generate the whole translations templates of both
templates but this seems a required pain. Indeed current template are broken
beyong redemption.
Fixes notably cfca2bb0ff
LINKS
Community PR odoo/odoo#55197
Enterprise PR odoo/enterprise#12113
Task ID-2309702 (Event Preparatory Merge 4)
Prepares Task ID-2252655 (Main Online Event task)
Prepares Task ID-2283796 (Event B2Basics / Registration Flow)
Prepares Task ID-2299857 (Event Design Review)
PURPOSE
Prepare Event Online support by providing fixes and preparatory cleaning
commits.
SPECIFICATIONS
As new Online Event feature is about to land new and improved demo data
is necessary to showcase it.
Add a new event for demo data that will be used to showcase the "online"
features to be added soon. Add some interesting demo on it: tags, tracks,
sponsors, ...
LINKS
Task ID 2289148 (Event Bugprovements)
Prepares Task ID 2252655 (master Online Event task)
Prepares Task ID 2283796 (Event B2Basics)
PR #53944
X-original-commit: 553e835eb87a750312bed8e188b3ba82e811f7cc
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>
PURPOSE
Prepare Event Online support by providing fixes and preparatory cleaning
commits.
SPECIFICATION
Currently tickets demo data are not correctly created as they mess up with
automatic ticket computation from event_type configuration.
Solution is to flush event creation. It means tickets default configuration
is computed. Afterwards tickets are created in demo and avoid clashing with
the compute in cache.
LINKS
Task ID 2289148 (Event Bugprovements)
Prepares Task ID 2252655 (master Online Event task)
Prepares Task ID 2283796 (Event B2Basics)
PR #53944
X-original-commit: 6b5ec74b3d9bc008c95a92e7fa954675ae506d1a
PURPOSE
Prepare Event Online support by providing fixes and preparatory cleaning
commits.
SPECIFICATIONS
Currently no tags are set on demo data due to strange construct of eval
and ref. This commit fixes those strange demo definitions.
LINKS
Task ID 2289148 (Event Bugprovements)
Prepares Task ID 2252655 (master Online Event task)
Prepares Task ID 2283796 (Event B2Basics)
PR #53944
X-original-commit: b2b53a6ca02e3e9f51b665bd24cc1d2fee0dc3b9
PURPOSE
Fix various issues spotted in 13.3 when testing event. Notably
computation of 2many fields coming from template.
SPECIFICATIONS
When updating template on an event, one2many fields should be better managed.
Previous heuristic was
* if event type uses o2m configuration (use_ticket / _schedule / _question)
and has lines
* erase existing lines;
* create new lines based on old one;
This has the drawback of loosing information of what is sent (mail) or
sold (tickets) or answered( questions). Another drawback is that only
types having line are synchronized. This means that if updating several
times the event type you could end up with an XMas configuration with
lines coming from different event types, depending on their o2m configuration.
We choose a better heuristic that should solve this issue
* every time we change type, independently of its use_* field that is used
mainly for UX on the type itself:
* erase existing lines that have not been used yet (no mail sent, no
ticket linked to registrations, no answer linked to registrations)
* create new lines based on old one; if type has no lines, event will
have its old empty line erased as well;
It means that we try to synchronize more the type to the event while keeping
configuration line already used in some registrations.
Also provide some other fixes like deletion restrictions or better domain
for UX purpose. See sub commits for more details.
LINKS
Task ID 2244487
PR odoo/odoo#52998
FwdPort of odoo/odoo#52923
X-original-commit: 645f70cad033083e82a3ef9102c694c331badef9
Co-authored-by: Sebastien Mottet <oms@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
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
closesodoo/odoo#52472
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Change seats_availability selection field into a boolean field
and rename it to seats_limited for consistency.
SPECIFICATION
Change all the tests accordingly.
Task ID : 2198660
PR : #46659
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
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
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>
This commit removes the field twitter_hashtag from event and event_type.
The justification behind this change is that it has been made obsolete
by our social marketing app and our website builder.
Task ID 2191921
Community PR odoo/odoo#44715
Upgrade PR odoo/upgrade#764
Related: odoo/upgrade#764
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
RATIONALE
Mail template model holds a field telling odoo mail engine to automatically
add the current user's signature to the body. Its use depends on the use
case
* using the template in the composer on a single record: it is displayed
in the rendered template in the composer, meaning people could change it.
This behavior is interesting as it allows to see the email content;
* using the template in the composer in mass mail mode: it is not displayed
as only the raw jinja is displayed. It is therefore not obvious that it
will be appended to the body of the mail. People could add it manually and
have 2 signatures as a result;
A mechanism automatically adding a signature to sent emails when posting a
message is already implemented and is based on template existence. If a
template has been used when posting, no signature is added in sent emails.
Otherwise it is automatically added. This behavior should not change.
Behavior will therefore be
* use a template -> specify signature usage in it manually through jinja;
* do not use a template -> signature added in sent emails;
SPECIFICATIONS
Remove user_signature.
Update template body accordingly. In customer oriented templates that are using
it and do not already contain it, manually add a call to user.signature within
the jinja code. When set to False, just remove its declaration.
Quickly clean some signature integration.
LINKS
Task ID 2089252
Community PR odoo/odoo#39482
Enterprise PR odoo/enterprise#6459
Upgrade PR odoo/upgrate#761
Related: odoo/enterprise#6459
Related: odoo/upgrade#761
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
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
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
Before this patch, the event link could be sent in the email even
if it was unpublished by hand.
Now, if the event is unpublished, no link appears in the
registration and reminder email.
closes odoo/odoo#37842
Closes: #37700
X-original-commit: 9878f319520861578ccc49796f4335f99ad49f9b
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
dane@odoo.com