Skip to content

24-Users

Schema: Verify new columns in show queries
1. Verify that phase_state column exists in show queries output
2. Verify that phase_start_time column exists in show queries output
3. Verify the column types are correct
path: cases/24-Users/test_query_phase_tracking.py

Phase: Verify query phase values
1. Execute show queries and verify phase_state is a valid phase string
2. The only reliably visible query is 'show queries' itself
3. Its phase must be one of the valid phases
path: cases/24-Users/test_query_phase_tracking.py

Long Query: Verify phase tracking for longer queries
1. Create a table with more data
2. Execute a longer running query
3. Verify phase information is captured correctly
path: cases/24-Users/test_query_phase_tracking.py

Concurrent: Verify phase tracking with multiple queries
1. Create multiple tables
2. Execute multiple queries
3. Verify each query has correct phase information
path: cases/24-Users/test_query_phase_tracking.py

Timing: Verify phase_start_time accuracy
1. Record current timestamp before running show queries
2. Execute show queries
3. Verify the visible query's phase_start_time is reasonable
path: cases/24-Users/test_query_phase_tracking.py

SubTask: Verify sub_status includes timing info with human-readable time
1. Create a supertable with multiple child tables to generate sub-tasks
2. Execute a distributed query to trigger sub-plan execution
3. Verify sub_status format contains tid:status:startTime
where startTime is human-readable (e.g. 2026-03-12 10:00:00.123) or "-"
path: cases/24-Users/test_query_phase_tracking.py

MaxLen: Verify phase_state column can hold long phase strings
1. Use currently defined phase values (e.g. those in VALID_PHASES) as reference
2. Verify the column width (32 + VARSTR_HEADER) is sufficient for all of them
3. Show queries and verify no truncation occurs
path: cases/24-Users/test_query_phase_tracking.py

Fetch: Verify phase transitions during fetch operations
1. Execute a query with multiple rows
2. Verify state transitions between fetch/done and fetch/in_progress
3. Each fetch call should set phase to in_progress, then back to done
path: cases/24-Users/test_query_phase_tracking.py

User: basic test
1. Verifies root user default privileges and restrictions on privilege modification attempts
2. Tests creation of users with different SYSINFO privilege levels (0/1)
3. Validates privilege alteration for enable/createdb/SYSINFO flags
4. Check system persistence after dnode restart
5. Ensures proper error handling for invalid privilege values
6. Check create multi users and grant/revoke privilege for them
7. Subscribe topic with different user privileges
path: cases/24-Users/test_user_basic.py

Cloud service user compatibility tests.
Creates a single cloud_user with sysinfo=0 and createdb=1 and drives
all sub-tests without per-test teardown/setup cycles.
Test coverage:
Legacy (3.3.x.y- compatibility, cloud_user only):
1. GRANT/REVOKE READ/WRITE/ALL on dbname.* and dbname.tbname
2. Verify SELECT/INSERT permissions from READ/WRITE grants
New version (3.4.0.0+):
1. Cloud user basic attributes verification
2. Createdb=1 allows DB creation; sub_user is blocked
3. Owner DML on cloud_db (INSERT / SELECT / DELETE)
4. Table management (CREATE / ALTER / DROP)
5. Database-level privilege management (grant/revoke to sub_user)
6. Super-table level privilege with row-level filtering
7. TOPIC privilege management (CREATE / SUBSCRIBE / DROP)
8. STREAM privilege management (CREATE / SHOW / STOP / DROP)
9. information_schema access for taosx-style metadata queries
10. taosx data subscription pattern
11. taosx read query correctness (aggregates, schema discovery)
12. SHOW DATABASES / STABLES / TABLES visibility with SYSINFO=0
13. Multi-user privilege delegation via root
path: cases/24-Users/test_user_cloud_compatible.py

User control
1. Create 1 stable 20 child table 1 normal table
2. Insert each table 10 rows data
3. Restart taosd
4. Check root user exist
5. Create 5 test users
6. Check test users exist
7. Login with test users
8. Check test users can access their own data
9. Change test users privileges
10. Alter test users password
11. Login with altered password
12. Check test users can access their own data after privilege changed
13. Disable some users and check they can not access data
path: cases/24-Users/test_user_control.py

Password: crypted password
Create encrypt_key and test to create user and login with crypted password
path: cases/24-Users/test_user_crypted_pass.py

User manager
1. create user with variant options
- SESSION_PER_USER
- CONNECT_TIME
- CONNECT_IDLE_TIME
- CALL_PER_SESSION
- VNODE_PER_CALL
- FAILED_LOGIN_ATTEMPTS
- PASSWORD_LOCK_TIME
- PASSWORD_LIFE_TIME
- PASSWORD_GRACE_TIME
- PASSWORD_REUSE_TIME
- PASSWORD_REUSE_MAX
- INACTIVE_ACCOUNT_TIME
- ALLOW_TOKEN_NUM
- HOST white list
- NOT_ALLOW_HOST black list
- ALLOW_DATETIME
- NOT_ALLOW_DATETIME
- combine options
- check created options work fine
2. show user
- show user command
- query information_schema.ins_users
3. alter user options
- alter user to change options
- check altered options work fine
4. drop user
5. exception on create/alter/drop user
path: cases/24-Users/test_user_manager.py

