Considering that Mantis updates the DB with LDAP information after successful login, from my point of view the current behavior is fine, I don't see the purpose of querying the LDAP all the time.

a) does it really update the /entire/ DB ?
as I said above, in my experiments only the logged-in user was updated. My mantis instances have to deal with several hundreds to thousands of users

b) i (and my users) run my Linux-box about one month w/o reboot (then i issue a forced reboot to all machines). this is the timespan that my mantis-login is open. so update once per login is not sufficent.

You are correct, the DB info is updated once, at login-time, for the user who is connecting only.

I guess it really depends on how static the LDAP data is. Meaning, how frequently do users' names and e-mails get updated. For me, this data changes very rarely, maybe in your case it's different.

As a workaround, you could maybe try to reduce the cookie's validity (g_cookie_time_length) to force a more frequent refresh ?

If I understand your need correctly, is that email and name should systematically be pulled from LDAP, without using a cache (i.e. the Mantis DB).

An hourly update would be sufficient.

Regarding g_cookie_time_length I assume that I have to re-authenticate as soon as this cookie expires, don't I? -- This would not be acceptable.

Still have a hard time to understand why a realname should be updated every hour? My name stays the same for as long as I live.
So if this all is so critical, why not write a small script that as often as you want, runs through the user table and updates it with info from AD?

Attached a small script that retrieves all users from AD (have fun)

I'm not talking of my personal account, but of the thousands of users that are enlisted in our general users database (and where I've attached mantis to via LDAP/AD).
My estimates are that >10 accounts are being added / modified per day.

In case you want to see their AD names in mantis all the way, suggest you use the provided script to update the mantis_user_table on a regular base.

So the requirement is that all users in your LDAP should be registered in Mantis, with up-to-date name/e-mail, right ? In that case, I think the script solution mentioned by CAS, to add/update account information in the Mantis DB, is really the best option for you.

The alternative would be to make the lookup of this information completely dynamic, i.e. read from LDAP everytime name/email is needed (and to never use the DB, or to build a cache with a configurable expiration). In terms of efficiency, this does not sound too good as it would cause a very large volume of LDAP traffic.

The script allows both ways, one can control Mantis user table from AD (Adding/Updating) or simply update Mantis with correct values.
This however does not resolve the issue that Mantis apparently is not consistens using "use_ldap_realname".
Constantly consulting LDAP may have perfomance issues so a better option could be to introduce a field LDAP_Realname in the usertable which then could be updated upon login. This still requires mantis to work consistently according the settings

from the discussion i conclude i have two requirements

a) major: automatical repeated update of the entire mantis users db against ldap, based on parameterised cookie expiry (I cannot use cron)

b) minor: really constistent use of "real name" in mantis

b) is a true Mantis issue whereas for a) you have a challenge.
How often do you need updates?
What is the issue with Cron?

really constistent use of "real name" in mantis

I think it is consistent today... Always pulling the information from DB (and having DB refreshed from LDAP at each user's login). If I'm mistaken, can you please point out precisely what you think is not consistent ?

in reply to 0011546:0027300:
ad a)
a1) approx 1 per hour (rather less frequent than more frequent)
a2) i don't have cron access on web server machines. why not use a cookie similar to administration login expiry?

in reply to 0011546:0027303:
cas, can you point out your note 0011546:0027297 regarding consistent use of "use_ldap_realname" ?

Consistent use, see issue 11755.

As for why not use cookie, then it becomes an issue of mantis to update the entire user database. In my view this is not a mantis requirement.
As for cron, there must be someone in your company that can access cron on the webserver or are you using services from an external provider?

cron simply is not admissible in the way we operate our web services

... in my case, the real name update does not work, anyway.

But I have following idea regarding the real name update issue:
With the aim to have minimum load on the AD/LDAP server the following is sufficient:
a) query real name from AD and store into the mantis DB when a new user is signed up
b) let the user edit the real name stored in the database via the myaccount page in case of short-term change of name (in common, marriage)
c) below admin.php add a facility to update all real names stored in the mantis database by command of mantis administrator (only those real names that actually can be obtained from the AD server)

Access to the AD database is granted via the standard LDAP-interface as it will be needed for authetication - you need a binding user

a) query real name from AD and store into the mantis DB when a new user is signed up

This is exactly what MantisBT does today.
The name is also refreshed each time the user logs in.

... in my case, the real name update does not work, anyway.

Which version are you using ? I just (re-)tested this and it works fine for me.

b) let the user edit the real name stored in the database via the myaccount page in case of short-term change of name (in common, marriage)

Are you suggesting that MantisBT updates your LDAP with the updated information ?

In my opinion, an easier and probably more correct way of handling this, would be to update your Master Data, i.e. the LDAP (following your company's HR process I guess), then ask user to login again so that the Mantis DB gets updated.

c) below admin.php add a facility to update all real names stored in the mantis database by command of mantis administrator (only those real names that actually can be obtained from the AD server)

I think this actually is a good idea, but beyond the scope of MantisBT. This could probably be built as a plugin, but I see little chance of it making it into the core.

a)
currently I'm using 1.2.10, but I had to stop using real names in 1.2.0 .

b)
As far as I understood the mantis mechanism in the beginning, mantis would query the LDAP service once for the user's realname in case of sign-in, cf. a), and then would store it in the mantis database.
If the refresh in the mantis db takes place at user login, that's ok

c)
During updates I use a shell script which scans the mantis database for userkeys that have been disabled in the LDAP master-db, and disables them in the mantis db. I see I have to extend it into that direction.
Anyway, for initial filling the mantis db with all users' real names I need such a general query and update tool, since I cannot hope that >>100 users will login at the first day after the change to real names for the mantis to to be updated via the individual logins.

something I forgot:
What if a user will not login for rather a long time, but his real name changes?
In this case only c) would be an appropriate method for the mantis administrator in case of many accounts to survey.

Which all boils down to your point c) - you need some external tool to handle mass-updating of Mantis user table based on LDAP query.

You either need to use an external script or, as I suggested earlier, write a plugin that will add a new button for the Administrator to trigger the mechanism from e.g. the user admin page.

Based on the above as well as your earlier response 0011546:0032256, from my perspective there is no issue with MantisBT.

agreed