Versions Compared

Key

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

Insert excerpt
_Banners
_Banners
nameapp
nopaneltrue

This page is for application designers who need to specify which users can access an application.

Overview

For end users of a PhixFlow 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  Anchorappuserappuser

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.

In the Full Repository, right-click 

Once an application is complete and ready for use, you need to configure the privileges that the application users require. To learn more about users, user groups, roles and privileges, see Managing User Groups and Privileges.

From version 9.0 onwards, PhixFlow automatically creates 2 user groups for applications:

  • appname for people who need to use the application
  • appname_Admin for people who need to manage the application and user access to it.

appname is the same as the application's name. For applications created in versions earlier than 9.0, you must create these user groups. 

Use the application user groups to set up user access to your application before making it available; see Configuring Application User Privileges, below.

Planning User Access to Application Screens

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

  • Consider all the screens that they need to access.
  • Decide if they start on the application's home screen, or if they need a different landing screen.
    • You may want a subset of users to open your application on a specific screen (not the application's home screen). For example the application manager may need access to task-specific options. 
  • Determine the routes that that allow them to get to screens from their landing page.
  • Add navigation menus and buttons so that users can follow these routes.
  • In the properties for items, leave access open to:
    • screens: Public ticked; All Users Can View Data ticked
    • tables: All Users Can View Data ticked
    • views: All Users Can View Data ticked.
  • Close access to actions: untick All Users Can Run Action.

For greater control over access to parts of your application, you can consider restricting access to screens, data tables and views. You must then add the specific user groups  to each item. This can be useful if you want application users to navigate to the screens only using action buttons. You can also control access to actions buttons; see Controlling Access Using Action Buttons below.

Note

We do not recommend restricting access to screens, tables views and actions, as providing user access per item becomes complex and hard to manage.

Configuring Application User Privileges 
Anchor
appuser
appuser

You must configure roles for:

  • application users with the following privileges
    • Run Actions
    • View Applications
    • View Dashboards
    • View Data
    • View Components
    • View Styles
    • View Filters
    • View Menu Items
    • View Menus
    • View Streams
    • View Stream Actions
    • View Stream Views
    • View Styles
  • application managers, with the privileges they require.

You can configure the roles:

  • either in the Full Repository, if you want all applications to use the same role
  • or in the application-specific repository, if you want to create a separate role for each application.

Step 1  Configure Roles and Privileges 

  1. In either the Full Repository, or the application-specific repository, right-click Role and select 
    Insert excerpt
    _new
    _new
    nopaneltrue
    .
  2. In the role properties, set Basic Settings → Name to App User.. For example:
    • for application users: AppUser
    • for application managers: AppAdmin
  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 Components
    • View Styles
    • View Filters
    • View Menu Items
    • View Menus
    • View Streams
    • View Stream Actions
    • View Stream Views
    • View Styles
    privileges for the role.
  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. Todo-Fiona  confirm if this is now automatically added to the App Name user group that gets auto-created.

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 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
  • 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
  • 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

Todo-Fiona Example and improve point 3If you configure the roles in the Full Repository, you only need to do this once.

Step 2  Configure Users

If PhixFlow does not already have user accounts for your application users, ask your administrator to add them; see User

Optionally Set Defaults

If a user only requires access to one application, configure Basic Settings → Default Application; see User

If  user requires a task-specific landing screen, configure Basic Settings → Default Dashboard.

Step 3  Configure User Groups in the Application

  1. In the application-specific repository, expand User Groups and open the application's user group. 
  2. Find the AppUser or AppAdmin role:
    • For roles created within the application, in the Roles section toolbar click  
      Insert excerpt
      _roles
      _roles
      nopaneltrue
       to open a list.
    • For roles created in the Full Repository, open the repository in a panel next to the user group properties and navigate to the role.
  3. Drag the role from the list/repository into the Role section.
  4. In the Users section of the user group properties, 
    Insert excerpt
    _user
    _user
    nopaneltrue
     to open a list.
  5. Drag users from the list into the Users section.

Controlling Access Using Action Buttons 
Anchor
buttons
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 AppUser role.
  5. Layer the user groups onto the users so that they end up with the access they need.