Page Comparison

...

Domain Structure

The domain classes described here are pretty similar to what was laid out already the components described in the vocabulary section.

External User

When a user interacts with mod-service-interaction, by fetching their dashboard or otherwise, the first thing the module will do is resolve their FOLIO user UUID to a domain class called ExternalUser. This means that every user who interacts with the backend will have an ExternalUser domain object which we then can hang dashboards from. This domain class stores no personal information besides the user UUID and the dashboard configuration.

...

String id
hasMany = [
	dashboards: Dashboard
]

Here I've included the id The id is included only to note that we set this on binding to be the same as the FOLIO User UUID, so that we can then rely on those being the same. The hasMany here is future proofing. Right now we Currently there is only support for a single dashboard per user, called "DEFAULT, which is automatically created the first time they access mod-service-interaction. In future we may look to support multiple dashboards per user maybe introduced.

WidgetType

WidgetType consists of three fields:

...

The name and typeVersion need to together form a unique couplet, allowing us ensuring that it is possible to know exactly which schema we're using is being used at any given point, but and also to update them as we go through allow updates to schemas throughout the lifecycle of a widgetType.

The schema field is simply a TEXT field, allowing the widgetType to store a standard JSON schema. This will dictate the shape of any widgetDefinition using this type.

WidgetDefinition

WidgetDefinition consists of four fields:

String name
String definition
String definitionVersion
WidgetType type

Similarly to before, we have there is name and definitionVersion, allowing us to update these as we go, but we also have these to be updated over time. Additional there is a type field, of class WidgetType. This ties the definition WidgetDefinition to an existing WidgetType. Finally we have a TEXT field definition, which will house is used to store the JSON responsible for this widgetDefinition.

WidgetInstance

WidgetInstance consists of four main fields:

...

The name, which will display at the top of the widget on a dashboard, ; a configuration string which houses is used to store a JSON blob, containing all the information needed for whatever the definition is, ; and a definition, of type WidgetDefinition, which ties the WidgetInstance to a WidgetDefinition.

The final field weight relates directly to the Dashboard this WidgetInstance sits on, determining its orderthe order in which the WidgetInstances are displayed when the user views the dashboard.

As you can see from the belongsTo section, a WidgetInstance is just that, an instance of a widget, unique to a single user's dashboard.

Validation

In the future we WidgetDefinitions will have WidgetDefinitions be validated against the type schema automatically, and resolved to the correct version etc. Similarly, we plan it is planned to have a chunk of code per WidgetType which can take in a WidgetDefinition and create a specific schema for a WidgetInstance based on that, which we would then validate it it could then be validated against.

That means the validation flow for a new widgetDefinition and then widgetInstance based on that is as follows:

Endpoints

This module as things stand has a few endpoints available to it. These are in the KIWT style, similar to Agreements/Licenses.

Dashboard fetch

A user can fetch their dashboards with the endpoint /servint/dashboard/my-dashboards. The first time a new user UUID is encountered, an ExternalUser will be created, and a dashboard named "DEFAULT" will be attached to that user. For administrative purposes, we also have the there is an endpoint /servint/dashboard which can fetch all dashboards in the system, protected by permissions.

Widget fetch

In order to facilitate the fetch and display of widgets, two more endpoints are also exposed: /servint/widgets/definitions will return a list of all the definitions in the sytem, and /servint/widgets/instances will be accessible to administrators to fetch ALL widget instances in the system, with specific access available to single users through /servint/widgets/instances/<id of my widget>.