You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Document IModulePermissions / PermissionRegistryBuilder.AddPermissions for downstream module authors #137
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.
Resolved by #140 (and earlier work on the Permissions feature finder).
Three of the surfaces called out in the issue are now in place:
README in SimpleModule.Permissions — modules/Permissions/src/SimpleModule.Permissions/README.md documents the IModulePermissions convention with a worked CustomersPermissions example, the RequirePermission usage on endpoints, the role-edit grouping behaviour, and a link to the full docs/site/guide/permissions.md guide.
Template module example — cli/SimpleModule.Cli/Templates/ModuleTemplates.cs (FallbackPermissionsClass, line 1008) scaffolds a starter {Name}Permissions.cs for every module created by sm new module <Name>.
Automatic permission registration — framework/SimpleModule.Generator/Discovery/Finders/PermissionFeatureFinder.cs discovers IModulePermissions implementors at compile time and the source generator registers them automatically. Downstream module authors do not need to call AddPermissions<T>() themselves.
Consumer apps can now permission-gate without source-diving.
Activity
fix: address remaining issues from downstream feedback (#140)
antosubash commentedon Apr 30, 2026
Resolved by #140 (and earlier work on the Permissions feature finder).
Three of the surfaces called out in the issue are now in place:
SimpleModule.Permissions—modules/Permissions/src/SimpleModule.Permissions/README.mddocuments theIModulePermissionsconvention with a workedCustomersPermissionsexample, theRequirePermissionusage on endpoints, the role-edit grouping behaviour, and a link to the fulldocs/site/guide/permissions.mdguide.cli/SimpleModule.Cli/Templates/ModuleTemplates.cs(FallbackPermissionsClass, line 1008) scaffolds a starter{Name}Permissions.csfor every module created bysm new module <Name>.framework/SimpleModule.Generator/Discovery/Finders/PermissionFeatureFinder.csdiscoversIModulePermissionsimplementors at compile time and the source generator registers them automatically. Downstream module authors do not need to callAddPermissions<T>()themselves.Consumer apps can now permission-gate without source-diving.
Generated by Claude Code