The role-edit UI's Permissions tab groups permissions by module (Settings, Users, Admin, OpenIddict in our test). When a downstream app builds its own modules (Customers, Invoices, etc.), those modules don't appear in the Permissions tab — they don't implement ConfigurePermissions.
The framework has PermissionRegistryBuilder.AddPermissions<T>() — UsersModule.cs:51 does builder.AddPermissions<UsersPermissions>(); — but nothing in the bootstrap, template, or docs surfaces this to consumers writing their own modules. Discoverability is read-the-source-only.
Fix options
- Template module example.
template/SimpleModule.Host-equivalent module template includes a stub ConfigurePermissions showing the pattern.
- README in
SimpleModule.Permissions explains the convention with a worked example.
- (More invasive) automatic permission registration based on
[RequirePermission] attributes on endpoint handlers — eliminates the boilerplate entirely.
Right now permissions in the framework are a real first-class feature that's only useful for framework-internal modules. Consumer apps essentially get role-based-only auth out of the box, with no path to permission gating without source-diving.
The role-edit UI's Permissions tab groups permissions by module (Settings, Users, Admin, OpenIddict in our test). When a downstream app builds its own modules (
Customers,Invoices, etc.), those modules don't appear in the Permissions tab — they don't implementConfigurePermissions.The framework has
PermissionRegistryBuilder.AddPermissions<T>()—UsersModule.cs:51doesbuilder.AddPermissions<UsersPermissions>();— but nothing in the bootstrap, template, or docs surfaces this to consumers writing their own modules. Discoverability is read-the-source-only.Fix options
template/SimpleModule.Host-equivalent module template includes a stubConfigurePermissionsshowing the pattern.SimpleModule.Permissionsexplains the convention with a worked example.[RequirePermission]attributes on endpoint handlers — eliminates the boilerplate entirely.Right now permissions in the framework are a real first-class feature that's only useful for framework-internal modules. Consumer apps essentially get role-based-only auth out of the box, with no path to permission gating without source-diving.