PhixFlow Help

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

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

Overview

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

  • Giving users the App User role - that means that they have no access to the lists of dashboards, views, streams or any other modelling components in the Repository Browser
  • Giving them a "landing page" - that is, setting a default dashboard for their User
  • All navigation from that point being only by pressing Action buttons on dashboards.

Considerations for app building

This means that while building the an app, 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 in some cases, but when putting apps together with the method described in this article it is not required, since end users are not able to navigate to these except via action buttons, and their access to actions buttons 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.

Controlling access via action buttons

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

  1. Build up a series of user groups that represent roles
  2. To each user group add access to the actions buttons that give access to the tasks and routes to other dashboards required by this role – only associate the privileges specifically for this role, not for this role and everything “underneath” it
  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. Layer the user groups onto the users so that they end up with the access they need


  • No labels