Managing Users
The Users tab lists the database’s login roles and lets you manage them with real DDL —
CREATE ROLE, ALTER ROLE, GRANT, REVOKE, DROP ROLE — all recorded in the
audit log. Passwords are excluded from audit entries.
The user list
Filter with the Filter users… box. Each row shows a role badge (superuser, admin, createdb,
nologin, or a plain role) and five privilege chips — S / I / U / D / X for SELECT, INSERT,
UPDATE, DELETE, and DROP. The X chip is worth understanding: AccessVault’s “DROP” privilege is
schema CREATE under the hood (PostgreSQL has no grantable DROP — owners can always drop their
own objects, and CREATE on a schema is the closest manageable proxy).
The user inspector
Select a user to see:
- Privileges — a per-schema grid of the five privileges, with an Edit button per schema.
Hover a granted cell to see where the grant comes from: a direct grant, inherited from
another role, or from
PUBLIC. - Attributes — Superuser, Create role, Create DB, Login, Bypass RLS, Replication, Inherits, and connection limit.
- Member Of — role memberships, with an
ADMINbadge where the membership carries admin option. - Password & Expiry — see below.
- Owned Objects — everything the role owns, by schema and object type.
Granting and revoking privileges
Click Edit on a schema row to open the privileges editor. Each toggle runs a live
GRANT/REVOKE <privilege> ON ALL TABLES IN SCHEMA ... (or CREATE ON SCHEMA for DROP).
Inherited and PUBLIC-sourced privileges appear disabled — they can’t be revoked from here; you’d
need to change the granting role or PUBLIC itself.
Note the scope: grants apply to all current tables in the schema. They don’t install default privileges for future tables.
Creating and dropping users
- Add User creates a login role with a username and password. The password goes straight to the database — AccessVault does not store it. (Password expiry is set afterwards, from the inspector.)
- Drop user (bottom of the inspector) asks for confirmation — “This cannot be undone” — then
runs
DROP ROLE. PostgreSQL will refuse to drop a role that still owns objects or has privileges granted to it; reassign or drop those first.
Password and expiry
From the inspector’s Password & Expiry section:
- Change Password — enter the new password and confirm.
- Password Expiry — set a
VALID UNTILdate (confirm to apply), or click Never to set it to infinity.