Click or drag to resize
Groups, Roles and Application Contexts

This topics explains the concepts behind roles, groups and application contexts in PACKflow.

You may refer to the Administration pages for practical information on how to manage groups in PACKflow.

This topic contains the following sections:

Overview

PACKflow uses different concepts listed below to manage users membership and permissions.

  • Modeling Role

    Roles are a permission modeling object used at application design time. They allow to template permissions within the modeled applications.

    When deploying an application, the modeled roles are translated into Group instances.

  • Group

    The group object allows to array principals at runtime. It may contain PFUser or other PFGroup instances.

  • Application Context

    Application contexts are runtime data partionning objects, allowing keeping data private for different entities using the same application.

Groups

Groups are runtime containers for other PACKflow groups or users.

When computing permissions, PACKflow RLS considers included groups have the same permissions as their parent *.

Note Note
* 'Parent' is used as a shortcut to say 'The group including the mentioned group'. There is no strict Parent notion in PACKflow. Groups can be included in several other groups, having multiple parents.

Each group has one of the following scopes:

  • Site

    Site groups are created runtime by the site administrators. They might be included in any other group, if not cycling. These groups can synchronize their membership on an Active Directory group.

    Application

    PACKflow engines instanciates application groups per application Context/Modeled Role combination. These application groups are used to define permissions on applications.

    Important note Important
    Application-scoped groups are called 'Roles' in the administrative GUI of PACKflow. This was decided to avoid confusion during runtime administration. In this document, we always use the word 'Role' to reference a modeling role, not a runtime group instance.

Comparation between group scopes

ScopeCreationInclusionAD SynchronizationUsage
Site Creation by members of SiteAdmins system group. May be included in any group. Can include any site group, if not cycling.Yes

Administrators create site groups and include users or other site groups.

This allows representing the users' organisation.

Application Creation by the engine during application deployment. Cannot be included in any group. Can include site groups.No Administrators include site groups and users under Application groups, to define permissions on applications.

Groups in PACKflow API

PACKflow groups are represented by the PFGroup class. Site groups are found in a relation under the current Site. Application groups are found in a relation under their parent PFApplication instance.

Application groups keep metadata about their source role and application context.

Roles App Ct PFGroup
Application Contexts

Application Contexts are data partitioning objects created by administrators at runtime. As an example, an application context could represent a physical location, a plant, a country, or any other entity, depending on your application needs. Using application contexts, these entities could use the same applications while keeping their functional data private.

Application Contexts and Item Creation

Every new PFItem needs to have an application context selected. Once selected, the engine uses the model to compute runtime permissions on the object.

Note Note

Most of the time, the context selection is automatically made by the engine, based on current user's membership or an eventual parent item.

The user is prompted to manually select the context in rare cases only.

If permissions were modeled using roles, the RLS system finds application groups matching the target modeled role in the current context to set permissions.

As an example, imagine that members of 'Admins' Role are enabled to delete an item, at modeling stage.

At runtime, an item is created with an application context named EU. The engine will then find the application group matching this role and app context to set the delete permissions on the item.

You may see this section for more details on how Roles, Groups and Contexts fit together.

Reference Groups

Application Contexts are created under each applications. Nevertheless, it is common that a functionnal data boundary makes sense for several applications.

A relevant example is using contexts for geographical areas. All geographical areas might use any of the applications in the site.

PACKflow allows to link related application contexts under different applications, using a Site Group as reference. This reference group is used by the engine to find a context matching the currently selected context for other applications.

In the example below, you can see two applications instances with two applications contexts under each.

The site group 'Europe' is used as reference Group to match the two 'EU' contexts under the applications. The end user sees a single entry named 'EU' when selecting contexts, which applies to both applications.

You can see an illustration in the example below. There are two applications and relative contexts, one coloured yellow, the other coloured green. Blue boxes represent Site-related objects.

Interaction between roles, application contexts and groups.

Let's take a simple example: An application is modeled with one content-type and three roles:

Roles App Ct Model

When deploying the application, the three roles are instanciated as application groups per application context. Creating a new application context automatically creates a new set of application groups.

In the object diagram below, you can see the objects created when deploying 'MyApplication'. The color convention is the same as above.

Roles App Ct Runtime

There are some notable points in the object diagram above.

  • The roles offspring app groups that are repeated for each application context present.
  • Site groups may be included in other site groups, as in application groups
  • Including users or groups into application groups from multiple app contexts allows multi-context operation.

    The group 'World Directors' is a good exemple, it is included in the Directors application group for both application contexts.

  • Site groups can be included in application groups from multiple applications.
See Also