Using the Configuration Service

The CloudApp API includes a Configuration Service, which allows your app to save configuration for your application to the platform. The Configuration Service is very similar to the Setting Service, but configuration is institution wide and can be used to store data such as service endpoints, usernames for external services, etc. Any data which can be serialized in JSON can be saved.

This tutorial is almost identical to the tutorial on “Using the Settings Service.”, so we’ll focus only on the differences. We’ll add a link to the configuration screen via the manifest file, and we’ll also add an Angular guard to control who can access the configuration page.

Follow the instructions in the “Adding additional routes” tutorial to add a new component and route called “configuration”. The functionality of the component is a simple form with one field and a save button. The save button calls the set method of the config service.

Configuration Link

Similar to settings, we can add a link to the configuration screen in the app’s menu. The link is only displayed if the logged-in user has General Administrator privileges within Alma. To add the configuration link, specify the route to your configuration form within your app’s manifest.json:

"pages": {
  "config": "/#/config"
},

Note the format of the link- preceded by a “/#/”, which is needed for Angular to route to your configuration page.

Now a configuration icon appears in the menu next to your app’s name:

Limiting access

We can also provide a link to the configuration page within our app if we don’t want to rely on the icon in the app menu. For example, we may wish to have different criteria for who is allowed to access the configuration screen. To accomplish this, we can use an Angular routing guard. We add a class which implements the CanActivate interface and inject the Events Service and the Rest service in the constructor. In the canActivate method, we call the getInitData method of the Events Service to retrieve the user’s primary ID, and then we call the user API to retrieve all of the data about the user. We then check to see if the user has a particular role, in our example the “Circulation Desk Manager” role. If the user has the role, we return true. Otherwise, we return false and navigate back to a component with a static error message.

In order to attach our guard class to the configuration route, we include the canActivate property in the route configuration in the app-routing.module.ts file:

{ path: 'configuration', component: ConfigurationComponent, canActivate: [ConfigurationGuard] },

Now if an unauthorized user tries to navigate to the configuration screen, they will receive an unauthorized message.