Redmine

An organization's policy requires users not be able to change their Redmine e-mail address.

(Extra background/scenario info: User registration, Project and Role assignment is done by a script which also uses the autologin cookie feature of Redmine: User clicks a link from an Intranet page, that script handles above user creation tasks (if user doesn't exist yet) and logs him/her into Redmine, without ever requiring them to enter a password for Redmine. Logout is done by having Apache redirect the "/logout" script to some different URL on the Intranet which also clears the Redmine session cookies.) So far, we are very happy and thankful to all Redmine Contributors.

While it is possible to change the number of extra e-mail addresses from 5 (default) to 0 [Administration > Settings > Users > Maxmimum number of additional email addresses], it still means that (under /my/account) any user logged in is able to change their e-mail address, unless the e-mail address is already taken by someone else in the system.

Having an Administration setting to "lock" only the Email address of an account would be great. It could help enforce policy of only using the organization's e-mail addresses.

From debug production.log, when a user updates his Email:

EmailAddress Update (0.2ms) UPDATE `email_addresses` SET `address` = '[redacted]', `updated_on` = '2020-03-29 18:55:59' WHERE `email_addresses`.`id` = 2

Hacking I tried:

• As a Ruby novice, I really am having a rough time finding my way through the code. Thanks to MVC, I don't believe it's as easy as just commenting out a line of code responsible for triggering the above SQL? Any pointer would be greatly appreciated.
• Maybe app/controllers/email_addresses_controller.rb would be a place to start, but I'm not sure.

Feature request:

• Add a Checkbox under Administration > Settings > Users: Allow users to change their email addresses, checked by default

"Workarounds":

• Apache Rewrite Rule to block access to /my/account altogether. Easy to implement, radical and effective, but not very friendly, as some useful Preferences (Time zone, UI Language) will be unavailable to users.
• Cronjob to replay any changed e-mail addresses to the MySQL database. Doesn't feel right.
• MySQL trigger to roll back any UPDATE statement to the `email_addresses` table. Hackish but better than cron; will likely break once a heavier DB Migrate script runs after updating Redmine.