Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

This article describes the best way to control access to apps for end users.

Overview

For end users of a PhixFlow , it is best to control their access to their apps by:

...

application, we recommend that access to PhixFlow itself is restricted. You can ensure that users can only access applications as follows.

  • Create an App User role with the essential privileges (listed below).
  • Assign application users to the App User role. They will have no access to the repository lists of dashboards, views, streams or any other modelling

...

  • objects.
  • Configure a default dashboard to act as a landing page when user logs into PhixFlow that is, setting a default dashboard for their

...

  • User.
  • Ensure that all the navigation that they require is available in the application's menu options or Action buttons on dashboards.

Creating the App User Role 
Anchor
appuser
appuser

PhixFlow has a set of pre-configured user roles. However, there is no pre-configured role for an application user.

Application users only need a limited set of privileges to ensure that they can log into the PhixFlow applications that they need to use. Therefore we recommend that you create a specific App User role on your instance of PhixFlow.

  1. In the Full Repository, right-click Role and select 
    Insert excerpt
    _add
    _add
    nopaneltrue
    .
  2. In the role properties, set Basic Settings → Name to App User.
  3. In the Roles section toolbar, click 
    Insert excerpt
    _roles
    _roles
    nopaneltrue
     to open the list of roles.
  4. Drag in the following privileges:
    • Run Stream Actions
    • View Applications
    • View Dashboards
    • View Data
    • View Layout Components
    • View Styles
    • View Filters
    • View Menu Items
    • View Menus
    • View Streams
    • View Stream Actions
    • View Stream Views
    • View Styles
  5.  Click 
    Insert excerpt
    _finish
    _finish
    nopaneltrue
     to save and close the new role.
  6. Add the App User role to the user groups that need access to the application.

Planning User Access to Screens

Remember that when you design an application, you will have different types of user. For each type of user you must consider :

  • Consider all the dashboards that they need to be able to see

...

  • Determine the routes that that allow them to get to these dashboards from their landing page

...

With this in place, access to apps can be controlled as follows:

...

  • Add buttons to dashboards as needed to allow users to follow these routes
  • Leave access open to:
    • dashboards: Public ticked; All Users Can View Data ticked
    • streams: All Users Can View Data ticked
    • 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

 

...

  • Close access to actions: untick All Users Can Run Action

Restricting access to dashboards, streams and views can be useful when users can only navigate to the screens using action buttons. You can also control access to actions buttons (see below). If you limit access to dashboards, streams or stream views, to specific user groups, remember to add the required privileges to the user groups.

Note

This can easily become complex and hard to manage.

Controlling Access Using Action Buttons

  1. Create a set of user groups to represent all application user roles.
  2. To each user group add access to the actions buttons that the group of users need to access
    •  tasks
    •  other dashboards
  3. Only associate the privileges specifically for this role, not for this role and everything “underneath” it.
  4. At least one user group must contain the App User role.
  5. Layer the user groups onto the users so that they end up with the access they need.