View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0015712||mantisbt||other||public||2013-04-04 03:56||2022-06-11 10:54|
|Summary||0015712: RealNames not displayed correctly while using LDAP auth and 'use_ldap_realname' options|
When using LDAP auth (I am using AD server) and setting the options 'use_ldap_realname' to true, function user_get_name() in core/user_api.php always returns the local real name and not the one coming from the LDAP.
|Tags||No tags attached.|
Fix suggested in pull request.
The reason it's done this way (i.e. pulling the info from DB), is that the user table currently acts as a "cache" for LDAP information, which is stored/updated after each successful login by the user .
I guess the idea behind this was to improve performance by reducing the amount of LDAP traffic, as loading a single MantisBT page can trigger hundreds of LDAP queries.
I'll grant you that this is not ideal as there can be a discrepancy between the master data (LDAP directory) and the Mantis DB, especially for users who don't login frequently.
However I don't think your fix should be applied as-is because it
In my case the users almost do not login to the system, as we are using EmailReporting with it...
So, In most of the cases the local records are not in sync with the directory.
Maybe it can be useful to update user's details from LDAP on issue submission, thus if one submits an issue, his details will be synced.
That could be an idea actually. The only catch is to find the most relevant/appropriate event to trigger the update of Mantis user table with LDAP info.
For implementation, 1. can probably be hooked into bug_api, and 2. into history_api. These would effectively improve the situation (i.e. reduce the risk of displaying outdated user info), but I don't think any one of them is perfect.
An alternative could be to build a back-end script that can be scheduled to run, e.g. on a daily basis, to mass-update the user profiles's info from LDAP.
Even if we do the suggested hooks, there are still users on issues that have already been submitted that may become stale. This is in addition to the synchronous performance degradation due to these extra LDAP updates that typically yield no added value.
Hence, I would prefer the idea of cronjob that goes through all users into MantisBT and refreshes their info from LDAP.
Why doesn't EmailReporting plugin also refresh from LDAP similar to login workflow?