Users, Tenants & Permission Commands

This page covers users, orgs, tenants, subject domains, kanban resources, and authorization flows. It aligns most closely with the hbi-user-mgmt, hbi-indicator-center, and hbi-permission skills.

user

Purpose: manage user accounts.

Common subcommands:

• list get
• create update delete
• enable disable
• reset-password
• roles

Minimal runnable example:

hbi user get 1 --output json

Representative output:

{
  "id": 1,
  "name": "admin",
  "email": "admin@example.com",
  "enable": true,
  "userType": "internal",
  "loginName": "admin",
  "roles": [
    {
      "id": 1,
      "name": "admin",
      "description": "System administrator"
    }
  ],
  "platformConfig": {
    "enable": true,
    "isManager": true
  },
  "organizations": [
    {
      "id": 1,
      "name": "Default Organization",
      "enable": true
    }
  ]
}

Common next steps:

• List users: hbi user list --limit 10 --output json
• Show user roles: hbi user roles 1 --output json
• Dry-run disable: hbi user disable 1 --dry-run
• Execute disable: hbi user disable 1

Drill-down guidance:

• If you only know a name and not an ID, start with list or search
• Pair real write actions with --dry-run first

user-group

Purpose: manage user groups.

Common subcommands:

• list get
• create update delete

org

Purpose: manage org trees and external synchronization.

Common subcommands:

• list get get-by-code
• trees
• sync

user-attr

Purpose: manage user attributes.

Common subcommands:

• list get
• create update delete
• values

tenant

Purpose: manage tenants and tenant administrators.

Common subcommands:

• list get
• create update delete
• enable disable
• users
• engine-config
• reset-password reset-admin
• statistics

subject

Purpose: manage subject domains and the metrics attached to them.

Common subcommands:

• list show
• create update delete
• add-metrics remove-metrics
• toggle-online
• list-metrics
• tokenize

Filter subject domains by title:

hbi subject list --query coffee --output json

--query trims surrounding whitespace and performs a case-insensitive containment match against the subject-domain title. The result remains a subject tree: each level retains only matching nodes or nodes with matching descendants, together with their ancestors and idPath; it is not a flat search result. A blank query is equivalent to omitting --query, and behavior without the option is unchanged.

JSON and YAML output return an empty array ([]) when nothing matches. Table output displays No subject domains found..

Run hbi subject list --help to confirm that the installed HBI CLI exposes --query. With Sense 6.2, the server still returns the complete subject tree and the CLI filters it locally. With Sense 6.3 and later, the server prefilters with q, and the CLI applies the same filter again to keep results consistent.

kanban

Purpose: manage analysis kanbans.

Common subcommands:

• list show
• create update delete duplicate
• add-metric
• export

permission

Purpose: inspect permissions in a read-only way.

Common subcommands:

• folder-list folder-get
• app-list app-get
• app-rules

Minimal runnable example:

hbi permission app-get <app-id> --output json

Use it to inspect app-level permission configuration for users, user groups, and roles.

Common next steps:

• Show folder permissions: hbi permission folder-get <folder-id> --output json
• List all app permissions: hbi permission app-list --output json
• Show app permission rules: hbi permission app-rules <app-id> --output json

Drill-down guidance:

• For actual permission changes, use authorize
• You can combine this with --area to scope by space (personal-area / public-area / app-mart / system-portal)

authorize

Purpose: perform real grant and revoke actions.

Common subcommands:

• get
• grant
• revoke

Pair higher-risk authorization changes with --dry-run first.

Minimal runnable example:

hbi authorize grant app <app-id> --user <user-id>:viewer --dry-run

This previews granting viewer access on an app.

Representative output:

Dry-run mode: the following actions would be executed.
Grant permission to app <app-id>:
  - user <user-id> as viewer

Common next steps:

• Remove --dry-run to execute the grant
• Verify the result: hbi permission app-get <app-id> --output json
• Revoke access: hbi authorize revoke app <app-id> --user <user-id> --dry-run

Drill-down guidance:

• Supported roles include viewer, editor, administrator, and tenant
• You can batch grants: --user 1:viewer --user 2:editor
• You can target organizations: --organization <org-id>:viewer

Where to drill down next

Scenario	Start with
users and user groups	user / user-group
org trees and org sync	org
user attributes and value lists	user-attr
tenants, administrators, and engine config	tenant
subject domains and attached metrics	subject
kanban resources	kanban
inspect permissions in read-only mode	permission
perform real grant or revoke actions	authorize

When you need exact flags and examples, use that command tree's --help in the terminal.