399071 - Remove the 'allowemailchange' parameter

Status: RESOLVED WONTFIX

(Bugzilla :: Administration, task)

Description

[Frédéric Buclin]

Per our discussions at our last 2 Bugzilla meetings, this param should go away. It should always be set to 1.

Comment 1

[Roman Pszonka]

I disagree. Companies usually don't want their employers to change company email address to some external one. And they may also have some group rules based on domain names. At least that was the default setting on bugzilla installations I was administering.

Comment 2

[Max Kanat-Alexander]

  That could be handled with emailregexp, right?

  It also would be a pretty simple customization.

Comment 3

[Antonis Christofides]

Is the default "on"? I administer a Bugzilla where it's set to off. It actually gets usernames, passwords, and email addresses from LDAP. If using LDAP automatically disallows email change, then I don't care about the removal of the parameter.

Comment 4

[Dimitri]

Our bugzilla set this flag to off too. As we use Apache authentication the users aren't allowed to modify in any way their email. We disable the account creation too for that purpose.

Comment 5

[Frédéric Buclin]

(In reply to comment #3)
> gets usernames, passwords, and email addresses from LDAP. If using LDAP
> automatically disallows email change, then I don't care about the removal of
> the parameter.

Correct, LDAP doesn't let you change your email, independently of the state of the allowemailchange parameter. So no problem here.


(In reply to comment #4)
> Our bugzilla set this flag to off too. As we use Apache authentication the
> users aren't allowed to modify in any way their email. We disable the account
> creation too for that purpose.

Here too, using the ENV auth method (Apache auth) automatically disables the ability to change your email address, independently of the allowemailchange parameter.


Nobody mentioned it yet, but just in case: those using the new Authen::RADIUS auth method implemented in Bugzilla 3.1.1 also cannot change their email address.

Comment 6

[Davy Courvoisier]

I would also disagree to remove this parameter. I've set this parameter to off.

This would potentially allow users to become someone else. Also allowing a user to change his loginname seems unsecure to me in a controlled environment.

If an administrator has to disable a user AB([e-mail]) and that user changed his name/email to XY([e-mail]), it would be impossible to trace him. That user will stay in the system with same access as before which can be quite annoying if bugzilla is used with strict controlled access.

It is not possible to use emailregexp for this. Customization is an option, but that would be like having the same code as of now(ideally). I don't see why this would simplify the administration of bugzilla which is the purpose of the removing if I well understood.

IMOO, this parameter is useful as it allows to use bugzilla in the open world, where one can change login name as often as needed. When this parameter is turned off, bugzilla can be easily deployed in closed world.

Comment 7

[Max Kanat-Alexander]

  Hrm, I think these sound like good enough use cases to keep this parameter. What do you think, LpSolit?

Comment 8

[Max Kanat-Alexander]

(In reply to comment #7)
>   Hrm, I think these sound like good enough use cases to keep this parameter.
> What do you think, LpSolit?

  But I think we should default it to 1, not to 0.

Comment 9

[Frédéric Buclin]

(In reply to comment #7)
>   Hrm, I think these sound like good enough use cases to keep this parameter.
> What do you think, LpSolit?

I'm not completely convinced by comment 6, even if I understand his point of view. One way to track such email changes would be to store them in the DB, in the same way we store permission changes. A checkbox "include old login names" in editusers.cgi would permit you to easily find user AB([e-mail]) even if he changed his email address meanwhile.

On the other hand, this parameter is by far not the one which causes the most complexity in our code. We may decide to keep it based on further discussion and feedback.

Comment 10

[Frédéric Buclin]

OK, let's keep this parameter (at least for now).