Component level access control based on roles

[mike12345567]

Currently the builder has the ability to control access to screens (and therefore layouts) via a role hierarchy. Each user has a specific role level and they will have access to a set of screens based on this, e.g. a basic user can see all basic and public screens while a power user can see power, basic and public screens and so on. There are some extensions we think could be made to this which will simplify creating apps with lots of different user levels.

One of the major problems the current system faces is that if you want to have save a different nav bar for each role level you need to create a different layout for each role level and then pick the correct one based on the logged in user level - this is confusing and difficult to achieve. Instead it would be better if the links in the nav bar itself were controlled by role as well, so the links to the screens a user has access to it will only appear and any link they do not have access to with not be shown. To do this we need role control for components.

Me and @aptkingston had some ideas around this and I wanted to put them up here for discussion.

This is an extension of the existing system for roles that manages screens to allow children of screens and layouts to be managed with a role as well.

There are a few parts to this that are required for it to work correctly.

1. The option to control a screen/component with a role should have a choice, either to allow roles that inherit the selected role to view it as well or to set it so that only a particular role can actually view the component. Only allowing one role to view a component could be useful for something like a welcome message, e.g. "Welcome to the Admin interface" or "Click here to do power user thing" which may not be applicable to a role with a higher level role, giving the user the option to select the method by which the component can be viewed will give the user both options. By default all components should default to the hierarchy method and then the user can disable this with a checkbox is required, something like "allow/dis-allow roles that inherit access"

2. The API needs to be extended to strip out components from client definition and builder definition calls, as well as doing this on layout and screen get calls. Currently this is done on all the calls that manage screens, layouts are not currently covered by roles in anyway as they are linked to my a screen so they implicitly gain a role level through the screens that link to them. When retrieving these definitions the server should iterate through all the children and strip out any definitions which are not viewable based on a specified role level. In the client definition call this will be the role of the user that is currently logged in.

3. The builder definition calls should do something similar to what point 2 suggests, but instead of stripping out the children/screens it should add a prop like visible: true|false to each screen/component so that the preview can be rendered by stripping out the invisible components and screens. The role used to decide this should be passed in as a parameter to the fetch API.

4. Continuing from the previous point, the visibility is necessary so that in the component tree we can show all the components that are on a screen but say whether they are visible or not for the current role. This removes the confusion of the tree components changing drastically each time the role is changed, instead some will simply be greyed out or marked invisible. We don't need to state why they are invisible, simply that the current role does not have the ability to view them.

5. Ideally all role logic should be maintained within the server and keep this out of the builder or client library, as this is the most secure method making sure a user never has access to content that their role does not allow them to view.

6. Each time the role is changed in the builder UI the API call would be made with the new role for the server to fetch the definition and work out what components should be viewable and which ones shouldn't be. If required we can do something around caching in this area to speed up the responsiveness of these calls for large screens.

7. Auto-links will likely require some updates for this to be really useful, the ideas around this would be that when autolinks are being filled out we attach the same role levels to the link itself based on the screens levels, take the list of screens on a route and select the lowest access level, use this for the nav link. When deleting a screen we need to check if any screens still exist on the route and if they do not delete the link (this is a QoL feature but want to document it here too).

[aptkingston]

Super write up actually, I think you covered pretty much all the points we discussed. This per-component system solves all the following use cases (and lots of others) without any duplication of screens:

• I want an extra link in the nav bar if the user is an admin
• I only want users to only see links to pages that they can access
• I want a totally different nav bar if the user is an admin
• I want to have 2 graphs if the user is an admin, and 1 graph if the user is a standard user
• I want totally different home screens for different roles
• I want nearly identical home screens for different roles, with a couple of additional items, but I don't want to have to duplicate screens
• I want a unique content box on the page that's specific to each role, and only that role
• I want to hide certain content, but not all content, if the user hasn't logged in yet
• I want to show an admin control bar on all pages if the user is an admin

Basically I think this is a well thought out method that will solve every use case I can think of, without duplication. As described roughly above, I have ideas for how to make the UI for this as simple as possible as I think it's very important to get right. I'll talk through more of the UI ideas in the review meeting this Friday.

[mjashanks]

