Determining User Roles on the UI

#1

I’m curious to know how people are checking the user roles for UI purposes.

My data is locked down using CLPs and ACLs with a hierarchy of roles. I’ve gone a bit overboard 1.51k roles later…

I know from a database point of view that data will not be loaded / be able to be saved, but how do you guys convey that to the user? There is no point showing an editable view if when they save the form, a permissions error is thrown.

It would be great if when we read an object from the store, a key is added to denote whether the currently logged in user has write access.

Secondly, how do you check when the user doesn’t have read access, are you making the request anyway, and checking that the data returned was null? How does this work when you’ve got sections of your app dedicated to certain users, like admins for example?

Thanks for your help.
W

#2

When I had this issue I used two different approaches, both not ideal.

In some cases (when doing queries only) I can deduce from an empty result that the user is not eligible to do that operation – e.g. after logging in to an admin page, the app queries for administered organizations, and if none are found the user is considered not to be an admin.

In more complex cases, i.e. when using roles, I store all role memberships in a separate per-user object to allow quick lookup, and give this data to the client to use it for permission-based logic. I use a helper function for changing role memberships which adds/removes users to/from a role and also updates the role lookup accordingly.

However, after doing things like that for about 3 years, the bottomline for me is that I try to leave roles and ACLs out of the game and do my own permission management, because the built-in stuff has limitations in complex scenarios with overlapping permissions.