Page Comparison

...

1. Build up a series of user groups that represent roles – only associate the privileges specifically for this role, not for this role and everything “underneath” it
2. Layer the user groups onto the users so that they end up with the access they need
3. At least one user group must contain the role App User - for clarity, it is best if the App User is only in one of the user groups added for users (commonly via an "App User" user group)
4. Leave access open to:
   1. dashboards: Public ticked; All Users Can View Data ticked
   2. streams: All Users Can View Data ticked
   3. views: All Users Can View Data ticked

This means that each user group has only at most a single dashboard (it could be more, but in general it won’t be); and a number of actions associated with it. Under this scheme you don’t need to worry about the “Allow All users to View Data” setting on streams.

-          No dashboard access is required

-          Role (App User) is required in one of the user groups

On dashboards and streams leave “Allow …” ticked, and make dashboards public

See article on setting up App User

This works because with this role users can browse to other dashboards; it might not be the strongest security model in the world, but it a good compromise and it’s really about helping users find their way through the application by not giving them too many optionsRestricting access to dashboards, streams and views can be useful in some cases, but when putting apps together with this method it is not required since end users are not able to navigate to these except via action buttons, and their access to these is controlled; if you restrict access to these components you will need to add these privileges to the relevant user groups, and this can easily become complex and hard to manage.