This issue introduces a new system setting. As such it requires a version increase to get that setting picked up. The version I've got in version.php may not be the version the integrators ultimately use. It just needs to be a version above whatever you currently have in your version.php to get an upgrade to run.

After the upgrade has run to go My profile settings > Messaging and check that the email address box is available. Its towards the bottom of the page.

As an admin search for the new setting in the Settings block. It is messagingallowemailoverride. Untick it and save.

Go back to your messaging settings and check that the email address area is gone.

Retick the settings and save. Reload your messaging settings and check that it has returned.

This issue introduces a new system setting. As such it requires a version increase to get that setting picked up. The version I've got in version.php may not be the version the integrators ultimately use. It just needs to be a version above whatever you currently have in your version.php to get an upgrade to run.
After the upgrade has run to go My profile settings > Messaging and check that the email address box is available. Its towards the bottom of the page.
As an admin search for the new setting in the Settings block. It is messagingallowemailoverride. Untick it and save.
Go back to your messaging settings and check that the email address area is gone.
Retick the settings and save. Reload your messaging settings and check that it has returned.

Description

We had a lot of confusion due to the fact that moodle sends forumposts and messages to different eMail addresses.
Reason is the possibility to define eMail address in two different places

user profile

settings of messages

I don't understand the reason for this so I assume this is a bug

It would be very nice if:
1) there would be only one place to define the EMail address
or
2) there would be a flag in the rights management where could be specified if these addresses should be synchronized or not.

Activity

There are indeed currently two places you can specify your email address. The primary one is your profile. You can optionally add a second email address on the messaging settings screen. By default this is empty and your primary email address is used. The ability to override it in your messaging settings exists for people who have multiple email addresses and want their messages delivered to one of their non-primary email addresses.

Currently the text around the email box in the messaging settings says the following
Send email notifications to: [ the text box ](Default: person@example.com)

I could change this to say something like this to make the relationship more obvious.
Send email notifications to: [ the text box ](If left empty notifications will be sent to person@example.com)

I could also do something like add a site settings that allows/disallows users overriding the email address in their profile. If set we could simply not display the email section on the messaging preferences page.

Andrew Davis
added a comment - 03/Oct/11 2:02 PM There are indeed currently two places you can specify your email address. The primary one is your profile. You can optionally add a second email address on the messaging settings screen. By default this is empty and your primary email address is used. The ability to override it in your messaging settings exists for people who have multiple email addresses and want their messages delivered to one of their non-primary email addresses.
Currently the text around the email box in the messaging settings says the following
Send email notifications to: [ the text box ](Default: person@example.com)
I could change this to say something like this to make the relationship more obvious.
Send email notifications to: [ the text box ](If left empty notifications will be sent to person@example.com)
I could also do something like add a site settings that allows/disallows users overriding the email address in their profile. If set we could simply not display the email section on the messaging preferences page.

Only one question:
Do you think there is any chance to move the definition of an alternative email-address for the messages to the user profile? It took us a long time to understand why moodle sends mail to an email-address different to the one defined in the profile. In my point of view the problem is not the existence of the second address (indeed I think its a great feature); the problem was to find out that moodle can use two different addresses.

Klaus Müller
added a comment - 04/Oct/11 2:24 PM Dear Andrew,
thank you very much for your kind explanation.
A permission which allows the field to be used would be great.
Only one question:
Do you think there is any chance to move the definition of an alternative email-address for the messages to the user profile? It took us a long time to understand why moodle sends mail to an email-address different to the one defined in the profile . In my point of view the problem is not the existence of the second address (indeed I think its a great feature); the problem was to find out that moodle can use two different addresses.
Best regards
Klaus

As a university who wants all mail delivered to the users university account, we would definitely like to see the site setting that allows/disallows users overriding the email address in their Messaging settings.

Monash University VLE team
added a comment - 10/Oct/11 12:07 PM As a university who wants all mail delivered to the users university account, we would definitely like to see the site setting that allows/disallows users overriding the email address in their Messaging settings.

I wasted a bunch of time fiddling around with capabilities before realizing that wasn't going to work. Messaging is outside of any course so course related capabilities like "student" don't really make sense. duh.

Andrew Davis
added a comment - 08/Dec/11 11:55 AM I've added a master branch version and testing instructions.
I wasted a bunch of time fiddling around with capabilities before realizing that wasn't going to work. Messaging is outside of any course so course related capabilities like "student" don't really make sense. duh.
So now I've introduced a new system setting.

