fix: fetch enabled_clients from the dedicated endpoint

[davidlovas]

Bug

auth0 users create fails with "There are currently no active database or passwordless connections to choose from" when a connection has enabled_clients: null (the default, meaning enabled for all applications).

Root cause

GetEnabledClients() returns nil when enabled_clients is null in the API response. Instead we use the different API (connections/{id}/clients) to fetch the enabled_clients

Fix

Use dedicated ConnectionManager.ReadEnabledClients instead of GetEnabledClients()

Applied to all 3 occurrences in internal/cli/users.go:

• createUserCmd() (line 407)
• importUsersCmd() (line 897)
• databaseAndPasswordlessConnectionOptions() (line 999)

Tested

Built the patched CLI locally and verified against a tenant with enabled_clients: null on the Username-Password-Authentication connection:

Command	Stock CLI (1.31.0)	Patched CLI
auth0 api post "users" --data '{...}'	Succeeds	Succeeds
auth0 users create -c "Username-Password-Authentication" ...	Fails	Succeeds

Same connection, same tenant — the Management API works, the users create wrapper does not.

Environment

• CLI version: 1.31.0 (also reproduced on 1.29.0)
• OS: macOS (Darwin, arm64)
• Connection: Username-Password-Authentication with enabled_clients: null

[ramya18101]

Hello @davidlovas ,

Thanks for raising the PR, We'll look into it and get back soon!

[ramya18101]

Thanks for the fix, this improves the nil vs empty handling, but I don’t think it addresses the actual migration requirement.

Per the migration docs, enabled_clients from the connection CRUD APIs is deprecated, so we shouldn’t rely on that field here even if nil is interpreted differently. The source of truth should come from the new endpoint instead.

Could we switch this logic to the replacement endpoint instead of adding more handling around the deprecated enabled_clients field?

[davidlovas]

Thanks for the guidance @ramya18101! You're right, I've updated the PR to use the dedicated ReadEnabledClients endpoint (GET /api/v2/connections/{id}/clients) instead of the deprecated enabled_clients field. The go-auth0 SDK already has ConnectionManager.ReadEnabledClients so it was a clean switch.

[ramya18101]

Thanks for the quick change!

We also no longer need the nil check. The ReadEnabledClients endpoint (GET /api/v2/connections/{id}/clients) already handles fetching the default client, so if a valid application is returned in that enabled list, the user creation flow will succeed.

Internally, the core logic treats both nil and [] the same way: as zero enabled clients. Using this endpoint lets us avoid manually distinguishing between those cases.

I tested it, and it works.

[davidlovas]

Acknowledged, simplified and removed the nil check.

[ramya18101]

I've updated the PR description and title!

[ramya18101]

@davidlovas , Can you please fix the linter errors