View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0020647 | mantisbt | administration | public | 2016-02-29 16:44 | 2023-10-31 16:32 |
Reporter | atrol | Assigned To | vboctor | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 1.3.0-rc.2 | ||||
Target Version | 2.26.0 | Fixed in Version | 2.26.0 | ||
Summary | 0020647: 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. | ||||
Tags | No tags attached. | ||||
related to | 0009093 | closed | vboctor | Add a configuration option to enforce email uniqueness |
related to | 0032464 | closed | vboctor | Implement UserUpdateCommand |
has duplicate | 0022458 | closed | atrol | Unable to change users after upgrade |
related to | 0032451 | closed | dregad | Email uniqueness is not enforced on case-sensitive databases |
related to | 0032787 | closed | dregad | Facilitate identification of user accounts sharing the same email |
The easiest way to fix this might be to execute those statements just if email has been changed in form. |
|
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. |
|
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. |
|
Not sure you understand what's the use case. I have 3 accounts on this bug tracker, all with the same email adress. We check in account_update.php if( $f_email != user_get_email( $t_user_id ) ) |
|
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. |
|
Seems I am not able to explain the problem in a good way. In 1.2.x it was possible to use the same email address for more than one user. 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. |
|
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). $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. |
|
@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. |
|
The main problem is, that $g_email_ensure_unique has been introduced with default ON instead of OFF. 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. |
|
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. |
|
Add the following line to config_inc.php |
|
This problem was actually fixed by the introduction of the UserUpdateCommand (see 0032464). |
|
Nice side effect, I guess not wanted, but finally the right behaviour ;-) |
|
Agreed ;-) |
|
I guess it is meant to be :) |
|