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 defaultssetting_institution- Institution-specific valuessetting_site- Site-specific valuessetting_specialty- Specialty-specific valuessetting_subspecialty- Subspecialty-specific valuessetting_institution_subspecialty- Institution + subspecialty combinationsetting_firm- Firm/context-specific valuessetting_user- User-specific values
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
- Text
- Textarea
- Checkbox
- Dropdown
- Radio
- HTML
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_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
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 htmlCorrespondence 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 valuegetSettingName($key, $allowed_classes, $institution_id, $is_setting_page)- Get display name with data mappingcheckSetting($key, $value)- Check if setting has specific valueparseSetting($setting, $metadata)- Process setting value (apply substitutions, etc.)performSubstitutions($html, $substitutions, $preserve_empty)- Apply substitutions to HTMLgetSessionSubstitutions()- Get available session-based substitutionsgetPatientSubstitutions($patient, $event)- Get patient-specific substitutionsresetCache()- Clear settings cache
AdminController Settings Methods
File:protected/controllers/AdminController.php
actionEditEventTypeCustomText()- Line 307actionEditElementTypeCustomText()- 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