LOVs and Listings

LOVs (Lists of Values) and Listings are data-driven components in tSM that allow users to select or view records from other entities. They are critical for enabling relationships across modules, such as assigning users, linking customers, or displaying related tickets.

These widgets can pull from static data, remote APIs, or entity-based queries, and can be filtered dynamically based on form context.

What is an LOV?

A List of Values (LOV) is typically a dropdown/select widget that presents values from another entity — like Users, Products, or Customers.

Feature	Description
Widget Type	tsm-autocomplete, tsm-customer-lov, etc.
Data Source	Configured via config.dataSource
Selection Modes	Single / Multi-select
Return Type	id, code, or full object

Example: Customer Selector

"customer": {
  "type": "string",
  "widget": {
    "type": "tsm-customer-lov",
    "config": {
      "dataSource": "CustomerEntity",
      "selectFirstValue": true,
      "showClear": true
    }
  }
}

Common LOV Config Options

Field	Purpose
dataSource	Defines which entity or list to load from
selectProperty	What is stored: id, code, or other key
displayField	What to show in the dropdown UI
multiselect	Allow multiple selections
defaultFilters	Predefined filters for limiting result scope
selectFirstValue	Automatically choose the first available value

What is a Listing?

A Listing is a tabular widget that displays multiple records from an entity — typically used in detail forms, dashboards, or nested forms.

Widget Example	Use Case
tsm-ticket-list-widget	Show all related tickets
tsm-user-stock-items	Show inventory assigned to user
tsm-customer-list-widget	Embed customer search

Listing Features

• Search, sort, and filter records

• Column profiles

• Bulk actions (in some cases)

• Read-only or interactive (e.g., row selection)

  Context-Based Filtering (Dynamic Lists)

You can use JEXL expressions to apply filters dynamically based on the current form.

"config": {
  "defaultFilters": [
    {
      "field": "customerId",
      "operator": "eq",
      "value": "${$context.form.customerId}"
    }
  ]
}

This will limit the listing to only rows related to the currently selected customer.

LOV vs. Listing – When to Use What?

Use Case	Use Component
Select one or more entities	LOV (tsm-autocomplete)
Show related records in a table	Listing (tsm-*-list-widget)
Reference-only (read-only data)	Listing or Card
Filtered or user-specific view	Both (via filters)

Performance Considerations

• Avoid large unfiltered LOVs (use defaultFilters)
• Listings with too many rows can impact rendering time — paginate if possible
• Enable lazy loading for remote data sources
• Use selectFirstValue wisely to reduce required clicks but prevent unintended auto-selection

Pro Tips

• For LOVs, always specify both selectProperty and displayField
• For Listings, define a profile to control visible columns and sorting
• Consider visibility logic for LOVs tied to form state
• Use readonly mode for Listings if edit isn’t needed