user-roles.test.js

Overview

This Jest test suite validates the roles functionality across all entities defined in each API’s metadata-cache.json. It ensures that role-based permissions are correctly enforced by creating users, assigning roles with specific endpoint access rights, testing allowed/forbidden operations, then cleaning up after tests.

The user-roles system grants or denies permission to endpoints based on:

• The user’s assigned roles (e.g., ROLE_MOD_KEYVALUE_SHOW, ROLE_USER_CREATE)
• Whether the role has explicit enable/disable permissions for specific entities and methods (_show, _add, _edit, etc.)

Test Scope

For every entity in each API’s metadata cache, the suite:

1. Creates a test user before running access tests for that entity
2. Assigns specific roles to control which operations are allowed (e.g., ROLE_MOD_KEYVALUE_ADD enables _add)
3. Tests each role’s permission on GET, POST, PUT, DELETE methods against the metadata-endpoint map
4. Deletes the test user after all access checks for that entity

Test source

The user-roles endpoints and their associated roles are extracted from:

• Each API’s metadata-cache.json which defines supported entities

These tests ensure permission matrices remain valid when new entities or endpoint definitions change. Snapshots verify consistent error responses for unauthorized access attempts.

Key Functionalities Tested

1. User Setup

• Runs before all entity-specific test blocks to create a fresh user via the account API’s /open-api/v3/users/set or POST login mechanism
• Uses default username/password combination stored in environment variables
• Stores retrieved JWT token for subsequent requests with elevated role access
• Assigns roles such as:
  • ROLE_MOD_KEYVALUE_LISTING → Allows GET listing
  • ROLE_MOD_KEYVALUE_ADD → Allows POST/CREATE operations

2. Access Verification per Role

For each tested entity, tests the role permissions by making requests to:

• GET /open-api/v3/{entityName} (listing) — when _show_end_point_listing_access_get_enabled = true
• POST /open-api/v3/{entityName} (create) — requires add-permission roles, blocked otherwise
• PUT /open-api/v3/{entityName}/{id} (update/edit) — edit permission required by role metadata

3. Endpoint Mapping per Role Category

Each entity maps to endpoints based on its CRUD:

4. Permission Enable/Disable Testing

For each role and entity, tests:

• Enable permissions: Requests succeed when the metadata indicates {roleId}._add_end_point_{action}_enabled = true in role for that API’s endpoint list
• Disable permissions: Unauthorized responses (EACCES, 403) expected when disabled by default roles

5. Role Metadata Validation

After creating users and assigning roles, tests verify:

• The role metadata returned from /open-api/v3/metadata/entity/{entityName} reflects status changes made via user operations
• Expected entity fields (id, slug, etc.) appear in responses based on the enabled/disabled flag state for each operation

6. Cleanup

Runs after all tests to:

• Remove created test users from database to prevent cross-test interference
• Ensure no lingering permission modifications persist between test runs

Notes on Metadata Integration

• Tests dynamically build endpoint paths based on the API’s configured base URL and the role-permission mappings within that metadata file.

Notes on Cleanup

Tests create users and assign roles temporarily before deletion after all permission checks. This ensures:

• No test pollution from previous runs (e.g., leftover data affecting state tracking)
• Database remains in initial state between test cycles