Permanent history entry (PHE)

What is a PHE?

A Permanent History Entry (PHE) is an advanced mechanism used to restrict what users can see or do in an application, based on their login and defined access rights. It ensures that each user only accesses the data, menus, and features relevant to their profile (level or role).

Topics

Overview

How It Works – Conceptual Flow

When a user logs in, the system loads all PHEs associated with them and checks whether they are allowed to access specific menus or data. If access is granted, the user sees the content; otherwise, it remains invisible — they don’t even know it exists.

ephstructure

flowchart TD
    A[User Login] --> B[Load PHE List]
    B --> C[Check User Access]
    C --> D[Restrict Navigation Based on Menu Tree Access]

Impact

  • PHEs are enforced across all modules of the application.

  • A user may have different visibility in different modules depending on the assigned PHEs.

    • E.g., A hotel manager may have limited access in the Backoffice module but full access in the Operations module.

Use Case Examples

User Module PHE Applied Result
Hotel A Manager Hotel Management CODHOTEL = A Sees only Hotel A data and menusSees only Hotel A data and menus
Hotel B Manager Hotel Management CODHOTEL = B Sees only Hotel B data and menus
Admin Hotel Management (No PHE applied) Has access to everything (Hotel A, B, etc.)

Advantages of Using PHEs

🔐 Security: Users cannot see or detect content outside their scope. 🎯 Customization: Users with the same level or role can have different access levels. 🧱 Modular Flexibility: Apply different PHEs per module (e.g., backoffice vs. operations). ⚙️ Performance: Avoid loading irrelevant data for users. 📏 Scalability: Easily managed through levels/roles without custom code per user.

How to configure

Before configuring a PHE, you must understand what data you want to restrict (e.g., hotels, regions, departments).

💡 The PSW table is a system table used to store all users who have access to the application. It comes pre-configured in all Genio-based systems and does not need to be created manually.

  • Once you define the target entity (e.g., HOTEL), you must create an association table between that entity and the PSW system table.
  • For example, to associate users to hotels, you might create a table called RECEP (representing receptionists).

This table will determine which users can access which hotel records.

Step 1 – Create the Association Table (RECEP)

This N:N (many-to-many) table defines what data each user can access.

Example Table: RECEP

CODPSW CODHOTEL
001 HOTEL_A
002 HOTEL_B

pswhotel

Step 2 – Create the PHE in the Application

  1. Open the Access Rights -> PHE Menu in the module where you want to apply access control.
  2. Click "Insert button to insert a new PHE

eph2

  1. Fill in the required fields:
    • PHE Identifier: e.g., RECEPTION
    • Association Table: RECEP and the field to compare with the filter field
    • Filter Field: e.g., CODHOTEL
    • Operator:
      • The method to obtain the value from PHE is equal by default, this means that the system will limit the users that belong to that hotel.
      • However, you can choose other types of operators to apply to the PHE.
      • You can have more than one PHE. By default the operator between them is AND, however, you can tick the option OR.
      • The option “Propagate in-depth” allows you to propagate the PHE to all areas below the defined area, but this spends a lot of resources.

eph3

Step 3 – Assign the PHE to User Profiles

You can assign a PHE to Levels or Roles.

How:

  1. Navigate to: Access rights → Access Levels/Roles
  2. From the list, choose the Access to apply the PHE (e.g., Receptionist).

eph4

  1. Click the line for the selected level. In the details, you’ll see the modules linked to that access.
    • Click Edit for the module where you want to apply the PHE.
  2. In the module-level view, scroll to the EPH in use by the Module Access Level section.
    • Click Choose EPH.

eph5 eph6

  1. Choose the appropriate PHE (e.g., RECEPTION) and click save.

eph7

Once assigned, the PHE becomes active for users with that access level in the given module. Their access is now filtered according to the RECEP table.

Test Access

Checklist Before Testing

  1. Create the Join Table Form (RECEP)
    • Make sure the form for the association table (RECEP) exists.
    • Use it in the menu or as a table list inside the hotel to manage relations between users and hotels.
  2. Create a Test User in WebAdmin
    • Go to the WebAdmin interface and create a new user.
    • Assign the user the "Receptionist" access level or role, and ensure the appropriate PHE is applied.
  3. Insert Data and Define Relationships on the application. NOTE: Use a login without PHE applied!
    • In the application, insert hotel records.
    • Define the relationship between each receptionist and their hotel by filling the RECEP join table.
  4. Login as the Receptionist
    • Once the configuration is complete, log in with the test user.
    • The PHE will be applied automatically at login.
    • The user will only see menus and data related to their hotel — nothing else will be visible.

Additional Notes

  • PHEs are evaluated at login time.

  • You can apply multiple PHEs using AND (default) or OR logic.

  • The "Propagate in depth" option allows filtering down the entire navigation tree but may impact performance.

  • Users with no PHE applied (e.g., Admins) will have full visibility.