Skip to main content
OpenEyes provides a comprehensive settings system that allows administrators to customize behavior at multiple levels, from installation-wide defaults to user-specific preferences.

Settings Architecture

The settings system uses a hierarchical approach with multiple levels of specificity:
When retrieving a setting, the system checks each level in order (most specific first) until a value is found.

Settings Database Schema

The system uses 9 related tables:

Setting Metadata

Table: setting_metadata Defines available settings and their properties:
integer
Unique identifier
string
required
Unique setting key (used in code)
string
required
Display name for admin interface
integer
required
Type of input field (text, dropdown, checkbox, HTML, etc.)
text
Serialized data for field configuration (e.g., dropdown options)
text
required
Default value when no override exists
integer
Optional: Link to specific element type if setting is element-specific
text
Help text for administrators
integer
required
Setting group for organization in admin UI
string
Minimum level at which this setting can be overridden

Setting Instance Tables

Each level has its own table for storing setting values:
  • setting_installation - System-wide defaults
  • setting_institution - Institution-specific values
  • setting_site - Site-specific values
  • setting_specialty - Specialty-specific values
  • setting_subspecialty - Subspecialty-specific values
  • setting_institution_subspecialty - Institution + subspecialty combination
  • setting_firm - Firm/context-specific values
  • setting_user - User-specific values
All instance tables share this structure:

Accessing Settings

In PHP Code

Setting Context

The system automatically determines context from the current session: File: protected/models/SettingMetadata.php:219

Setting Field Types

Available Field Types

Table: setting_field_type
Simple text input field.

HTML Settings with Substitutions

HTML field types can include dynamic substitutions:

Available Substitutions

Session Substitutions (user/firm/site context):
  • [user_name] - Current user’s full name
  • [user_title] - User’s professional title
  • [firm_name] - Current firm name
  • [site_name] - Current site name
  • [site_address] - Site address
  • [site_phone] - Site phone number
  • [site_fax] - Site fax number
  • [site_email] - Site email
  • [current_date] - Today’s date
  • [primary_logo] - Institution primary logo
  • [secondary_logo] - Institution secondary logo
Patient Substitutions:
  • [patient_full_name]
  • [patient_first_name]
  • [patient_last_name]
  • [patient_date_of_birth]
  • [patient_gender]
  • [patient_nhs_num]
  • [patient_hos_num]
  • [patient_last_exam_date]

Using Substitutions

Substitutions are processed automatically by the parseSetting() method in SettingMetadata.php:384.

Managing Settings in Admin Interface

Accessing System Settings

Navigate to: Admin → System Settings Settings are organized into groups:
  • Core - Essential system settings
  • User Interface - Display and behavior settings
  • Clinical - Clinical workflow settings
  • Correspondence - Letter and document settings
  • Examination - Examination module settings
  • Module-specific - Settings for each active module

Setting Groups

Table: setting_group

Editing Settings

1

Select Setting Group

Choose the group containing the setting to edit
2

Choose Setting Level

Select whether to edit at:
  • Installation (system default)
  • Institution
  • Site
  • Subspecialty
  • etc.
3

Modify Value

Change the setting value using the appropriate input field
4

Save Changes

Click “Save” to apply the new value
Changing installation-level settings affects all institutions and users unless overridden at a more specific level.

Common System Settings

Core Settings

string
default:"Hospital Number"
Label for hospital number field
string
default:"NHS Number"
Label for NHS number field
boolean
default:"on"
Display version number in footer
string
Email address for helpdesk/support
string
Phone number for helpdesk/support

User Interface Settings

integer
default:"6"
Number of recent firms to show in context menu
integer
default:"30"
Default pagination size for lists
text
Configure which ID numbers to display in patient summary

Clinical Settings

integer
Default site for new events
boolean
Automatically generate event descriptions
string
default:"pdf"
Method for printing events: pdf or html

Correspondence Settings

string
Default sort order for correspondence list
string
Default address type for letters
Default letter footer content (supports substitutions)

Custom Text Settings

OpenEyes allows customizing display text for event types and element types:

Event Type Custom Text

Element Type Custom Text

Caching

The settings system implements aggressive caching for performance: File: protected/models/SettingMetadata.php:250-270

Cache Management

Settings are cached with a dependency on the last update time of setting tables. The cache automatically invalidates when settings are modified.

Creating New Settings

Via Database Migration

Via Admin SQL

API Reference

SettingMetadata Methods

File: protected/models/SettingMetadata.php
  • getSetting($key, $element_type, $return_object, $allowed_classes, $institution_id, $is_setting_page) - Retrieve setting value
  • getSettingName($key, $allowed_classes, $institution_id, $is_setting_page) - Get display name with data mapping
  • checkSetting($key, $value) - Check if setting has specific value
  • parseSetting($setting, $metadata) - Process setting value (apply substitutions, etc.)
  • performSubstitutions($html, $substitutions, $preserve_empty) - Apply substitutions to HTML
  • getSessionSubstitutions() - Get available session-based substitutions
  • getPatientSubstitutions($patient, $event) - Get patient-specific substitutions
  • resetCache() - Clear settings cache

AdminController Settings Methods

File: protected/controllers/AdminController.php
  • actionEditEventTypeCustomText() - Line 307
  • actionEditElementTypeCustomText() - Line 334

Best Practices

Use Appropriate Levels

Set settings at the most appropriate level for your use case

Document Custom Settings

Add clear descriptions to help future administrators

Test Before Production

Test setting changes in a development environment first

Version Control Migrations

Use database migrations for new settings in code