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:
listgetcreateupdatedeleteenabledisablereset-passwordroles
Minimal runnable example:
hbi user get 1 --output jsonRepresentative 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
listorsearch - Pair real write actions with
--dry-runfirst
user-group
Purpose: manage user groups.
Common subcommands:
listgetcreateupdatedelete
org
Purpose: manage org trees and external synchronization.
Common subcommands:
listgetget-by-codetreessync
user-attr
Purpose: manage user attributes.
Common subcommands:
listgetcreateupdatedeletevalues
tenant
Purpose: manage tenants and tenant administrators.
Common subcommands:
listgetcreateupdatedeleteenabledisableusersengine-configreset-passwordreset-adminstatistics
subject
Purpose: manage subject domains and the metrics attached to them.
Common subcommands:
listshowcreateupdatedeleteadd-metricsremove-metricstoggle-onlinelist-metricstokenize
kanban
Purpose: manage analysis kanbans.
Common subcommands:
listshowcreateupdatedeleteduplicateadd-metricexport
permission
Purpose: inspect permissions in a read-only way.
Common subcommands:
folder-listfolder-getapp-listapp-getapp-rules
Minimal runnable example:
hbi permission app-get <app-id> --output jsonUse 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
--areato scope by space (personal-area/public-area/app-mart/system-portal)
authorize
Purpose: perform real grant and revoke actions.
Common subcommands:
getgrantrevoke
Pair higher-risk authorization changes with --dry-run first.
Minimal runnable example:
hbi authorize grant app <app-id> --user <user-id>:viewer --dry-runThis 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 viewerCommon next steps:
- Remove
--dry-runto 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, andtenant - 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.