new-permission

To add a new RBAC permission variant, you extend the Permission enum with a new module/action pair scope and update its TypeScript bindings. This requires modifying key_str(), module(), action(), and implied_permission() mappings to keep type-safe relationships intact.

Wiring implied permissions for a new RBAC scope involves updating the implied_permission() mapping to preserve read-to-manage semantics. This ensures that granting a manage permission automatically implies the corresponding read permission across both backend checks and frontend UI gating.

To keep TypeScript permission types in sync with a Rust Permission enum, you regenerate frontend types after modifying the backend enum. This is validated by running cargo test and make types to ensure the generated TypeScript bindings match the updated Rust variants.

Yes, you need to run cargo test and make types after extending an RBAC permission enum. These commands validate that the new variant's key_str(), module(), and action() mappings are correct and that the regenerated TypeScript frontend bindings are fully synchronized.

Introducing a new RBAC module and action pair requires updating downstream routes, admin datatables, and frontend UI gating components. This end-to-end integration ensures access controls are consistently enforced across backend API checks and frontend user interfaces.

Yes, you can safely add a topups.read permission scope by following the standardized enum extension pattern. By updating the implied_permission() mappings and validating with cargo test, you ensure existing access controls and type-safe frontend bindings remain unbroken.