Group user info still available in "Account info" even if disabled in plugin config #12789

[rowheat02]

Description

The "hideGroupUserInfo" option configured through:

{
  "name": "Login",
  "cfg": {
    "toolsCfg": [
      {
        "hideGroupUserInfo": true
      }
    ]
  }
}

was no longer propagated to the User Details modal. The regression was introduced on PR #10963.
This PR fixes the propagation of login toolsCgf to UserModal.
Now, if hideGroupUserInfo is true, then Groups can not be seen on the User Info modal.

Please check if the PR fulfills these requirements

• The commit message follows our guidelines: https://github.com/geosolutions-it/MapStore2/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (check one with "x", remove the others)

• Bugfix

Issue

What is the current behavior?

#12789

What is the new behavior?

when configured from toolsCfg of Login plugin, groups information of user can be hidden

Breaking change

Does this PR introduce a breaking change? (check one with "x", remove the other)

• Yes, and I documented them in migration notes
• No

Other useful information

[allyoucanmap]

One clarification on how it was working before. Initially OmniBar and SidebarMenu were listing the component of the Login as tools into an array [UserDetails, PasswordReset, Login]:

OmniBar:     { ..., tools: [UserDetails, PasswordReset, Login], ... }
SidebarMenu: { ..., tools: [UserDetails, PasswordReset, Login], ... }

Then the toolsCfg was injected inside the plugin container, see:

• MapStore2/web/client/plugins/OmniBar.jsx

  Line 37 in e3d325b

  cfg: current?.cfg?.toolsCfg?.[index] || {}

• MapStore2/web/client/plugins/SidebarMenu.jsx

  Line 162 in e3d325b

  cfg: current?.cfg?.toolsCfg?.[index] || {}

The possibility to use toolsCfg was mentioned in the migration guide, but not documented on the Login.jsx plugin but only in the internal UserDetailsModal.

Now in the new Login.jsx structure toolsCfg?.[0]?.hideGroupUserInfo may act as a fallback for retro-compatibility but it should not be the new official property (note has mentioned in the migration guide this was working by array index so a different plugin configuration could break this config).

Proposed changes:

   className,
    toolsCfg,
    hideGroupUserInfo: hideGroupUserInfoProp
}, context) {
    const hideGroupUserInfo = !!(hideGroupUserInfoProp || toolsCfg?.[0]?.hideGroupUserInfo);
    const { loadedPlugins } = context;
                showPasswordChange={showPasswordChange}
                showAccountInfo={showAccountInfo}
                isUsingLDAP={isUsingLDAP}
                hideGroupUserInfo={hideGroupUserInfo}

• add a new cfg.hideGroupUserInfo property and use toolsCfg?.[0]?.hideGroupUserInfo only as a fallback
• document this new hideGroupUserInfo in the Login.jsx plugin, this should be visible in the JSDoc so future changes will keep this into account. Only the new hideGroupUserInfo should be officially documented while toolsCfg will be used internally as fallback for existing configurations.
• add a new section in the migration guide where we should document that the new property hideGroupUserInfo also informing that will replace the index based configuration of toolsCfg (we cannot predict if some project changed the structure of the Login.jsx plugin)
• review documentation in the component web/client/components/security/modals/UserDetailsModal.jsx and remove reference from the toolsCfg or plugins (this is an internal component and we should just inform about what the hideGroupUserInfo is doing)

[rowheat02]

@allyoucanmap fixed as requested

• Added cfg.hideGroupUserInfo for the Login plugin to decide whether to hide the user's group.
• toolsCfg[0].hideGroupUserInfo is still supported for backward compatibility
• Updated docs and migrations

[allyoucanmap]

is this in the correct migration section?

I'm seeing this under ## Migration from 2026.01.01 to 2026.01.02 but the milestone for this PR is 2026.02.01.
Could you verify, please?

[rowheat02]

@allyoucanmap now the migration guideline is in the correct place for this.

[allyoucanmap]

@ElenaGallo please test this fix on dev, thanks

[offtherailz]

Request failed due to following response errors:

• Pull request Pull request is a draft