Purpose of this commit is to allow mass mailing users to select an outgoing
mail sever when performing mass mailing. It includes
* add a field in mass_mailing to select specific outgoing mail server;
it is put in debug mode because it sounds people would not understand
what is its purpose;
* add an option in settings to set a default outgoing mail server;
* give read access to ir.mail_server to mass_mailing users;
This commit is related to task ID 31737.
Since revision
731356a155
and the fact `mail.mass_mailing.campaign` inherits (with s)
from `utm.source`, and the name of the mass mailing
is took from this `utm.source` linked to the mass mailing,
a mass mailing user requires the write access on the model `utm.source`
to be able to change the subject of a mass mailing.
As a side node, I notice there is no group applied on the
base `access_utm_source` access rule of the module UTM,
meaning a portal user can create `utm.source`.
I am not sure if this is wanted or not.
opw-710525
This group was defined in the mass_mailing module but is only working when
you install website_mass_mailing. What this group does is allowing to insert
a newsletter snippet in the page, thus it has nothing to do in the mass_mailing
module which doesn't depend on website. Also, the snippet itself was already
defined in website_mass_mailing.
Moved all the things to website_mass_mailing.
Add a link in the general settings to access easily the default_user form view in order to modify the default access rights
The default_user manager rights declarations in all the applications have been move in a noupdate="1" definition to avoid the manual configuration overwrittings
Coming from a bug in web_settings_dashboard. Invited user didn't have any rights
when created from the dashboard, which was leading to an error.
This bug leaded to a new discussion. Better to have basic employee having user
rights for all main applications. For bigger entreprises there is an admin that
will carefully remove extra rights, if necessary. The target is small businesses,
it makes sense that every way to create a user gives the same result.
In conclusion, each new user has a full access to the applications by default
How is it implemented ?
We added an inactive default user which original access right to the groups
'base.group_user' and 'base.group_partner_manager' in base. Each
application will extend the default user's access right by adding the maximal
access right for this application.
On user creation, we will use by default the 'group_id' field from the default
user. We will in the same time remove the ugly 'default_groups_ref' key which
was passed sometimes in the context for some fields in some views, and sometimes
nothing.
So, the user can modify the access rights for the default user, but he should be
aware that removing project user access rights for a default user will prevent
a *created on the fly in a task* user will not be able to access the task.
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
Improved mass mailing form view, that is used as a central point to create new
mailings.
Added concept of contact list (based on partner, or leads (to add)), as well as
contact (a list of name / email to import). Mailings are done un contact list
to simplify the way it works.
Added a kanban view of templates, with a flag to filter only mass mailing templates
(to avoid havign to deal with acknoledgments).
Using campaigns is now an option (a group), mailings can be done without having to
deal with campaigns.
Mailings and campaigns now have a status, used to display their kanban view.
bzr revid: tde@openerp.com-20140314165113-g4gvvifrhr2nfu15
Mail statistics are now stored onto a separated object (mail.mail.statistics), allowing to
handle emails separately from statistics (among other removing mail.mail entries while keeping
statistics).
Everything linnked to opened/replied/bounce is not managed by mass_mailing, removed added code
in mail module.
bzr revid: tde@openerp.com-20130913115408-322cyjipdg680as6
simple mass mailing campaign model, linked to emails, compute some statistics
mail.compose.message updated to the mass mailing campaigns in mass mail mode
bzr revid: tde@openerp.com-20130807130334-nwd34fgsz4lc6lt1
Yannick Tivisse