Gentics Portal.Node PHP Guide

Chapters

1. Introduction

2. How are personalisation content attributes stored in Gentics Portal.Node PHP?

3. How the personalisation check is performed

4. Configuration of content attributes that should be checked

1 Introduction

Personalisation module is a tool that checks if current user (logged in or not) has access to see some content that is stored in the CMS.

Content personalisation can depend on any business rule. It can depend on any user parameter: age, gender, live place … It can also depend on special personalisation content attributes. These parameters can be set in the configuration file separately for each content source:

'sourceSettings' => array(
    'DynamicContentSource' => array(
        .
        .
        .
        'usePersonalisation' => true,
        'personalisationFields' => array('permissions')
    ),
    'FileSystemContentSource' => array(
        .
        .
        .
        'usePersonalisation' => true,
        'personalisationFields' => array('permissions')
    ),
),

2 How are personalisation content attributes stored in Gentics Portal.Node PHP?

Personalisation attributes for content are special attributes assigned in the CMS to any content. In most examples they are used as object properties (i.e. permissions) for folder, pages or binary files. The personalisation attributes are managed in the CMS and then published into the Content Repository where the portal can also read them.

To assign the personalisation attributes to portal users, the portal uses a separate storage of the personalisation attributes. Right now they are independent.

If you want to enhance the list of personalisation attributes, you have to update them in the CMS and in portal again. (table in portal responsible for the personalisation is called PersonalisationAttribute, they are stored in tree form).

They can be managed in user administration: /user/admin/managePersonalisation

Here you can assign personalisation attributes to portal users

To get user personalisation attributes in code / cms page, use this method:

    PersonalisationAttribute::flatListForUser($userId)

3 How the personalisation check is performed

There is a special class which requests the content personalisation attributes, userId and use some business rule to define whether the user is allowed to see the requested content or not.

More about it is here request lifecycle

You can overwrite this class in configuration. In case you need a different business rule for personalisation.

........
'personalisation' => array(
    'rule' => 'personalisation.components.BasicPersonalisationRule',
),
........

4 Configuration of content attributes that should be checked

To define which content attributes should be requested from API and then used in permission check, change following lines in configuration file:

'sourceSettings' => array(
    'DynamicContentSource' => array(
        .
        .
        .
        'usePersonalisation' => true,
        'personalisationFields' => array('permissions','age')
    ),
    'FileSystemContentSource' => array(
        .
        .
        .
        'usePersonalisation' => true,
        'personalisationFields' => array('permissions','age')
    ),
),