Allow regular users to see peers of group he belongs to

[a-elkaim]

Before posting

• I searched existing discussions and issues for similar requests.
• I checked the documentation to confirm this is not already supported.
• This is a product idea or enhancement request, not a support question.
• I removed or anonymized sensitive details from examples and screenshots.

Product area

CLI, Desktop UI, Mobile app, Dashboard / Admin UI, Management service / API

Problem or use case

We are managing a fleet of IoT devices, we are keeping track of the devices through their MAC Addresses.

In a near future, the support team will need to SSH into the devices for basic troubleshooting:

netbird ssh user@hostname.netbird.selfhosted

or

ssh user@hostname.netbird.selfhosted

To do so, we created accounts with User Role set to "User" (the idea is to give the least permission possible), however we are currently facing a limitation: despite being able to connect to peers belonging to the same group, those peers are not visible in the WebUI (from what I understand, a simple "User" can only see peers he registered himself).

Because of this limitation, the support team is not able to determine which device they need to connect to on their own.

Either we give them an "Auditor" account (but then they can see ALL the peers), or provide them with the information for them to be able to connect (ie: engineering team member connects to the webui, search for the device using its serial / mac address / other... , and provides the IP or the hostname to the support).

Apparently, this behavior wasn't always present and might be a regression: #6599

Proposed solution

Since a user can already reach peers from the groups he belongs to (if the policies allow it), either allowing by default a user to see the peers from the groups he belongs to, or making it a per-user setting would solve this issue.

Alternatives or workarounds considered

I played with all the different "User roles" level, the only one that might allow our support team to be autonomous would be "Auditor", but then could see all the other peers, even those that aren't in their groups.

Community impact and priority

Self-hosted server, IoT device currently in final stages of development and will be deployed soon

Examples from other tools or products

No response

Security, privacy, and compatibility considerations

No response

Implementation ideas

A possible implementation, gated behind a new account setting (default off, so current behavior is preserved):

1. New account setting, add RegularUsersGroupPeersViewEnabled bool to Settings in management/server/types/settings.go (next to RegularUsersViewBlocked, incl. Settings.Copy()). Column is picked up by AutoMigrate; the raw Postgres account query in store/sql_store.go (getAccount) also needs the new column.

2. API surface, add optional regular_users_group_peers_view_enabled to AccountSettings in the OpenAPI spec, regenerate types, and wire it through the accounts handler (updateAccountRequestSettings / toAccountResponse) so the dashboard can toggle it.

3. Peer list (DefaultAccountManager.GetPeers, management/server/peer.go), on the restricted path (no peers:read permission), when the setting is on, union the user's own peers (GetUserPeers) with peers from the user's groups via the existing Store.GetPeersByGroupIDs(accountID, user.AutoGroups), deduped by peer ID. RegularUsersViewBlocked keeps precedence and still returns an empty list.

4. Peer detail (DefaultAccountManager.GetPeer), after the existing owner/admin check, allow access when the setting is on and the peer shares at least one group with the user (Store.GetPeerGroupIDs ∩ user.AutoGroups).

5. Accessible peers (GetAccessiblePeers in http/handlers/peers/peers_handler.go), extend the peer.UserID != user.Id check with the same shared-group test (groups are already loaded on the account there).

No store interface changes needed, GetPeersByGroupIDs and GetPeerGroupIDs already exist. Tests: extend TestDefaultAccountManager_GetPeers / _GetPeer and the accessible-peers handler tests (setting off → unchanged, on → own + group peers deduped, regular_users_view_blocked always wins).

Are you willing to help?

Yes, I can submit a PR if the approach is accepted.

Additional context

No response

[zerotohero]

I've implemented this proposal as a draft PR: #6771

It follows the plan in this discussion closely — an opt-in, default-off account setting RegularUsersGroupPeersViewEnabled:

• GetPeers unions the user's own peers with peers from their groups (GetPeersByGroupIDs(user.AutoGroups)), deduped by peer ID.
• GetPeer and GetAccessiblePeers allow access when the target peer shares at least one group with the user.
• RegularUsersViewBlocked keeps precedence — it still returns no peers when enabled.
• The new field is wired through Settings/Copy(), the raw pgx getAccount query, and the OpenAPI AccountSettings schema (regenerated types.gen.go), so the dashboard can toggle it.

Build and tests are green: GetPeers / GetPeer / GetAccessiblePeers plus an accounts-handler round-trip, covering setting-off (unchanged), own∪group deduped, disjoint-group exclusion (real intersection), and blocked-wins precedence.

@a-elkaim — since you offered to submit a PR, feel free to take this over or use it as a base. Would a maintainer be willing to weigh in on whether a default-off setting like this is an acceptable approach? Happy to adjust to fit the preferred design. This also addresses the regression reported in #6599.