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

Overview

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.

where 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 configure 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:

These users can be used with a role assigned, or can simply be used to grant access where a user is part of a group. For example, a user will need to be in the appname group in order to access the application and in the user group to have adequate privileges to undertake any activity. The appname_Admin, can then be assigned to specific objects and a user must be a part of this group to see/interact with them. For example, an admin options button can be set for appname_Admin use and only users in this group will see it.  

For applications created in versions earlier than 9.0, you must create these user groups. 

Configuring Application User Privileges 

Anchor
appuser appuser

You must configure roles for:

General Application Users require the following privileges as a minimum:

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

These can be set up in a bespoke role depending on your requirements, or alternatively, use the prebuilt User role.

Application Administrators, requirements will depend on your own requirements. For example, these might be users who can see everything, including all data and perform any interaction. Alternatively, their role may be administrative only and they cannot see the data in an application.

Roles can be Configured

If none of the preconfigured roles suit your requirements, you can configure a role by either:

• create one in the Full Repository, if you want all applications to make use of the same role
• or in the application-specific repository, create one within an application, 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 click 

   Insert excerpt
   _newaddIcon _newaddIcon nopanel true

   .
2. In the role properties, set Basic Settings → Name. For example:
   • for application users: AppUser
   • for application managers: AppAdmin
3. In the Roles section toolbar, click 

   Insert excerpt
   _roles _roles nopanel true

    to open the list of roles.
4. Drag in the privileges for the role.
5.  Click Click 

   Insert excerpt
   _finish _finish nopanel true

    to save and close the new role.

If 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 a 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 nopanel true

      to open a list.
   • For roles created in the Full Repository, open the repository in a pane 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,  click 

   Insert excerpt
   _user _user nopanel true

    to open a list.
5. Drag users from the list into the Users section.

Restricting Access

Any application user can access all data and actions , unless you specifically configure restrictions.

For the following items, their properties include options that are ticked by default.

• screens:
  • Public
  • All Users Can View Data
• tables: All Users Can View Data
• views: All Users Can View Data
• actionsConfiguring Actions: All Users Can Run ActionActions

For greater control over access to parts of your application, you can consider restricting access.

1. For the item you want to restrict, untick All Users Can...
   For screens, also untick Public.
2. PhixFlow displays properties to which you can add specific user groups.

Restricting access is most useful for where you want specific people:

• to perform key actions, such as approval or deletion.
• to access parts of your application.

In this case, you apply the restriction to actions on a button. The following section explains how configure user groups and privileges to create more complex access options.

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 screens
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 AppUser role.
5. Layer the user groups onto the users so that they end up with the access they need.