---
title: v4.0.23 Changelog
description: See what's new in Kener v4.0.23, including new features, improvements, and bug fixes
---

## New features {#new-features}

### Role-based access control (RBAC) {#rbac}

Kener now uses a full RBAC system with roles, permissions, and user-role assignments. This replaces the previous single-role-per-user model with a flexible, permission-driven approach.

- **Permissions** follow a `domain.action` format (e.g. `monitors.read`, `incidents.write`). There are 30+ permissions covering all domains: monitors, incidents, maintenances, pages, triggers, alerts, API keys, users, settings, subscribers, email templates, images, and roles.
- **Built-in roles** — `admin`, `editor`, and `member` — are seeded automatically and cannot be edited or deleted. Admin gets all permissions, editor gets all except `api_keys.delete`, and member gets read-only access.
- **Custom roles** can be created, edited, deactivated, and deleted from the new **Manage → Roles** page. Permissions can be cloned from an existing role during creation.
- **Multi-role assignment** — users can now be assigned multiple roles simultaneously. A user's effective permissions are the union of all their roles' permissions.
- Permissions are enforced at both the **route level** (page access) and the **action level** (API operations).

New database tables: `roles`, `permissions`, `roles_permissions`, `users_roles`. Existing users are automatically migrated from the old `users.role` column to the new `users_roles` table.

See [User Management](/docs/v4/user-management) for full details.

### Roles management UI {#roles-management-ui}

A new **Manage → Roles** page provides full role administration:

- View all roles with their status and type (readonly or custom).
- **Permissions panel** — toggle individual permissions grouped by domain. Readonly roles show permissions in read-only mode.
- **Users panel** — view, add, and remove users assigned to each role.
- **Duplicate role** — create a new role by cloning permissions from an existing one.
- **Delete role** — choose to remove user assignments or migrate users to another role before deletion.

### Login role validation {#login-role-validation}

Users must have at least one active role to sign in. If a user's account exists but has no active roles assigned, login is blocked with a descriptive error message directing them to contact an administrator.

## Improvements {#improvements}

### Multi-role user invitations {#multi-role-invitations}

The **Add User** dialog now shows checkboxes for all active roles instead of a single role dropdown. At least one role must be selected when inviting a new user. All selected roles are validated to be active before the invitation is sent.

### Permission-based UI visibility {#permission-based-ui}

Sidebar navigation and action buttons throughout the manage dashboard are now driven by the current user's permissions. Pages and actions that the user lacks permission for are hidden rather than showing access-denied errors.

## Breaking changes {#breaking-changes}

### Vault page removed {#vault-removed}

The **Manage → Vault** page has been removed from the admin dashboard. The vault route and its associated permission (`vault`) have been dropped from the route permission map.

### User role column migration {#role-column-migration}

The `role` column on the `users` table is migrated to the `users_roles` junction table. A down migration re-creates the `role` column by backfilling from `users_roles` if you need to roll back. Existing user roles are preserved during the migration.