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.

A convention of prefixing a module/team name is encouraged, e.g. "ERM Agreements"/"ERM Licenses", but not enforced.


WidgetDefinition NameImplementing ModuleWidgetType
ERM Agreementsmod-agreementsSimpleSearch
ERM Licensesmod-licensesSimpleSearch
  • No labels