| Age | Commit message (Collapse) | Author |
|---|
|
Purpose
=======
Allow to customize the preview text in mass mailing.
Specifications
==============
We do not generate the preview text anymore, instead we add
a new field to let the user choose want he want to put into
the preview. As the preview is added in the mail body, it
supports dynamic placeholders.
Rename "View in browser" into "View Online" because the text
will be displayed in the preview if the snippet is added at
the beginning of the email. And we want to make it shorter.
Remove the alt attribute of the image tag which are not part
of the "email content" in the mass mailing template.
So, we improve the email preview in the mail clients
(otherwise the mail client include the alt attribute into the
preview).
Task-2313872
closes odoo/odoo#55695
Related: odoo/upgrade#1584
Related: odoo/enterprise#12323
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
Purpose
=======
Provide a follow-up/overview of the Mailing 24 hours after its been sent.
Specifications
==============
Send an email to the responsible of the mailing 24 hours the last email
of the mass mailing.
During the link trackers creation, extract the button label if exists
(so we can display them in the statistics email).
Technical remarks
=================
The statistics email is sent to the responsible of each mailing in the
CRON of mass mailing.
Task-2227411
closes odoo/odoo#49836
Related: odoo/upgrade#1094
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
PURPOSE
Improve the Email Marketing tour and onboarding to create a "wow effect" when
users test the app.
SPECIFICATIONS
Create a tour for mass_mailing to let user visit Odoo Email Marketing through
a simple mailing creation flow.
This require the following functional changes
* by default, if user chooses to contact mailing lists and there is a single
mailing list available, add it as default value for chosen list;
* create a master mailing list data containing the admin user so that he can
easily follow the tour and test the mailing application;
LINKS
Task ID 2194876
Community PR odoo/odoo#48259
Upgrade PR odoo/upgrade#983
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
PURPOSE
Clarify the use case in which a specified email address is set as replies may
not be traceable. Make the %Click KPIs visible for Emails as well. Allow users
to report on the links that have (or not) been clicked from their
mailing.
SPECIFICATIONS
Add an info text for the "specified email address" option in the "reply to"
field. If target model does not accept incoming emails warn the user it is
likely to fail.
Number of emails/sms sent is now display as clickable text instead of stat
button and clicked stat button is now also visible in mass_mailing.
Task ID: 2202495
PR #48339
|
|
* = mass_mailing, web_editor, website_crm, website_event, website_form,
website_forum, website_hr_recruitment, website_mail_channel,
website_mass_mailing, website_sale, website_slides
When an outdated snippet's option are activated we display a warning
in the left panel that inform the user about the potential
malfunctions.
To do so the snippet's template key is added to the snippet as
data-snippet.
If a snippet is "t-call" inside another snippet, it will need to use
t-snippet-call instead of t-call to have the key on himself.
Those unique keys are used on snippet selection to retrieve the
snippet's version in the left panel and compare it with the currently
selected snippet's version. Versions are describe with data-vcss,
data-vjs and data-vxml. If a snippet's key is not in the left panel we
consider that snippet as outdated.
Added some tests to ensure that t-snippet and t-snippet-call really have
their template key as data-snippet
Adapted the views to the data-snippet changes adding
data-snippet="tmpl_key".
Part of: https://github.com/odoo/odoo/pull/44569
task-2189669
closes odoo/odoo#50254
X-original-commit: 28a6cd49b6e87b75c2e70771e241c41778bf9e87
Related: odoo/enterprise#10236
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
* Code cleanup
* Avoid a safe evaluation of the field value when loading those records.
closes odoo/odoo#44883
Related: odoo/enterprise#8283
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
|
|
This reverts commit ff1c35513aecef5fbc30f7c2f3834450e719714e.
closes odoo/odoo#41480
X-original-commit: 116057b26e71db4692280463669f3e80d813ddcc
Related: odoo/enterprise#7110
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
FontAwesome 5 introduced new names for some icons as described on
https://fontawesome.com/how-to-use/on-the-web/setup/upgrading-from-version-4#name-changes
This commit replaces the old names to the new ones.
closes odoo/odoo#35826
Taskid: 2050241
Related: odoo/enterprise#5180
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
In order to improve and clarify the mass-mailing (Email Marketing) module
several changes have been made
1 - Clarify the name of the application:
2 - Prevent the “Quick Add/Create” feature in the mailing kanban view
3 - Label and wording clarification in mailing_mailing form view :
4 - Clarify button names "Send now" ("put_in_queue")
5 - Mailing Form view layout
6 - Clarify the required field
7 - Clarify the readonly field
8 - Wording clarification if scheduling mail in the future
9 - Add a Placeholders tools page in the form view:
10 - Clarify the Campaigns view
11 - Clarify the Action Helpers
TASK-ID : 2046078
closes odoo/odoo#36124
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
Purpose of this commit is to help discovering the new mass SMS application
by adding some data. Some mass mailing data is also udpated to be a bit
more interesting / up to date.
LINKS
Task 1997464
PR #34424
Original SMS addition: Task 1922163 (4287481)
|
|
PURPOSE
This commit removes the mass_mailing.campaign model. Instead of having a fully
fledged model, we will simply inherit utm.campaign. We will also add relevant
statistics on utm campaign model in order to use it in various applications.
SPECIFICATIONS
This commit removes the mass_mailing.campaign model. Instead of having a fully
fledged model, we will simply inherit utm.campaign. This change implies that
mass_mailing.tag and mass_mailing.stage have to move to the utm model along
their associated views/data.
These changes were made so that campaigns could be used in the future
by social, mass_mailing and mass_sms and available in the same view
This commit also removes the source_id and the medium_id
fields on the campaign.
This commit also moves the unique_ab_testing field from the mass_mailing_campaign
to the mass_mailing model
Task ID: 2002029
PR: #34015
|
|
PURPOSE
Mass mailing is currently a bit messy. As SMS will be added as a way to notify
people in mass through SMS let us take this opportunity to somehow clean this
application: organization, light code cleaning, model renaming.
SPECIFICATIONS
Rename mail.mass_mailing model to mailing.mailing. Rationale :
* mailing is now a prefix for mass mailing models;
* mailing.mailing is easier to read / find / understand;
Note that mail.mass_mailing.campaign is not updated as it is likely to be
removed soon and replaced by simple utm.campaign model.
MIGRATION
mail.mass_mailing model -> mailing.mailing
mail_mass_mailing table -> mailing_mailing
LINKS
Task ID 2037906
Preparing task ID 1997464 (SMS addition in mass mailing)
PR #34938
|
|
PURPOSE
Mass mailing is currently a bit messy. As SMS will be added as a way to notify
people in mass through SMS let us take this opportunity to somehow clean this
application: organization, light code cleaning, model renaming.
SPECIFICATIONS
Rename mail.mass_mailing.stage and mail.mass_mailing.tag models to mailing.
stage and mailing.tag. Rationale :
* mailing is now a prefix for models in mass mailing;
* mailing.stage and mailing.tag are easier to read / find / understand;
MIGRATION
mail.mass_mailing.stage model -> mailing.stage
mail_mass_mailing_stage table -> mailing_stage
mail.mass_mailing.tag model -> mailing.tag
mail_mass_mailing_tag table -> tag
LINKS
Task ID 2037906
Preparing task ID 1997464 (SMS addition in mass mailing)
PR #34938
|
|
models
PURPOSE
Mass mailing is currently a bit messy. As SMS will be added as a way to notify
people in mass through SMS let us take this opportunity to somehow clean this
application: organization, light code cleaning, model renaming.
SPECIFICATIONS
Rename mail.mass_mailing.list and mail.mass_mailing.list to mailing.list
and mailing.list.merge. Rename mail.mass_mailing.contact to mailing.contact.
Rename mail.mailing_list.list_contact_rel to mailing.contact.subscription.
Rationale :
* those new names are easier to understand: mailing.list and mailing.contact
are less mail-related, especially taking into account that SMS will allow
to be less mail-oriented;
* those names are easier to read / find / understand;
* align wizard and sub-models naming with the main naming;
* have a mailing as first part of namespacing;
MIGRATION
mail.mass_mailing.list model -> mailing.list
mail.mass_mailing.list.merge model -> mailing.list.merge
mail.mass_mailing.contact model -> mailing.contact
mail.mass_mailing.list_contact_rel model -> mailing.contact.subscription
mail_mass_mailing_contact_list_rel table -> mailing_contact_list_rel (specific
case of a decorated m2m)
fields updated (no column change)
* mailing.list: subscription_contact_ids -> subscription_ids
LINKS
Task ID 2037906
Preparing task ID 1997464 (SMS addition in mass mailing)
PR #34938
|
|
PURPOSE
Mass mailing is currently a bit messy. As SMS will be added as a way to notify
people in mass through SMS let us take this opportunity to somehow clean this
application: organization, light code cleaning, model renaming.
SPECIFICATIONS
Rename mail.mail.statistics to mailing.trace and mail.statistics.report
to mail.trace.report. Rationale :
* mail.mail.statistics is linked to mail.mail model. Soon this model will
hold data related to SMS sending. It makes sense to be broader in the
naming;
* mailing.trace is more inlined with marketing.trace model that is the
marketing automation model using it in marketing automation (enterprise
application);
* mailing.trace is shorter to write;
* mail.statistics.report model should sense to be updated at the same
time;
MIGRATION
mail.mail.statistics model -> mailing.trace
mail_mail_statistics table -> mailing_trace
mail.statistics.report model -> mail.trace.report
fields updated (w column change)
* link.tracker.click: mail_stat_id -> mailing_trace_id
fields updated (no column change)
* mail.mail: statistics_ids -> mailing_trace_ids
* mail.mass_mailing: statistics_ids -> mailing_trace_ids
LINKS
Task ID 2037906
Preparing task ID 1997464 (SMS addition in mass mailing)
PR #34938
|
|
PURPOSE
Mass mailing is currently a bit messy. As SMS will be added as a way to notify
people in mass through SMS let us take this opportunity to somehow clean this
application: organization, light code cleaning, model renaming.
SPECIFICATIONS
Fix UTM management and propagation in mass mailing.
Right UTM definition in mass mailing
* mass mailing campaign -> utm.campaign
* mass mailing -> utm.source
* "email" -> utm.medium
Therefore
* remove campaign setting source and medium as each mailing is a source
and medium is "email";
* ensure each mailing is a separate source (otherwise name is shared);
* ensure UTM values propagate to link creation are those values and not
the one coming from the mass mailing campaign;
LINKS
Task ID 2037906
Preparing task ID 1997464 (SMS addition in mass mailing)
PR #34938
|
|
PURPOSE
Mass mailing is currently a bit messy. As SMS will be added as a way to notify
people in mass through SMS let us take this opportunity to somehow clean this
application: organization, light code cleaning, model renaming.
SPECIFICATIONS
Guidelines: re-organize model files and split them according to main
models. Also reorganize views.
Done in this commit
* split big python file by main models;
* split views according to python files;
* move statistics report to /report;
* merge some exploded view files (assets, snippets, application menus);
LINKS
Task ID 2037906
Preparing task ID 1997464 (SMS addition in mass mailing)
PR #34938
|
|
This commit removes the field `datas_fname` from `ir.attachment` as
it was unnecessary and most of the time the duplicate of `name` or
`url`.
Task #1909865
closes odoo/odoo#32976
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
|
|
closes odoo/odoo#31417
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
Following the new editor's merge at https://github.com/odoo/odoo/pull/29775,
the classes 'o_mail_wrapper' and 'o_mail_wrapper_td' were renamed to
'o_mailWrapper' and 'o_mailWrapper_td' because of what appears to be a
JS-variable-search-replace fail. Strange enough, the scss was not
impacted which allowed to see the bug in master.
closes odoo/odoo#30544
|
|
* Creating a new structure by transforming all the plugins in the
library using the odoo inheritance system. Plugins are easier to
implement with the AbstractPlugin to add Odoo behaviors.
* From now on, the methods of the library (in this case Summernote) can
no longer be called by other modules or files. Only the wysiwyg
widgets can access it, to simplify the updating process. The wysiwyg
object serves as an interface.
* Depending on the options the snippets will be loaded or not, the
editor will be in an iframe or not... all of this is transparent from
the outside.
* Regarding iframes, all controllers related to editing have been
removed: the new API no longer needs them. This speeds up loading,
eases testing and removes complexity for the same
features.
PUBLIC FEATURES
There are several public methods on the Wysiwyg class:
* Wysiwyg.prepare (WidgetParent): returns a deferred resolved when the
library (xml, lazy, assets...) is loaded.
* Wysiwyg.getRange (DOM): returns the range (selection in the dom)
* Wysiwyg.setRange (startNode, startOffset, endNode, endOffset): creates
a range (selection in the dom)
* Wysiwyg.setRangeFromNode (DOM, options) that creates a range from an
element (option available to select all, start or end)
A jQuery selector was added: :o_editable, which indicates whether the
current element is editable. That is, if it is contained in a tag with
the attribute 'contentEditable = "true"' or in a tag with the class
o_editable.
Several methods are also present:
* focusIn: makes a focus and places the cursor at the beginning of the
element
* focusInEnd: makes a focus and places the cursor at the end of the
element
* selectContent: makes a focus and selects the content
HTML FIELD
The HTML field can receive different options:
* style-inline: {boolean} transforms a class into an inline style when
saving and vice versa when reading.
* no-attachment: {boolean} prevents the use of attachments (in media
dialog)
* cssEdit: {xml_id} to use a template containing the css to loaded in
an iframe when editing
* cssReadonly: {xml_id} to use a template containing the css to load
into an iframe when viewing in readonly
* snippets: {xml_id} snippets template (can be used with or without
cssEdit)
* wrapper: {template} qweb static template (containing a tag:
id = "wrapper") that will include the content during editing (removed
on save)
MASS MAILING
A widget was created for mass mailing. There are now two fields:
body_html and body_arch.
body_arch contains the code with the class without conversion into
inline style, useful when editing and one with the inline style that is
visible in readonly mode and sent by email.
Advantage: no spreading errors, able to update css/theme, able to do
more changes when converting to inline style so that a maximum of mail
clients have an impeccable rendering.
Co-authored-by: Antoine Guenet <age@odoo.com>
|
|
Purpose of this task is to allow marketing people to differentiate the
mailing name (internal reference) from the subject used in the mailing
emails.
Mailing name is actually the UTM source name as mass mailing inherits
from it. Being able to edit it independently from the subject allows
to better categorize / filter mailings without sending technical terms
to customers. Marketing users could also change and tweak mailing subject
without disorganizing the pipe and changing the URM source name.
Demo data are updated accordingly to have both subject and mailing
names.
This commit is linked to task ID 1917602 and PR #29514.
|
|
In this commit we rewrite a bit add_click in order to remove the inlined sudo
and ease inheritance and parameter management inside the method.
Access through controllers is sudo-ed as the main API method is now done
with current user access rights.
This commit is linked to task ID 1904277 and PR #28242.
|
|
Purpose of this commit is to improve a bit demo data in mass mailing. This
includes notably
* having real links and UTMs generation for them calling manually
convert_link in demo data;
* having real statistics about clicks by calling add_click in demo data;
It will help having demo data feeling like a real mass mailing has been
sent.
This commit is linked to task ID 1907994 and PR #28533.
|
|
In order to understand more easily the impact of an opt out
or a blacklisted contact on the interface, blacklist and
opt-out demo data are added.
Tests updated to only test mails on contacts created inside
the test environement and not with demo data.
Task ID 1892998
Closes PR #27674
|
|
Purpose of this commit is to have some demo data that are coherent. Main things
done in this commit are
* clean the body of the first mass mailing given to the user in order to have
a content more inlined with odoo emails;
* update filter of the demo mass mailing to limit the results to something
predictable, aka contacts of ReadyMat;
* update statistics to be really linked to customer of the demo company by
setting model and res_id;
* create a statistics for each child of the company ReadyMat so that stat
buttons redirect correctly to a filetered view;
This commit is linked to task ID 1885121 and closes PR #27003.
|
|
- Remove useless onchange company id from website, now that we configure it
in the res config.
- Add the onchange company into the res_config_settings
- Remove left duplicate data from mass_mailing
- Add ALL social links into the res config
|
|
Fix Issue : With Mass Mailing Campaigns option activated only: if I go to Campaigns menu, I see 'Newsletter', I click on it and I am redirected to Mailings but don't see anything
because the filter 'My Mailings' is activated. In my opinion, there is an inconstancy somewhere. Is it only due to demo data?
Reason : Since System and Admin users refactoring, in one case, we see the data of system, because no filter, ine other case, we see only admin data because filter. As the mailing creator is system and not admin anymore.
|
|
Purpose
=======
- Apply the blacklist implementation to Improve mailing subscription to be more
compliant with the European GDPR law. Keep a list of people who does not want
to receive promotional emails (or mass mailing in general) anymore.
- Allows the recipient to update himself his mailing preferences
Specifications
===========
This commit is regrouping some main changes on mass mailing.
Apply Blacklist for following models through blacklist.mixin :
- crm.lead
- res.partner
- mail.mass_mailing.contact
- mail.channel.partner
- Opt_out per mailing list instead of per mailing contact.
- Replace opt_out by blacklist in crm.lead + res.partner models
- Added 'ignored' state for mass_mailing. Ignored = blacklisted, opted-out
Ignored email are not included into final statistics to avoid confusion.
- Unsubscribe(d) pages migrated from website_mass_mailing to mass_mailing module
as thoses pages should work without having the website module installed
Detailed implementation
===================
Mass-mailing :
- A blacklisted email is notified by the ban icon next to the email field.
(at the left of the email field for display purpose)
- Renaming the '_get_blacklist' method that was actually
searching opt_out list into 'get_opt_out_list'
- Opt out per mailing list : Add opt_out + related fields (for display and
ergonomy reasons) on the relational model
- Display relational model tree view instead of mass_mailing.contact tree
view when clicking on mass_mailing_list in kanban view
-> In order to be align between contact_nbr displayed in kanban tile and
the content of the tree view
-> mass_mailing contact is accesible via the user icon in this tree view
- Remove custom filters 'filter_contact_subscription' and
'filter_contact_unsubscription' as opt_out is not on mass_mailing.contact
model anymore
- Add 'is_public' to mailing list
The name of this mailing list can be seen (or not) by recipient in
the unsubscription page
If the mailing lists used in the mass mailing are not public,
the user in only informed that he has been unsubscribed.
If the mailing lists are public, the user is informed that he has been
unsubscribed from the mailing lists
and he has the choice to modify his subscription to all the public
mailing list he is or was subscribed to.
- Unsubscription Page :
- mass_mailing_contact :
Opt_out per mailing list, done by email and not by id, as multiple
contact can have the same email
The recipient can add/remove himself to/from the blacklist
The recipient can send a feedback about why he unsubscribed
- crm.lead + res.partner :
Once the recipient unsubscribe, he is automatically blacklisted
The recipient can 'Come back' and remove himself from the blacklist
if he changes his mind
- Show blacklist button parameter added in config :
The idea is to enable/disable the fact that the recipient can add
himself to the blacklist by showing or not the 'blacklist me' button
Only applies for mass_mailing.contact. The recipient, once
blacklisted, can always, no matter the value of this parameter,
'come back' and unblacklist himself
crm.lead + res.partner :
- Replace opt_out by blacklist in crm.lead + res.partner models.
As when a res.partner or crm.lead unsubcribe, we assume that the recipient
does not want to receive mass mailing anymore, at all, even if we adds him
to a mailing list afterwards. He is then blacklisted to avoid this.
With this behaviour, if a new lead is created with the same email address,
he won't be able to receive mail in mass_mode.
But he will still be able to receive '1 to 1' direct email.
Task ID 33224
Closes #25966
|
|
Purpose is to be able to have some basic demo data for crm and sales linked
to UTMs. Those will be used when introducing crm and sale bridge module with
mass mailing in order to display some documents linked by UTMs.
This commit is linked to task ID 1872198 and PR #26188.
|
|
Today, Odoo is really tricky to use without seeing the screen, it must be improved to be usable.
This PR forbid to use labels without a "for" attribute, add some title, rule and aria attributes in HTML. With that, Odoo will be fully usable with a screen reader.
* [IMP] Labels must have a for attribute. Improve accessibility.
* [IMP] Better error message when trying to read a missing cached value
* [FIX] Add some aria-label and title attributes for screen readers.
* [FIX] Template name is not included in the error message in case of SyntaxError in QWeb
* [FIX] Improve the Tour failed at step error message to be more explicit.
* [IMP] Add aria-labels
* [FIX] Add missing aria-label on failing test
* [IMP] aria-hidden means hidden. Fix all bad aria-hidden and hide aria-hidden for all.
* [IMP] Color names on kanban views and many2many tags
* [IMP] Add some checks on views for accessibility.
* [IMP] Add `alt` attribute on `img` tags.
* [IMP] Add aria-label and title on non-described icons
* [IMP] Add button role to widgets with btn class
* [IMP] Translate aria and formatted attributes.
* [IMP] Remove wrong aria-labelledby
* [IMP] Add menu role on dropdowns
* [IMP] Buttons must be focusable
* [IMP] Add aria attributes on progress bars
* [IMP] Improve accessibility of basic widgets
* [IMP] Change main layout to more semantic tags
* [IMP] Add menuitem role when missing
* [IMP] Remove wrong role='presentation'
* [IMP] Improve accessibility of tab panels
* [IMP] Add aria-invalid on invalid fields
* [IMP] Add aria-sort on ordered columns
* [IMP] Add role on alerts
* [IMP] Use dialog role, header, main and footer tags for modals
* [IMP] Add labels on o_status
* [IMP] Improve accessibility of kanban view with feeds and articles
* [IMP] Add alerts in case of new messages
* [IMP] Add widget, navigation or img role to aria-labelled items
|
|
This commit removes the strange selection box based on a magic flag and
some strange methods returning a string. Instead just allow to send mass
mailing on all models inheriting from mail.thread using the is mail
thread flag.
Various addons are updated to remove the _mail_mass_mailing class
attribute used to determine mass mailing capability.
We consider people could send a mass mailing on every model inheriting
from mail.thread. It makes no sense to limit it to a given set of addons.
|
|
Purpose
=======
- Settings are too complex: too long + too many options that shouldn't be suggested with checkboxes
e.g. twitter roller is now suggested as a new snippet to install from website editor
google maps, slides, forum, etc. should show up in the apps store
- When saving the page I expect to stay in the settings -> no redirection to homepage anymore!
Specification
=============
See task 33620
|
|
|
|
|
|
|
|
To avoid forcing the frequency or active.
Move to data file with noupdate enabled
Closes #17227
|
|
Purpose
=======
External links in the data sometimes open in the same tab, the users loses times as he has to come back (and looses the context).
Specification
=============
Any external links in data (planners, settings) should open in new tabs.
|
|
|
|
Handle bounces using bounce alias directly in mailgateway. Previously bounces
were used only in mass mailing to update campaign statistics. Now the
mailgateway tries to find data from standard delivery status emails. This
data is used to update state of emails sent to customers, to display it in
the Chatter. It is also used to increment the message_bounce counter on the
bounced partner and bounced record, if any and if the field exists.
Previous more generic code that detect bounces is kept. This code is more specific
to standard delivery failure notifications by parsing its content.
|
|
1. Splitted data/mass_mailing_data.xml to security/mass_mailing_security.xml for res_groups data.
2. Splitted views/mass_mailing_views to
- views/link_tracker_views.xml
- views/mass_mailing_stats_views.xml
- views/mass_mailing_template.xml
|
|
|
|
|
|
NB : Some tests have been modified.
One assert statement in orderpoint_calendar.yml has been modified,
but the change is legit has no python method has been modified at all
|
|
bridge to add subscribe snippet into website builder. Split website_links to have link_tracker to create short and trackable URLs, and website_links to have a website layout for link_tracker and add button to share page.
|
|
web_editor
|
|
color, font color and convert class to inline style in mail designer, changed snippet according to new format, added theme selector in mail_designer, added font-awesome support (convert in image) in mail snippets
|
|
1. The merge of the "email_template" module into the "mail" module.
2. The send action of the mass mailing has been moved from the frontend to a cron, because it was too slow to send over 10,000 mails (the user's browser was blocked for 15 - 20 minutes). Mass mailings have now their own process in the kanban view.
3. Mails sent from the mail form are sent immediatly instead of from the mail queue (for instance, when you go to sales > customers > list view > select 2 -3 customers > More > Partner Mass Mailing).
4. Users have now the choice from which mailing list they want to unsubscribe when they click on the unsubscribe link at the bottom of the mail.
5. Mass mailings inherit from their campaign UTMs and mass mailing campaigns are linked to an UTM campaign.
6. Many little improvements
|
|
This module tracks clicks in mass mailing mails and allow the generation of trackable links in a website interface.
Modules modifications
---------------------
Refractoring of the crm_tracking_* classes in a new module.
* Extract the crm_tracking_* from the crm module into a new module "utm"
* Remove the crm_mass_mailing bridge module
* New dependencies of mass_mailing and website_links to utm.
|
|
website.snippet: The methods described in javascript will be called automatically from the data-method_name = value on li snippets options. The methods are called in the order relative to children of xml (eg: <li data-method1=value1> ... <li data-method2=value2> ... </ li>, the method1 is then called method2). Methods receive two arguments: type (over, click, reset) and value. data-snippet-id-option becomes data-snippet-id. Several xml options can use the same data-snippet-id.
add a new gallery snippet
convert website_sale to the new option system
|
