Our previous article covered the basics of our platform’s add-on. If you haven’t read it, check out the Developing Custom Solutions With eLabNext Add-ons. In this follow-up piece, we will dive into the add-on configuration and setup process. We’ll start from the beginning and guide you through each step, focusing on the essential details you need to know.
Configuration is an essential feature of an add-on provided by the eLabNext SDK for customizing add-on behavior for different users or organizations.
Here are a couple of good examples of when configuration can be used։
If you have created an add-on for switching between metric and imperial measurement units, configuration would be a good place to allow users to switch between units and store the choice.
If you have created an add-on that integrates your eLabNext dashboard with 3rd party software such as Jira, the integration details should be stored in the configuration.
As you can see, configuration can be used as user preferences or system configuration.
eLabNext SDK defines add-on configuration using two properties.
needsConfiguration: This boolean attribute serves as a flag indicating whether your plugin requires configuration or not. When set to true after the installation, the dashboard will inform users that they need to configure the add-on after the installation. Otherwise, it might function differently than intended. For example, an add-on for switching between metric and imperial measurement units will probably need a configuration set to false, as it may have some measurement unit set as the default. Opposite to it, the Jira integration plugin should inform the user about the required configuration by setting needsConfiguration to true.
configurationSchema: Allows developers to define the JSON schema of the add-on configuration by providing the type, title, and default value. ConfigurationSchema fully supports https://json-schema.org/specification versions 3 and 4 of the JSON Schema core and validation specifications․
To understand the configuration better, we must first understand how the add-ons are installed. Add-ons can be installed for the following three scopes. Before talking about the installation scope, it is essential to mention that it is set by add-on developers while publishing add-ons to the marketplace. Once the add-on has been published, the scope of the add-on cannot be changed. Users installing the add-ons cannot change the installation scope; as mentioned above, the add-on can only have a single scope. It is set while publishing the add-on, and after that, it cannot be changed by developers or users.
User – An installed add-on will be available only to the user who has installed the add-on.
Group – An installed add-on will become available for all group members. Sufficient permissions will be required to install an add-on for the group.
System – An installed add-on will become available for all the organization’s members. Sufficient permissions will be required to install an add-on for the entire organization.
Again, there are multiple cases when you might want to select a certain scope. An add-on that adds an electronic signature to all PDF files to verify them should probably be installed on a system level, accessible to all users. An add-on that allows users to change theme colors can probably be installed using the user’s scope.
The add-ons can be configured manually from the add-on settings. If you need to update configurations programmatically, you can utilize the eLab SDK to call the corresponding API method.
You’ve probably already noticed that we should provide the scope while updating the configuration. Remember that you must provide the exact installation scope; otherwise, it will cause an error, and the configuration will not be updated.
Similarly, the configuration can be loaded using.
Input your search keywords and press Enter.
