The Perfion security model allows you to define user rights in almost any way imaginable. Today we explain the components of the security model and show you examples of some common configurations.

Security Model Components

User rights in Perfion can be defined at multiple levels. Each level provides options for increased granularity.

Users and Groups

At the bottom of the security model is the setup of users and groups:

Open

The user Administrator is a native Perfion user. It has full rights in the system and can’t be deleted. All other users are created manually.

Each user has to be a member of one or more groups. The following groups are available:

Security on Main Buttons

The first level of the security model is related to the main buttons:

Open

Access to Features and Feature Data is restricted to members of Administrators and Super Users. Administrator can access both while Super Users may only access Feature Data. Other users cannot be granted access to these areas.

All other buttons are configured via the Section designer, and this is also where access to each button is defined. The set permissions on a button, find the appropriate (blue) entry in the Section-Designer, right-click and pick the “Security…”-menu. In this example, the Marketing group has been granted access to the Products button:

Security on Items and Values

The second level of the security model is related to items and values. In order to understand this part of the security model, it is important to understand the difference between these two entities.

In Perfion, items are really just the entities contained by a selectable feature. The easiest way to visualize this is to go to Feature Data and click on any feature. All related entities on the right are items. This could be all products in your system, but it could also be all colors as illustrated here:

Values are the data, you specify on an item.  The easiest way to visualize this is to open an item.

All the fields on the form containing data are values. So you can think of an item as a container to hold the values.

Since an item by itself is simply a container without values, all items are born with a base value to make sure at least one displayable value exist on an item. On the below form, the base value is found in the top panel, next to the Product label:

With these concepts in mind, we can now look at security on items and values.

In Perfion 3.5 security on items and values were controlled via Tabs. All features on a tab had to have the same security model which forced you to group features according to security rights. This has become much more flexible in Perfion 4.5. In this version you can control security on each feature independently of the tab it is on.

First step is to select a Security group for a feature. This is done in the dropdown called Security Group on the Feature Definition dialogue. In this example, we have specified that security on Color is defined by the security group Marketing:

Second step is to define the user rights associated with the security group Marketing. This is done in Information Groups found in the Administration menu:

In this example we have granted members of the Marketing user group full rights both to Items and Feature values. Members of the Users group have only been granted read rights to items and feature values.

Now what are the end-results of this setup? Three things. Think again on the definition of items and values and think of Color as an example:

1. Members of the Marketing user group will be able to create/edit/delete items on the Color-list. In essence, they can delete the color Red from the list and create a new color Purple.

2. Members of the Marketing user group will be able to edit color values on products. In essence, they can decide that Product A is Blue and Product B is Purple.

3. Members of the Users group will be able to see the list of available colors (items) and also see which color is set for each product (values). They will not be able to edit the color-list or change color values on products.

Feature Item Security

The third level of the security model is called Feature Item Security. With this concept, you are able to give or restrict access to items that have specific values on a feature. This may seem complex to understand, but think of Category as an example. You may want to give certain users edit-rights to products in the Cups-category and give other users edit-rights to products in the Pots and pans-category. This can be set up like this:

First you go to the feature definition of Category. On the Advanced tab, you set Feature Item Security to Give Access:

Secondly, you give access to individual categories for selected user groups. This is done by right-clicking a Category and choosing Permissions:

Notice that rights can be set at two different levels here: Item and RelatedItem:

• Item refers to the item Cups itself. In our example, members of the Marketing user group are not allowed to change this item, and they are not allowed to change values on this item either. The last part is only relevant if the Category-feature is set up with a configuration.

• RelatedItem refers to items that have the value Cups in the Category-feature (i.e. products shown in the right-hand window above). In our example, members of the Marketing user group have been given rights to create/edit/delete items in this category, and they have also been given rights to manage values on items in this category.

Security on Language

The last level of security is related to languages. With this level it is possible to define if a user is allowed to manage data for a specific language.

Language security is defined at user level. It is simply a matter of granting edit-rights to individual languages:

In this example, EN-ES translator is a Spanish translator. He is allowed to manage Spanish values and not English.

Notice that these settings only relate to localizable features. The translator will still be able to manage all non-localized features. If you don’t want him/her (and other translators) to manage non-localized features, you should do the following:

1. Restrict language access for all translators as described

2. Create a user group called Translators and make all translators a member of this group

3. Give translators edit-rights to values on localized features (via the relevant security groups) but not to values on non-localized features.