Admin Settings

Overview

An admin user can configure different system settings that control behavior like the connection to an SMTP server or what users are allowed to create accounts on the system. These settings will be persisted in the database and used by the services that need to access configuration data.

Service Interface

The service interface for getting and setting the settings models each of the settings as a POJO in order to provide a strongly typed interface with both client and server side validation of the settings. The service provides basic CRUD calls with resource paths that signify the settings that the user is changing.

Resource	Description
/settings/email/config	Configuration of the SMTP host/port, username, password, and from address for all emails sent from the system
/settings/email/filter	The regular expression filter used during the account creation process to limit sign up to users with emails that satisfy this expression

See the REST documentation for sample payloads. Each of the services will have a reasonable default behavior, although the EmailConfig bean is not configured with a password by default.

All access to the this interface requires a security context to have been established and the user to have the proper permissions. See below for a read-only variant that is provided internally for services.

Read Only Settings

Services that require access to the settings can do so through an internally visible read-only service that is not exposed as a REST endpoint and therefore does not require authentication/authorization. This enables services like the CreateAccountService to access system settings for users that have yet to establish an authentication context.

Storage Layer

As with the other services, there is a storage interface that abstracts the persistence details away from the service. This interface provides basic calls for loading and storing the config items. The services do not make any attempt at caching their setting data and should instead fetch it on demand from the storage layer when needed. Caching or some signal to trigger a refresh could be added later if needed.

JPA Implementation

The current default implementation is through JPA and the AdminSetting entity. This is a simple name/value pair setup where the name is a unique identifier for the setting data and the value is a JSON payload for the config that is marshalled/unmarshalled from the POJO that models the config data. In a nutshell, we're storing the JSON for the config bean as a string in a CLOB. The thinking here is that it's unlikely that we'll ever need to run reports on this config data so it's fine to store the data in JSON within the db.

Adding a new setting involves the following:

• model the setting as a simple POJO
• add annotations to support reading/writing to JSON
• add getter/setter for the setting to the AppSettingsService with the appropriate security annotations
• added getter for the setting to the ReadOnlySettings if this config ever needs to be accessed w/o a security context

Note in the above steps that you do not need to modify the storage layer interface or implementation in these steps. This is because of the convention of using the POJO's class's 'Simple Name' as its key for the AppSetting entity. As long as the class names are unique then the persistence layer doesn't need modification.

The interface for the AppSettingStorage uses generics to load/store the settings so no changes are needed to this interface to support new settings.

public interface AppSettingsStorage {
    <T> T load(Class<T> setting);
    <T> void store(Class<T> setting, T t) throws IOException;
}