BEP-1008 Discussion

[fregataa]

I left some comment about BEP-1008

1. How about using a scope name "global" rather than "system"?
2. What happen if a client requests a list of Entity in a "domain" scope but the client has a Read permission only in a "project" scope which belongs to the domain? Would the client be rejected or get the Entity in project scope? To clarify how RBAC handles such cases, let's add more details about checking permissions in nested scope recursively in the RBAC check flow section.
3. Does "Role" belong to any scope? Or every Role can be globally used? Should the name of Role is unique globally or in a certain scope?
4. Can the role_permissions.operation column have only "creat", "read" value or can have joined string value like "create,read"?

[HyeockJinKim]

1. I agree that using global as the scope name makes sense and sounds clearer. I’ll update the BEP accordingly.
2. In principle, if the API request is made explicitly in the “domain” scope, the client should only get a response if they also have read permission in the domain scope.
   However, if the API is designed to aggregate entities by traversing all projects under the domain, partial responses can make sense — returning only entities from the projects where the client has permission.
   The actual behavior would depend on API design and use case.
3. Roles themselves are not tied to a specific scope. Instead, scope is applied when checking permissions.
   So the same Role definition can be reused across scopes.
   For uniqueness, we plan to identify Roles by ID rather than enforcing globally unique names.
4. Each permission (e.g., create, read) will have its own row.
   Managing multiple operations in a single comma-separated string would require extra parsing and complicate updates, so I prefer separate rows for clarity and maintainability.
   @fregataa

[fregataa]

Do permissions for managing Roles also exist? If Roles are not bound to scopes, then permissions for managing Roles would need to be handled specially. For example, only superadmin could access Roles, and so on.
However, this approach prevents users with admin privileges in specific scopes from handling Roles. For instance, a Project Admin would not be able to create Roles within a specific project or assign them to users.

[HyeockJinKim]

Yes. To handle permissions for a Role, project and domain information must be in the role table.