list of users membership in group when in mixed mode 1.0.9x is not showing the same info as in 1.0.8.9
list of users membership in group when in mixed mode 1.0.9x is not showing the same info as in 1.0.8.9
it used to be "$sn, $givenname (uid)"
it is now "uid) which is quite ugly for final users
(from redmine: issue id 4194, created on 2015-10-09, closed on 2015-10-12)
- Relations:
- copied_to #4208
- Changesets:
- Revision fe535ba8 by Côme Chilliet on 2015-10-12T08:11:52.000Z:
Fixes #4194 Using nameAttr and not mainAttr for display- Revision 87165663 by Côme Chilliet on 2015-10-12T08:12:48.000Z:
Fixes #4194 Using nameAttr and not mainAttr for display- Custom Fields:
- Bug in version: 1.0.9
Activity
The following patch can be applied to fix the problem:
(from redmine: written on 2015-10-10)
By kiorky on 2017-09-02T15:24:30 (imported from GitLab)
Mathieu Le Marec - Pasquet wrote:
See the patch, the refactoral has sniped out a lot of code, specially on groups and users display, leaving out only cn (or uid). Replacing by nameAttr wont change a thing
It will change. mainAttr is what is used in the dn, in your case uid. It’s not what should be displayed. nameAttr is what should be displayed, the cn in the case of users.
If you set your cn pattern to «%sn%, %givenName%», I think you should get the same result as with you patch. I pushed the change to nameAttr as it is needed any way (if not for users then for other object types). You can test the git version and report any problem.
(from redmine: written on 2015-10-12)
By Côme Chilliet on 2017-09-02T15:24:30 (imported from GitLab)
As already explained on IRC, i can't change the CN to something else for organizational purpose.
If i change the pattern, i also have to migrate the data (which is not a big deal, this is not the problem).
On other hand, this was the behavior for ages to have $lastname, $firstname [uid], which is now changed, and can be considered as a non documented break.
If you want not to ardcode a label here, the only solution i see is to have a specific and configurable pattern for group and user display on those specific pages. (this label would have to default to firstname [uid], of course.)
The meaning is different on those pages.
(from redmine: written on 2015-10-12)
By kiorky on 2017-09-02T15:24:31 (imported from GitLab)
Mathieu Le Marec - Pasquet wrote:
As already explained on IRC, i can't change the CN to something else for organizational purpose.
If i change the pattern, i also have to migrate the data (which is not a big deal, this is not the problem).
If it is not a big deal, you should do this as FD relies on the CN for several other things and will continue to do so in the future
On other hand, this was the behavior for ages to have $lastname, $firstname [uid], which is now changed, and can be considered as a non documented break. This is just a question of how things are displayed, it does not break anything. There are a lot of changes like this in each FD release as we tend to uniform things and use the new internal tools in every plugin.
If you want not to hardcode a label here, the only solution i see is to have a specific and configurable pattern for group and user display on those specific pages. This is exactly the purpose of the CN field in FD and this is why you can now easily change its pattern in the «CN pattern» field of the configuration. We want the display of users to be consistent across pages and do not want a specific pattern for each page.
(from redmine: written on 2015-10-12)
By Côme Chilliet on 2017-09-02T15:24:32 (imported from GitLab)
added Fixed label
By bmortier on 2018-10-05T15:00:01 (imported from GitLab)
