RolePermissions
fretje opened this issue · comments
The new RolePermissions view could be made more user friendly.
Nothing personal, @PedroVentura235, you did a great job with the initial version! Just want to iterate on it a bit more ;-)
The Permissions should be split into their respective categories. Similar like how it's done in BlazorHero.
There it's done using tabs. It can be anything: tabs, groups in a table, a treeview or any other of visual representation of groups, but like it is now it's not really easy to find what you need.
The groups in FSHPermissions.cs actually have DisplayName and Description attributes which values could be used in the UI (after running them through the localizer maybe?). I guess they are put there for that reason?
About the descriptions: like it's implemented now, the descriptions of the individual permissions will always be empty.
I thought those descriptions were in FSHPermissions.cs as well. But apparently, as it looks, they live in the database in the RoleClaims table now?
That doesn't make much sense to me to be honest. As one particular permission can be added to different roles, this means those descriptions would have to be duplicated everywhere, and permissions that aren't added to any roles can't have a description? And where would the descriptions come from in the first place?
I think there's something wrong in the design here?
I think we should also put Description attributes on all the individual Permissions in FSHPermissions.cs, And take them from there in stead for the UI. And then simply remove the Description property from ApplicationRoleClaim and the dto's that are derived from it... no need to send those over the wire either...
hi. if i might add, while this is still the works,
1 - why not allow nested permissions ? i.e.: we could have a Catalog permission and permissions for each of the catalog entities/features. this would prevent accessing or displaying the catalog if a user is not allowed to without the need to go further and check for each entity/feature within the catalog.
2 - in multitenant systems, features can be set also by Tenant which is not present here. one should be able to allow access to a CRM feature for a tenant and desactive it for another ... (this should be thought out if you're planing on adding modules support , then features could be modules and access to modules can be through permissions, by tenant also).
1 - It is already working like that AFAICT. If you can't "View" the brands, then you will not have the menu item, so you definitely won't be able to create, update or delete them... What could be made better is that for instance when you uncheck the view permission for brand, that automatically the rest of the brand permissions are unchecked as well...
2 - We don't have the concept of "features" yet in this template, but that's something interesting to add indeed. I wouldn't mix it with permissions though. This is a different concept altogether.
@fretje thank you for your comments. what you said in point 1 is true but that let me give you a example : take the catalog. what if i had Permissions for Catalog and a set of permissions under catalog for brands, products, categories .... i would access them only if i had rights to the parent, in this case catalog. making this available can help setup roles permissions in a much logical way and codewise, a productcontroller would be secured by an Authorise attribute on Catalog first then the method by the product permissions for viewe, creste and delete .....
point 2, yes it is very different from the permissions. but if I had a feature Called Crm in which i manage a catalog and customers and billing , then i would need to have rights to that feature before managing those entities unfer CRM, hence the nested permissions ...
i hope this helps.
thx.
Well, yes, ultimately, the permissions are just strings... they have to start with "Permission" if you want to use them with the "MustHavePermission" attribute... but otherwise you are totally free to name them anything you want.