# Admin Master role

The application now supports an internal `admin_master` role.

Behavior:

- The installer-created first admin account is the bootstrap `admin_master`.
- Existing installations are auto-upgraded on boot: if the `users.role` enum is still old, it is expanded, and if no master exists yet, the oldest `admin` account is promoted to `admin_master`.
- `admin_master` can log in anywhere an `admin` can.
- `admin_master` is the only role allowed to access admin configuration.
- User management remains available to normal admins and to `admin_master`, but the elevated role itself is still hidden from visible labels and selectors.
- Only an existing `admin_master` can create or promote another `admin_master`; normal admin UI still does not expose that role in selectors.
- When the signed-in user is an `admin_master`, user-management screens identify master accounts as `Administrador Master` and expose the master option in the role selector.
- UI labels and API auth responses normalize `admin_master` to `admin` so the elevated role stays hidden from normal surfaces.
- Admin user create/edit forms do not expose `admin_master` as a selectable option.
- Editing an existing `admin_master` account through the standard admin option preserves the elevated role instead of demoting it accidentally.

Existing databases need a one-time schema update plus manual promotion of the intended account:

```sql
ALTER TABLE users
  MODIFY COLUMN role ENUM('admin_master','admin','editor','subscriber')
  NOT NULL DEFAULT 'subscriber';

UPDATE users
SET role = 'admin_master'
WHERE email = 'master-admin@example.com';
```

Replace the email filter with the correct account before running the update.