Rajesh Taneja
added a comment - 09/Dec/11 1:17 PM Hello Andrew,
you might want to consider using empty for
if (!$CFG->messagingallowemailoverride) {
to avoid any warnings during upgrade.
Rest looks great

Ankit Agarwal
added a comment - 09/Dec/11 1:40 PM Hi guys,
Just wondering what exactly will happen when :-
Email override is allowed
A user overrides his email id
Admin Disables Email override
will the user continue to get emails sent to the over-ridden email or default email will be used?

Andrew Davis
added a comment - 09/Dec/11 6:36 PM - edited Adding various branches. Assuming there are no more issues Rajesh feel free to hit the submit for integration button after you've had another look.

The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.

Eloy Lafuente (stronk7)
added a comment - 23/Dec/11 10:47 AM The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.
TIA and ciao

Eloy Lafuente (stronk7)
added a comment - 04/Jan/12 11:32 AM The integration of this issue has been delayed to next week because the integration period is over (Monday, Tuesday) and testing must happen on Wednesday.
This change to a more rigid timeframe on each integration/testing cycle aims to produce a better and clear separation and organization of tasks for everybody.
This is a bulk-automated message, so if you want to blame somebody/thing/where, don't do it here (use git instead) :-D :-P
Apologizes for the inconvenient, this will be integrated next week. Thanks for your collaboration & ciao

The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.

Eloy Lafuente (stronk7)
added a comment - 06/Jan/12 12:03 AM The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.
TIA and ciao

Eloy Lafuente (stronk7)
added a comment - 09/Jan/12 9:24 AM I'm moving out from these as integrator for now... will retake them only if I'm able to review properly all the "enrol" pending ones that have max priority for this week.
So any other integrator, feel free to pick them if pending... TIA and ciao

Getting several conflicts when trying to merge this on master.
Can you please rebase your branches and put this back up for integration review when you get a chance.
As a heads up in admin/settings/*.php use `new lang_string` rather than `get_string` from now on.

Sam Hemelryk
added a comment - 09/Jan/12 12:36 PM Hi Andrew,
Getting several conflicts when trying to merge this on master.
Can you please rebase your branches and put this back up for integration review when you get a chance.
As a heads up in admin/settings/*.php use `new lang_string` rather than `get_string` from now on.
Cheers
Sam

The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.

Eloy Lafuente (stronk7)
added a comment - 27/Jan/12 11:11 AM The main moodle.git repository has just been updated with latest weekly modifications. You may wish to rebase your PULL branches to simplify history and avoid any possible merge conflicts. This would also make integrator's life easier next week.
TIA and ciao

Eloy Lafuente (stronk7)
added a comment - 01/Feb/12 8:44 AM Some notes:
1) While we should keep current behavior in existing sites, wouldn't be better, for new installations, to set the default of the new setting to no, so admins must opt-in to allow the alternate emails?
2) As new feature/improvement, do we want this really backported to 21 and 22 ?
3) This new setting requires docs, it's one new option that needs to be documented, not sure where, but needs that (so I'm adding the docs_required label).
Otherwise the patch looks ok. Just halting till answer for 1 & 2 arrives, TIA and ciao

1) Youre right. Ive reversed the default so the ability for users to override their email address is off by default. Ive also added some upgrade code that turns that setting on so that upgrading sites will have the setting turned on ensuring there is no change in behaviour for them.

2) Probably not. I wasnt actually thinking of this as a new feature but I guess it is.

There is 1 new commit in my master branch. The 2.2 and 2.1 branches are unchanged as theyre probably not going in anyway

Andrew Davis
added a comment - 01/Feb/12 10:33 AM 1) Youre right. Ive reversed the default so the ability for users to override their email address is off by default. Ive also added some upgrade code that turns that setting on so that upgrading sites will have the setting turned on ensuring there is no change in behaviour for them.
2) Probably not. I wasnt actually thinking of this as a new feature but I guess it is.
There is 1 new commit in my master branch. The 2.2 and 2.1 branches are unchanged as theyre probably not going in anyway

I'm going to integrate and test this... although I'm going to create one new issue about to clean the subsystems (advanced features) admin page. It should contain exclusively on/off switchers for entire subsystems and not individual settings like the introduced here (and another 2-3 more) that should belong to another (own) settings page (messaging, appearance...).

Eloy Lafuente (stronk7)
added a comment - 01/Feb/12 7:49 PM I'm going to integrate and test this... although I'm going to create one new issue about to clean the subsystems (advanced features) admin page. It should contain exclusively on/off switchers for entire subsystems and not individual settings like the introduced here (and another 2-3 more) that should belong to another (own) settings page (messaging, appearance...).
Ciao