Personalize LDAP fields cached

[maturbet]

To customize the list of ldap account fields to be cached for a user.

[vboctor]

Thanks @maturbet for your contribution.

1. Please update $g_public_config_names with the new config option name.
2. Update manual with new config option configuration.
3. Add an issue in the bug tracker and reference it from the commit.

[atrol]

Please update $g_public_config_names with the new config option name.

@vboctor why do you want it in $g_public_config_names?
Similar options like $g_ldap_uid_field are not part of this list.

Independent from that, shouldn't we add all ldap options to $g_global_settings?

[maturbet]

Is there any hope to view it in MantisBT 2.25 ?

[vboctor]

@atrol I'm fine with your recommendations.

[vboctor]

@maturbet can you elaborate on scenarios where adding more fields (like the room number) would add value? I look at the issue and don't see the scenarios where this would be useful.

[atrol]

@atrol I'm fine with your recommendations.

@vboctor I opened #1639 for

Independent from that, shouldn't we add all ldap options to $g_global_settings?

Concerning my other recommendation

@vboctor why do you want it in $g_public_config_names?

To be sure, it means you agree that @maturbet should remove the setting from this array?

[maturbet]

@maturbet can you elaborate on scenarios where adding more fields (like the room number) would add value? I look at the issue and don't see the scenarios where this would be useful.

@vboctor here an exemple how we use this functionnality :
exemple_ldap.txt

[dregad]

So this PR is basically in support of a local customization, i.e. adding a new ldaplink custom field type that you have defined in your installation.

Unless we are planning to add this to core as well (and I personally don't believe we should), it does not make sense to update the LDAP API per your suggestion.

In my opinion you should maintain this custom code in your own fork.

[maturbet]

@dregad
It was just an example.
The strength of MantisBT is that it is highly customizable, with the possibility of many parameters, the custom_functions as well as the EVENT_* make this tool very attractive.
It's a sad thing that with such a policy, there is such a static list ($t_search_attrs) with hard-coded values and not customizable.

[maturbet]

@vboctor @dregad
An other exemple (not implemented yet in internal plugin) :
Associated with EVENT_MENU_ACCOUNT we will be able to add to the user's menu, specific links composed with data from LDAP.

Many informations could be usefull in LDAP, not only mail or realName

[maturbet]

an other exemple (not from us)
https://www.mantisbt.org/bugs/view.php?id=23392

[vboctor]

I suggest updating the issue in the bug tracker with the plugin scenario. I also added a couple of minor comments.

[dregad]

😂

[maturbet]

@dregad seriez-vous francophone ? ;-)

[dregad]

Je suis démasqué 👼

[maturbet]

@dregad @vboctor
Does that make sense to be added ?
Association-Cocktail#1

[vboctor]

@maturbet I wonder if what is really needed here is a plugin event that allows adding more fields to the list loaded by LDAP API. This would enable building a plugin that can fetch more LDAP fields and display them or use them in the appropriate scenarios. I would generally prefer that model over the approach in this PR and the one you linked to for adding to the user profile page.

[maturbet]

@vboctor I agree with you, it would certainly be much better.
However, I'm not a developer, I don't know much about php and I wouldn't know how to create a plugin event. I also don't see how to make these fields appear in the user profile pages via a plugin.
But maybe I'll try ...

[maturbet]

During my personal time :
@vboctor, do you prefer this way ?
#1660

[maturbet]

Well, I'm throwing in the towel.