> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hitaji360.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Platform administration permissions catalog

> Every checkbox on the role editor for the User Management and Tenant Management modules, with a plain description of what each one does.

When you edit a role under **Settings → Access → Roles & Permissions**, you see a list of modules, and each module has a row of checkboxes. This page covers the two modules that control platform-level administration — **User Management** (the "Users" and "Roles" modules) and **Tenant Management** (the "Tenant Admin" module) — with a plain description of what turning each checkbox on actually lets someone do.

There are **2 modules and 10 checkboxes** in User Management, and **1 module and 5 checkboxes** in Tenant Management. Every module here follows the same five-checkbox pattern: **Add** (create new), **Edit** (change existing), **Delete** (remove), **View** (see it), **View All** (see everyone's, not just your own) — there are no module-specific actions in this area, unlike Loans or Reports elsewhere on the platform.

**Where to manage this:** Settings → Access → Roles & Permissions. These are high-privilege, organization-wide modules — anyone with **Edit** on Roles can change what every other role (including their own) is allowed to do, and anyone with **Delete** on Users can remove other people's accounts. Grant them sparingly.

***

## User Management

### 1. Roles

This is the permission that controls the role editor itself — the same screen you're reading about right now. Because of that, it's one of the most sensitive checkboxes on the platform: whoever has it can change what any other role (including roles held by SuperAdmins) is allowed to do.

| Checkbox     | What it does                                                                                                            |
| ------------ | ----------------------------------------------------------------------------------------------------------------------- |
| **Add**      | Create a new role.                                                                                                      |
| **Edit**     | Change what an existing role can do — i.e. flip these very checkboxes for any role.                                     |
| **Delete**   | Remove a role entirely.                                                                                                 |
| **View**     | See the list of roles that exist and what each one can do.                                                              |
| **View All** | See every role, including ones outside your own scope (e.g. across tenants or products), not just the ones tied to you. |

> **Verified enforcement gap:** the endpoints behind this module (`GET /api/admin/roles`, `DELETE /api/admin/roles/{roleId}`) don't check these permission checkboxes at all. They're gated only by a hardcoded check that the caller holds the built-in **SuperAdmin** or **Admin** identity role — not by whether their role has `roles:read` or `roles:delete` granted. In practice, toggling **View** or **Delete** here has no effect: only membership in SuperAdmin/Admin controls access to those two actions today.

***

### 2. Users

This governs the user list and the actions available from it — looking someone up, editing their profile, deactivating their account, or granting them a one-off extra permission outside of their assigned role.

| Checkbox     | What it does                                                                                                   |
| ------------ | -------------------------------------------------------------------------------------------------------------- |
| **Add**      | Invite or add a new user account to the platform.                                                              |
| **Edit**     | Change a user's details, and grant/revoke one-off permission or claim overrides on top of their assigned role. |
| **Delete**   | Remove a user's account.                                                                                       |
| **View**     | See the list of users and look up an individual user's details.                                                |
| **View All** | See every user across the platform, not just ones in your own scope.                                           |

> **Verified enforcement gap:** the same pattern applies here. `GET /api/admin/users` (the user list), `PUT /api/admin/users/{userId}` (edit), and `DELETE /api/admin/users/{userId}` (delete) carry no permission check tied to these checkboxes — they inherit the controller-wide hardcoded requirement that the caller be in the **SuperAdmin** or **Admin** identity role. Assigning a role with only `users:read` (and not the SuperAdmin/Admin identity role) does not currently grant access to these screens.

***

## Tenant Management

### 1. Tenant Admin

Hitaji 360 is multi-tenant: each organization ("tenant") that signs up gets its own space, and can subscribe to one or more products (Sacco360, HR, Edu360, and so on). This module covers the admin-side actions around that — listing tenants, linking or unlinking a user from a tenant, suspending/reactivating a user's membership in a tenant, and provisioning the standard set of roles for a tenant when it subscribes to a new product. It does **not** cover the separate, standalone Tenant Management application (a different product used for commercial subscription management) — this is the auth-service's own tenant-administration surface, reached from the same role editor as everything else here.

| Checkbox     | What it does                                                                                                         |
| ------------ | -------------------------------------------------------------------------------------------------------------------- |
| **Add**      | Link a user to a tenant, or provision (clone) the standard set of roles for a tenant when it takes on a new product. |
| **Edit**     | Suspend or reactivate a user's membership in a tenant, or change their role assignment within that tenant.           |
| **Delete**   | Remove a user's link to a tenant.                                                                                    |
| **View**     | See the list of tenants (organizations) on the platform.                                                             |
| **View All** | See every tenant across the platform, not just ones tied to your own scope.                                          |

> **Verified enforcement gap:** `GET /api/admin/tenants` (the tenant list behind **View**) has the same issue as Roles and Users above — it's gated purely by the hardcoded **SuperAdmin**/**Admin** identity-role check, not by the `tenant-admin:read` claim this checkbox grants. Separately, the role-provisioning endpoint (`POST /api/admin/tenants/{tenantId}/provision-roles`) runs the *opposite* mismatch: it's open to any authenticated caller regardless of role or permission claims (used by automated service-to-service calls), so **Add** here doesn't gate it either, in the other direction — it's less restrictive than the checkbox implies, not more.

***

## Related

* [SACCO roles & permissions catalog](/sacco/user/settings/roles-and-permissions) — the equivalent checkbox-by-checkbox catalog for the Sacco360 product modules.