The dashboard interface
In order for a definition defined by another backend module to be discovered by mod-service-interaction, first that module will need to implement the dashboard interface.
That involves an entry in the ModuleDescriptor for that module of the shape:
{
"id": "dashboard",
"interfaceType": "multiple",
"version": "1.0",
"handlers": [
{
"methods": [ "GET" ],
"pathPattern": "/dashboard/definitions",
"permissionsRequired": []
}
]
}
When mod-service-interaction is queried for widgetDefinitions via the endpoint /servint/widgets/definitions/global, it will make a call through Okapi to fetch all of the widgetDefinitions provided by any apps implementing this interface.
The expected shape from the endpoint /dashboard/definitions is either a single JSON object or an array of JSON objects. Should the provided definitions be invalid, error messages will be logged to mod-service-interaction (See what went wrong). Mod-service interaction will then collate these definitions, and resolve them to a list of the latest valid Definition for each major version of each Definition name.
Each new WidgetDefinition must have a name unique to the module implementing it. Should mod-foo and mod-bar both expose definitions named "baz", then whichever of these modules is called second by Okapi will have all Definitions named "baz" rejected. Underneath is a table of existing WidgetDefinition names, and which module is implementing them. This should be appended to whenever a new WidgetDefinition is created by a module.
| WidgetDefinition Name | Implementing Module | WidgetType |
|---|---|---|
| ERM Agreements | mod-agreements | SimpleSearch |
| ERM Licenses | mod-licenses | SimpleSearch |