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
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>
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>
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
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
dane@odoo.com