View Issue Details

IDProjectCategoryView StatusLast Update
0020647mantisbtadministrationpublic2019-10-21 03:03
Reporteratrol Assigned Tovboctor  
Status assignedResolutionopen 
Product Version1.3.0-rc.2 
Summary0020647: Not able to update existing user accounts if $g_email_ensure_unique == ON

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.


related to 0009093 closedvboctor Add a configuration option to enforce email uniqueness 
has duplicate 0022458 closedatrol Unable to change users after upgrade 




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 );


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.



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.



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



2016-03-04 22:00

manager   ~0052682

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


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.



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."



2016-03-05 18:24

manager   ~0052687

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



2016-03-28 07:31

developer   ~0052887

Last edited: 2017-03-05 07:44

View 2 revisions

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.



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.



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.



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.

Issue History

Date Modified Username Field Change
2016-02-29 16:44 atrol New Issue
2016-02-29 16:44 atrol Relationship added related to 0009093
2016-02-29 16:50 atrol Note Added: 0052609
2016-03-01 00:01 vboctor Assigned To => vboctor
2016-03-01 00:01 vboctor Status new => assigned
2016-03-01 00:02 vboctor Note Added: 0052612
2016-03-01 02:57 dregad Note Added: 0052620
2016-03-01 03:38 atrol Note Added: 0052623
2016-03-04 22:00 vboctor Note Added: 0052682
2016-03-05 17:09 atrol Note Added: 0052686
2016-03-05 18:24 vboctor Note Added: 0052687
2016-03-28 07:31 atrol Note Added: 0052887
2016-04-01 23:17 vboctor Note Added: 0052898
2017-03-03 10:44 atrol Relationship added has duplicate 0022458
2017-03-05 07:44 atrol Note Edited: 0052887 View Revisions
2017-03-05 08:05 atrol Note Added: 0055905
2019-10-21 03:03 fishgirl Note Added: 0063011