User manager
1. create user with variant options
- SESSION_PER_USER
- CONNECT_TIME
- CONNECT_IDLE_TIME
- CALL_PER_SESSION
- VNODE_PER_CALL
- FAILED_LOGIN_ATTEMPTS
- PASSWORD_LOCK_TIME
- PASSWORD_LIFE_TIME
- PASSWORD_GRACE_TIME
- PASSWORD_REUSE_TIME
- PASSWORD_REUSE_MAX
- INACTIVE_ACCOUNT_TIME
- ALLOW_TOKEN_NUM
- HOST white list
- NOT_ALLOW_HOST black list
- ALLOW_DATETIME
- NOT_ALLOW_DATETIME
- combine options
- check created options work fine
2. show user
- show user command
- query information_schema.ins_users
3. alter user options
- alter user to change options
- check altered options work fine
4. drop user
5. exception on create/alter/drop user
path: cases/24-Users/test_user_manager_localrun.py

Password call c unit test
1. Compile script/api/passwdTest.c to passwdTest
2. Run passwdTest and check retcode is 0
path: cases/24-Users/test_user_passwd.py

Password: basic
1. Creation and modification of users with various password formats (valid/invalid patterns)
2. Verification of password complexity requirements (length/special characters)
3. Testing cross-user permission restrictions during password changes
4. Validation of system behavior with maximum password length boundaries
5. Special character handling in passwords and error case verification
6. Login with strong password
path: cases/24-Users/test_user_password.py

Privilege: create db
Verify user privileges for database creation, including grant, revoke, and query operations.
path: cases/24-Users/test_user_privilege_create_db.py

Privilege: db
Verify user privileges related to database operations, including grant, revoke, and query privileges.
path: cases/24-Users/test_user_privilege_db.py

Privilege: sysinfo
1. Verify user privileges related to sysinfo operation, including grant, revoke, and query privileges.
2. Verify bug TS-5130 (normal user with sysinfo privilege cannot access information_schema)
path: cases/24-Users/test_user_privilege_sysinfo.py

Privilege: table
Verify user privileges related to table operations, including grant, revoke, and query privileges.
path: cases/24-Users/test_user_privilege_table.py

Except reset query cache
1. Reset query cache before grant/revoke privilege
2. Reset query cache after grant/revoke privilege
3. Check show command and query command correctness
path: cases/24-Users/test_user_privilege_table.py

Privilege: topic
Verify user privileges related to topic operations, including grant, revoke, and query privileges.
path: cases/24-Users/test_user_privilege_topic.py

User token login
1. Create token
- Basic creation
- With options (ENABLE, TTL, PROVIDER, EXTRA_INFO)
- IF NOT EXISTS clause
- Max length token name (31 characters)
- Multi-language support
- Exception cases:
- duplicate name
- non-existent user
- over-length name
- invalid parameters
- over-length provider
- over-length extra_info
2. Show tokens
- SHOW TOKENS command
- Query from system table ins_tokens
- Query specific token with filters
- Verify row counts consistency
3. Alter token
- Modify single property (ENABLE, TTL, PROVIDER, EXTRA_INFO)
- Modify multiple properties at once
- Exception cases:
- non-existent token
- empty name
- invalid parameters
- over-length provider
- over-length extra_info
4. Delete token
- Normal drop operation
- IF EXISTS option
- Verify deletion from system table
- Exception cases: non-existent token, empty name, duplicate deletion
5. Token login
- Normal token login
- Disabled token login failure
- Enable/disable toggling
- Login failure after deletion
- Recreate same-name token
- Modify TTL and login
- Exception cases: invalid token string, too short/long, special characters
path: cases/24-Users/test_user_token.py

User totp login
1. Create TOTP
- super root account create key
- default user account create key
- disabled user account create key
- sysinfo disabled user account create key
- check duplicate create key
- exception cases
2. Alter TOTP
- alter totp for default user
- login with new totp
- login with old totp fail
3. Delete TOTP
- drop totp for super root account
- drop totp for disabled user account
- duplicate drop totp
- login fail after drop totp
- exception cases
4. Login with TOTP
- exception cases:
- non-exist user
- wrong password
- empty user
- empty password
- empty totp code
- wrong totp code
- totp code expired (30s)
path: cases/24-Users/test_user_totp.py

Whitelist: basic test
Verify basic usage of whitelist functionality, including creation and display operations.
path: cases/24-Users/test_user_whitelist.py