Comment on page
Once your app is developed and ready to launch, you need to provide settings for the Apps-Engine. The settings are displayed on the administration interface for the workspace admin to configure and launch the app.
Everything under the Settings menu of the app within a marketplace belongs under the app configuration. This tab contains various fields and instructions that can be filled out. What you see on the screen must be configured for the app. If you have a workspace, you can look at the Settings tab of existing apps on the Marketplace to see different app settings.
In this section, we will look at the configuration details.
Here are some key terms you need to familiarize yourself with:
- ID - for identifying the settings.
- Type - the type of value that will be saved.
- Required - whether or not configuring the app is required.
- Package value - the default value before the administrator can configure anything.
- I18n label - the translated name or description of an app.
You can create a distinct file containing the configuration settings, in which everything is defined as a basic object. In this file, define each setting separately. In the
configurationExtendmethod, you simply read the file. For each setting, call the
provideSettingmethod, so that each defined setting is read, called, and displayed in the user interface.
This is equivalent to executing the command:
Since your app may have multiple settings, it is preferable to organize them all in a separate file and reference them as required in the app's main file.
Every time the administrator modifies the app's configuration via the Settings panel, the
onSettingUpdatedmethod is invoked each time. The method will use the new value to make adjustments as necessary. For instance, you can inform an external service that the parameters have changed and the values have been updated. With
onPreSettingUpdate, you will receive both the old and updated settings values.
It is common in integrations to transmit certain security protocols for API requests. In the case of the Rocket.Chat REST API, these headers are
X-User-Id. See the Authentication endpoints for more information. It would be desirable if these headers were always set when making API queries. In such situations, it is customary to generate a personal access token in Rocket.Chat and adding configuration parameters to the app makes sense. These are configured in the
extendConfigurationmethod of the app's primary class.
The client ID and client secret are routinely generated by one of the mechanisms for the app settings. You can see this implemented in the settings file of the Notion app integration with Rocket.Chat.
Furthermore, along with defining the app configurations, you can create internationalization files for different languages. Let's look at the details in the next topic.
Last modified 12d ago