Disabling permissions for User role also disables them for Admin role

Issues
1

Issue Description

After disabling certain permissions for the User role, same permissions appear to have been disabled for the Admin role as well.

As a result, when I navigate to https://mail.example.com/admin/Account/ under the admin user, the following tabs are missing from the left vertical menu: password settings, API settings, and app password settings.

Disabled permissions:
Settings: Get account password settings
Settings: Update account password settings
Settings: Get account settings settings
Settings: Update account settings settings
API keys Management: Get API keys
API keys Management: Create API keys
API keys Management: Update API keys
API keys Management: Destroy API keys
API keys Management: Query API keys
App passwords Management: Get App passwords
App passwords Management: Create App passwords
App passwords Management: Update App passwords
App passwords Management: Destroy App passwords
App passwords Management: Query App passwords
Public keys Management: Get public keys
Public keys Management: Create public keys
Public keys Management: Update public keys
Public keys Management: Destroy public keys
Public keys Management: Query public keys
Sign in using email alias addresses
Interact with AI models
Archived items Management: Get archived items
Archived items Management: Create archived items
Archived items Management: Update archived items
Archived items Management: Destroy archived items
Archived items Management: Query archived items
Masked emails Management: Get masked emails
Masked emails Management: Create masked emails
Masked emails Management: Update masked emails
Masked emails Management: Destroy masked emails
Masked emails Management: Query masked emails

Additionally, when I try to re-enable some of these permissions by removing them from the Disabled Permissions list in the User role, I get the following error:

You are not authorized to grant permissions: sysAccountSettingsUpdate, sysAccountSettingsGet, sysAccountPasswordUpdate, sysAccountPasswordGet

Expected Behavior

Disabling permissions on the User role should not affect the Admin role.

Actual Behavior

The Admin role lost the same permissions, and attempting to restore them returns an authorization error.

Reproduction Steps

  1. Add list of permissions to disable in Directory → Roles → User Role → Disabled Permissions
  2. Save settings and restart docker container
  3. Navigate to https://mail.example.com/admin/Account/

Stalwart Version

v0.16.x

Installation Method

Docker

Database Backend

RocksDB

Blob Storage

RocksDB

Search Engine

Internal

Directory Backend

Internal

Additional Context

Roles assigned to the admin user account: Administrator role

I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.

on

I have searched this support forum (open and closed topics) and confirm this is not a duplicate.

on

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

Let me research this issue with role permissions and inheritance in Stalwart.

Now I have a clear picture. The built-in User role (default_role_ids_user) and the built-in Admin role (default_role_ids_admin) are separate Role objects stored in the database. When you edit the User role’s disabledPermissions, you are modifying that specific Role object. An admin account with UserRoles::Admin resolves to default_role_ids_admin - a different Role object - so the issue is not that admin “inherits” from the user role.

The key insight from the docs is: disabledPermissions takes precedence at every level - including at the account level. Let me check if there’s something about account-level disabled permissions.

3

This is by design,the default defaultAdminRoleIds is [System Administrator, User], i.e. admin accounts also carry the User role so they inherit its defaults. Permission resolution then unions enabled AND disabled across every role in the chain and computes enabled minus disabled, so a permission disabled on ANY role in the chain is gone for the principal.