- ABP Framework version: v9.1.0
- UI Type: Angular
- Database System: EF Core (SQL Server)
- Tiered (for MVC) or Auth Server Separated (for Angular): no
- Exception message and full stack trace: No thrown error
- Steps to reproduce the issue:
We have a multi-tenant application that we're in the process of building. External client users have their own tenancy in the application with specific roles that have reduced permissions assigned. Internal users are part of the host tenancy. We've defined a tree structure of permissions as follows:
Application (MultiTenancySides = Both) -> Application Area (MultiTenancySides = Both) -> Update (MultiTenancySides = Host) -> Delete (MultiTenancySides = Host)
If a users role has access to the application area permission then we assume they have read-only access to that area. The navigation menu requiredPolicy is set to ensure that the users role has permission on the application area in order to show the menu item. For internal users this all works. If an application area permission is turned off for an internal role then the menu item disappears for them. If turned back on then it reappears.
For an external tenant user, even though an application area permission is not enabled for their role the system still thinks they have read only access and so shows them the menu items.
Any thoughts on what the issue might be here?
Thanks
2 Answer(s)
-
0
In ABP, when you define permissions with MultiTenancySides, permissions marked as Host are only available to host users, and Tenant for tenant users. Permissions with Both are available to both.
If your menu's requiredPolicy is set to the "application area" permission (MultiTenancySides = Both), then both host and tenant users can be granted this permission. If a tenant user is seeing the menu item even when their role does not have the permission, it usually means:
- The permission is being granted by default to tenant roles (e.g., tenant admin), or
- The permission check logic is not correctly evaluating the user's granted permissions.
By default, when you add a new permission, it is not automatically granted to existing tenant roles unless you explicitly seed it. However, if your permission tree is structured so that a parent permission is granted, all child permissions may be considered granted unless you override this behavior.
For your scenario, ensure:
- The "application area" permission is not granted to the tenant user's role.
- The permission check in your menu (requiredPolicy) is checking for the correct permission name.
- You are not programmatically granting the permission elsewhere (e.g., in a migration or seeding service).
To debug:
- Check the AbpPermissionGrants table for the tenant and user/role in question to see if the permission is granted.
- Use the Permission Management UI or API to verify the effective permissions for the user/role.
- If you are using hierarchical permissions, ensure that granting a parent does not implicitly grant children unless intended.
If you want tenant users to have read-only access only when explicitly granted, make sure the "application area" permission is not granted by default to tenant roles, and that your menu checks for this permission.
If you have recently added new permissions, remember that existing tenant roles will not have them granted automatically. You may need to update your seeding logic or manually assign them.
Sources:
This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.
-
0
AI answer did not help but pointed me at table which helped me to answer myself
