permission-model-change-guide

Permission Model Change Guide

Applicable Scenarios

• Adding a new IAM resource type
• Designing or adjusting the operation list for a resource type
• Modifying IAM RBAC configuration, instance selectors, or callback data
• Supplementing permission migration, initialization scripts, or online change processes
• Troubleshooting incomplete resource type integration

Inapplicable Scenarios

• Only calling existing permission verification APIs
• Only handling user authorization, adding members, or removing members
• Only modifying ordinary business logic in the Auth module
• Only doing OAuth2 or login authentication

Quick Guide

1. This skill focuses on "how the permission model itself changes", not "how existing permissions are called".
2. A single change usually covers at least four layers: resource definition, operation definition, data initialization, and verification.
3. First enter the corresponding reference document based on the problem type:
   • Resource types and operation design:reference/1-resource-action-design.md
   • IAM configuration, migration, and initialization:reference/2-iam-config-migration.md
   • Callbacks, verification, and common pitfalls:reference/3-callback-validation.md
4. create This type of action is often the special item most easily misconfigured in the permission model; first confirm whether the associated resource is still the parent resource.
5. Any model change must simultaneously consider internationalization, initialization scripts, historical data compatibility, and the online rollout method.
6. If you are changing the RBAC service implementation inside the Auth module rather than the resource model itself, switch to auth-module-architecture。

High-Signal Rules

• A permission model change is essentially a contract change, not just adding a few enums or JSON
• Resource types, operation lists, instance selectors, and callback chains must be considered together
• During online integration, prioritize initialization and compatibility rather than just getting it running locally
• The boundaries of both the API approach and the script approach must be clear to avoid duplicate writes or inconsistent state

Key Pitfalls

• Only adding resource enums without supplementing IAM configuration and the initialization chain
• create、list、manage Incorrect associated resource design for actions such as
• Only changing configuration without doing internationalization, callbacks, and verification
• Misjudging a permission model problem as an ordinary Auth business problem

Further Reading

• Resource types and operation design:reference/1-resource-action-design.md
• IAM configuration, migration, and initialization:reference/2-iam-config-migration.md
• Callbacks, verification, and common pitfalls:reference/3-callback-validation.md
• If you are changing the internal implementation of Auth: see also auth-module-architecture