View Issue Details

IDProjectCategoryView StatusLast Update
0020647mantisbtadministrationpublic2023-10-31 16:32
Reporteratrol Assigned Tovboctor  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version1.3.0-rc.2 
Target Version2.26.0Fixed in Version2.26.0 
Summary0020647: Not able to update existing user accounts if $g_email_ensure_unique == ON
Description

Fix of 0009093 enforces unique email addresses.

After upgrading installations where different accounts are using the same email address you get APPLICATION ERROR # 813 when trying to update an existing account (e.g. change access level) using mange_user_edit_page.php.

TagsNo tags attached.

Relationships

related to 0009093 closedvboctor Add a configuration option to enforce email uniqueness 
related to 0032464 closedvboctor Implement UserUpdateCommand 
has duplicate 0022458 closedatrol Unable to change users after upgrade 
related to 0032451 closeddregad Email uniqueness is not enforced on case-sensitive databases 
related to 0032787 closeddregad Facilitate identification of user accounts sharing the same email 

Activities

atrol

atrol

2016-02-29 16:50

developer   ~0052609

The easiest way to fix this might be to execute those statements just if email has been changed in form.

email_ensure_valid( $t_email );
email_ensure_not_disposable( $t_email );
user_ensure_email_unique( $t_email, $f_user_id );
vboctor

vboctor

2016-03-01 00:02

manager   ~0052612

It is unclear to me that this is an issue. If the administrator has elected to enforce uniqueness, then any new users or updates to existing users should require email uniqueness. Is there really a benefit in grand fathering such accounts? I don't see the benefits, we are just going to make the code more complex.

dregad

dregad

2016-03-01 02:57

developer   ~0052620

I agree that once a decision has been taken that emails must be unique, then we should strictly enforce it.

That being said, we should also provide tools for admins to help them resolve the cases where multiple accounts share a single e-mail.

atrol

atrol

2016-03-01 03:38

developer   ~0052623

Not sure you understand what's the use case.

I have 3 accounts on this bug tracker, all with the same email adress.
If you (vboctoradmin) as an administrator want to change any setting of one of my accounts, e.g. change my (atrol) access level from DEVELOPER to REPORTER you can't do it in UI as you will get APPLICATION ERROR # 813.

We check in account_update.php if( $f_email != user_get_email( $t_user_id ) )
I don't see a reason why we shouldn't check also in mange_user_edit_page.php

vboctor

vboctor

2016-03-04 22:00

manager   ~0052682

For the scenario where a user wants multiple accounts, they can use:

  • username@example.com
  • username+admin@example.com

We shouldn't be in the business of wondering whether a case of duplicate emails is valid or not. If it should be unique, then we should enforce it to be so.

If one of our pages is not consistent with this, we should fix it.

atrol

atrol

2016-03-05 17:09

developer   ~0052686

Seems I am not able to explain the problem in a good way.
One more try.

In 1.2.x it was possible to use the same email address for more than one user.
If you upgrade such an installation there might be users U1 and user U2 with email adress E1.

After upgrading to 1.3, $g_enforce_unique is set to ON but existing email adresses are not unique.

Now if user U1 goes to page "My Account", he is able to change settings, e.g. change his real name.
He gets no error message.
However an administrator is not able to change the real name of user U1 using manage_user_edit_page.php page.
He gets "APPLICATION ERROR # 813 That email is already being used. Please go back and select another one."

vboctor

vboctor

2016-03-05 18:24

manager   ~0052687

I think both cases should fail, forcing updating of the email address to be unique.

atrol

atrol

2016-03-28 07:31

developer   ~0052887

Last edited: 2017-03-05 07:44

I think both cases should fail, forcing updating of the email address to be unique.

The user has a chance to change the address to another address he owns (might be a problem in enterprise environments).
But what can the admin do in this case? He does not know any other address of the user.
So I still think that none of the cases should fail.

$g_email_ensure_unique = ON; is good for new installations as the default in config_defaults_inc.php but it's questionable for update installations.

vboctor

vboctor

2016-04-01 23:17

manager   ~0052898

@atrol, the administrator can set the email address to a blank one and defer to the user to fix it. That is assuming that there is a good way out, but that seems to be an assumption we are making here, since we assume the user can fix it.

atrol

atrol

2017-03-05 08:05

developer   ~0055905

The main problem is, that $g_email_ensure_unique has been introduced with default ON instead of OFF.
This can't be changed, and we have to look for a good way to deal with it.

I still see no reason why a user itself is able to change settings (e.g. change real name using account_page.php) without getting error, whereas an administrator is not able to do the same using manage_user_edit_page.php.

@vboctor, after getting real life issue 0022458 you might consider that 0020647:0052609 is an acceptable approach for it.

fishgirl

fishgirl

2019-10-21 03:03

reporter   ~0063011

We have the ussue related to this topic (MantisBT version 2.21.1; Schema version 209; php version 7.3.1; database version: 8.0.16.):

User with 4 different accounts (as he has more topics) all assigned to the same email, have to become new access level. I as an admin have tried to change his access level and received the error #813 message.

Referring to suggestions above: It makes no sense to delete the email address from another accounts and then force the user to add them again because its double effort.

And of course in enterprise each of us only owns one email address.

Please advice.

atrol

atrol

2023-04-26 14:11

developer   ~0067710

Please advice.

Add the following line to config_inc.php
$g_email_ensure_unique = OFF;

dregad

dregad

2023-07-26 05:30

developer   ~0067907

This problem was actually fixed by the introduction of the UserUpdateCommand (see 0032464).

atrol

atrol

2023-07-26 14:10

developer   ~0067908

Nice side effect, I guess not wanted, but finally the right behaviour ;-)

dregad

dregad

2023-07-26 18:02

developer   ~0067909

Agreed ;-)

vboctor

vboctor

2023-07-27 02:41

manager   ~0067910

I guess it is meant to be :)