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.