I like that we can cover these use cases, and trust that you can do it in a user-friendly manner. I do have a few points.

1. We should consider how this will affect a general conditional UI solution. For example, if Status = 'New' then display = none, and if DueDate > Today then color = "red" - we should ask ourselves "is this conditional role stuff special - aside from conditional UI ?"
2. I find the hierarchal access level thing quite confusing. Do roles always have to be in a hierarchy? e.g.

	Create Invoices	Create Payments	View Customer	Create Customers	Create Leads
Finance User	YES	YES	YES	NO	NO
Sales User	NO	NO	YES	YES	YES

Who's level is "higher" here?

3. The key to all of this is that everything is simple by default. If I don't care about Roles, I don't want it to pollute the building experience

[mike12345567]

It is a great point that conditional UI might work around this, however it may be possible to build this in a way that we can extend the role system onto become a conditional system. The other point however is that we probably need to do something about this for roles to be really useful and if we have to wait until we build out a whole conditional UI system roles may just not be useful - it does highlight though that putting some thought into the design of the conditional UI right now and putting some requirements into it might help us decide the direction to go.

I agree that hierarchies can be confusing, but I think it is a requirement since I can't really imagine a security system were everytime you define something is accessible by a basic user you also have to list all the roles that are higher than it, I think that could lead to bugs/further confusion when building. However in this design we think that it is necessary for there to be an option to disable the hierarchy feature and limit access to a single role - it depends on what you're trying to build, really there are two ways to think about it:

1. The hierarchy is very useful for say building a screen for three types of users, one that gets basic information, one that gets a deep analysis view and one that can administrate some of it, the screen and basic info would be viewable by everyone above basic, the deep analysis would be viewable by a power user role and above and then some editing components would only be viewable by an admin role. Without hierarchies you would need to add a list to each of these components to say basic, power and admin and so on, this will inevitably lead to mistakes and confusion.
2. Your specific example would be better in the case of a single role can access this screen, e.g. a screen for creating invoices and a screen for creating payments are only accessible by a finance role and so on, that example fits better with hierarchy disabled.

The last one is a difficult point in that right now by default we do have a couple of roles which may add confusion. It might be an improvement to remove some of the roles that are built in, only have public and basic for the time being or something like that, which would essentially be what we had before in the public and private options. I think it'll be a little difficult to totally escape the role system as its very hard to build a web app that you can log into without considering what the logged in user is capable of doing/seeing, but we could probably reduce the complexity of it when you load a new app, making sure that the user has the ability to expand upon what is there if needs be.

[mike12345567]

Forgot to add one thing!

One other thing to think about is the ability to create hierarchies is the ability to copy the logic of a company, for example if we take say a factory thats building a production monitoring app we might have:

• worker
• factory manager
• district manager
  This is an obvious hierarchy that could exist in the wild and there will be some things that each level should be able to see and some things a person at a particular level should only be able to see, for example total output might be of interest to everyone, but only a factory manager can see per line outputs (a district manager might not care about this granularity).

In this example it'd be nice to have a mixture of the two and use them as and where it makes sense, I think as long as we make it obvious how to turn on and off this feature people adept in the tool should be able to make great use of it!

[dw-bayer]

Would love to be able to have Layouts have conditional Links based on Role.

[mjashanks]

You can do this right now. Goto layout, and choose the layout that you want to change - probably "Navigation Layout"

1. Click on "Configure Condition"
2. Choose Update Setting > Links
3. Click Configure links to choose the links for the role that you wish to change
4. For the condition do: IF {{ Current User.roleId }} Equals Binding 'admin' - this will configure the 'Admin' role.

If you have a custom role - ask me how to get its _id as I've just realised that we don't display it anywhere!
If you

[shibasis3k]

THIS binding actually working for the default roles, but if I want to add binding with a custom role, then what to put in the Binding box?

[tglynx]

I am here for the same question! How to get the role_id of custom roles? Please also note #11038

[tglynx]

Answer: The RoleID of a custom role can be seen in Design Mode on the Data tab in the Users table in the Role Column of a user that has this role assigned. Alternatively a Screen can be created with a Headline (as an example) component having a binding of {{ Current User.roleId }} and viewing this Screen as a user having this role assigned.