View Issue Details

IDProjectCategoryView StatusLast Update
0010493mantisbtcode cleanuppublic2018-03-04 00:36
Reporterdhx Assigned Tovboctor  
Status closedResolutionfixed 
Product Versiongit trunk 
Target Version2.12.0Fixed in Version2.12.0 
Summary0010493: Non-existent duplicate_realname column is updated by various functions in user_api.php

It seems that all references within user_api.php to a column "duplicate_realname" in mantis_user_table are invalid. This column does not appear to exist in the Mantis database schema (has it ever existed?).

user_set_field will fail when it tries to update the non-existent column in mantis_user_table with the following error:


Database query failed. Error received from database was #1054: Unknown column 'duplicate_realname' in 'field list' for the query: UPDATE mantis_user_table
SET duplicate_realname=?
WHERE id=?.

TagsNo tags attached.


related to 0004226 closedvboctor Provide a way to disambiguate duplicate realnames 




2009-05-18 02:54

reporter   ~0021826

To reproduce, simply attempt to set the real name for two different accounts to the same string. Bingo, you have an error!



2009-05-18 02:58

reporter   ~0021827

Last edited: 2009-05-18 03:10

View 3 revisions

one mark.. Create one user with RealName: Test Name, second with Test Real.
$g_differentiate_duplicates = ON;



2009-05-18 03:49

reporter   ~0021829

See admin/ugprades/



2009-05-18 04:16

reporter   ~0021830

Actually you're right, I accidentally had this setting to ON (which the default config strongly warns against). My bad doh

I'm still confused why a function named "user_is_realname_unique" would go about updating the database. The function name implies it is performing a read-only operation.

The documentation of $g_differentiate_duplicates is lacking... to be polite. It looks like this feature needs some major work to bring it up to the standards of the rest of Mantis... or it needs to be dropped completely (it doesn't sound like anyone can use it anyway at the moment).



2009-05-19 21:14

reporter   ~0021845

Part of the implementation was lost early in 1.0.0. I plan on adding it back in an incremental fashion.



2018-01-30 02:18

manager   ~0058669

Code removed in PR

Issue History

Date Modified Username Field Change
2009-05-18 02:51 dhx New Issue
2009-05-18 02:54 dhx Note Added: 0021826
2009-05-18 02:58 Kirill Note Added: 0021827
2009-05-18 03:01 Kirill Note Edited: 0021827 View Revisions
2009-05-18 03:10 Kirill Note Edited: 0021827 View Revisions
2009-05-18 03:49 grangeway Note Added: 0021829
2009-05-18 04:16 dhx Note Added: 0021830
2009-05-19 21:13 thraxisp Relationship added related to 0004226
2009-05-19 21:14 thraxisp Note Added: 0021845
2018-01-30 02:18 vboctor Assigned To => vboctor
2018-01-30 02:18 vboctor Status new => assigned
2018-01-30 02:18 vboctor Target Version => 2.11.0
2018-01-30 02:18 vboctor Note Added: 0058669
2018-02-06 21:22 vboctor Target Version 2.11.0 => 2.12.0
2018-02-07 02:51 vboctor Status assigned => resolved
2018-02-07 02:51 vboctor Resolution open => fixed
2018-02-07 02:51 vboctor Fixed in Version => 2.12.0
2018-02-07 02:58 vboctor Category administration => code cleanup
2018-03-04 00:36 vboctor Status resolved => closed