Configuring Lookup (Mint) Records

This guide outlines how to configure your ReDBox deployment to ingest, index, search, and display lookup records (formerly held in Mint) using the new internal lookup functionality. It is intended for technical administrators or developers maintaining ReDBox configuration.

---

1. Configure the Record Type

Update config/recordtype.js to define the record type(s) for your lookup records. These records are able to utilise all the features existing record types are able to, including onCreate and onUpdate triggers.

Example:

module.exports.recordtype = {
  party: {
    packageType: "party",
    searchCore: "parties", // optional if you're querying Solr and want the ability to tune a custom Solr core
    hooks: {
      onCreate: {},
      onUpdate: {}
    },
    relatedTo: [],
    searchFilters: []
  }
};

• searchCore is optional. If omitted, the default Solr core will be used.

---

2. Define the Workflow for the Record Type

Update config/workflow.js to configure how records behave in the system. A custom form can be configured for a record if desired (see [Configuring Record Forms](https://github.com/redbox-mint/redbox-portal/wiki/Configuring-Record-Forms)), however a default view only form that will display all the fields based on the record's schema has been provided. To use the generated form, set form to the value "generated-view-only"

Minimal View-Only Example:

"party": {
  "draft": {
    config: {
      workflow: {
        stage: "draft",
        stageLabel: "Draft"
      },
      authorization: {
        viewRoles: ["Admin", "Librarians"],
        editRoles: ["Admin", "Librarians"]
      },
      form: "generated-view-only"
    },
    starting: true
  }
}

---

3. Configure Solr for the Record Type

Update config/solr.js to define a separate Solr core if needed.

Example:

module.exports.solr = {
  cores: {
    default: {
      options: {
        host: "solr",
        port: "8983",
        core: "redbox"
      },
      schema: {
        // fields and dynamic fields
      },
      preIndex: {
        // flattening and transformations
      }
    },
    parties: {
      options: {
        host: "solr",
        port: "8983",
        core: "parties"
      }
      // optionally define custom schema or preIndex here
    }
  }
};

Make sure the searchCore value defined in recordtype.js matches one of the keys under cores.

---

4. Configure Vocab Queries for Lookups

ReDBox supports dynamically populated vocab fields in forms using query-based lookups. These can be backed by:

• A Solr search query, for records indexed in Solr.

• A named database query, for data that resides in the database.

You define these in config/vocab.js under the queries section.

---

4.1 Solr-Based Query Example

module.exports.vocab = {
  queries: {
    parties: {
      searchQuery: {
        searchCore: "parties",
        baseQuery: "metaMetadata_type:party"
      },
      queryField: {
        property: "full_name",
        type: "text"
      },
      resultObjectMapping: {
        fullname: "<%= record.full_name %>",
        email: "<%= record.email %>",
        orcid: "<%= record.orcid %>"
      }
    }
  }
};

• searchQuery.searchCore: Which Solr core to query

• baseQuery: Base query string to filter records

• queryField: Defines what field user input will match

• resultObjectMapping: How the result appears in the dropdown

---

4.2 Database-Based Query Example

module.exports.vocab = {
  queries: {
    rdmps: {
      databaseQuery: {
        queryName: "listRDMPRecords"
      },
      queryField: {
        property: "title",
        type: "text"
      },
      resultObjectMapping: {
        title: "<%= record.metadata.title %>",
        oid: "<%= record.oid %>"
      }
    }
  }
};

• databaseQuery.queryName: Named query defined in your namedquery.js/code>. See [Configuring Named Queries](https://github.com/redbox-mint/redbox-portal/wiki/Configuring-Named-Queries) for more information

• queryField.property: The field that will be matched

• resultObjectMapping: Defines keys rendered in the form

---

4.3 Using Query Vocab in a Form Field

The existing Vocab Components in the forms have been updated to support the new vocab lookup type.

{
   class: 'VocabField',
   definition: {
   vocabQueryId: "activity",
   sourceType: "query",
   titleFieldName: "title",
   titleFieldArr: ["title"],
   fieldNames: ["title", "ID"],
   stringLabelToField: "ID",
   }
}

The vocabQueryId (activity) must match the key in your vocab.js config.

---

5. Enable Dashboard Table View (Optional)

To allow administrators to browse Mint records in a table view:

a. Add link to dashboard for the record type

Example URL to link from the admin homepage:

#/dashboard/party

b. Configure filters in config/dashboardtype.js

module.exports.dashboardtype = {
  standard: {
    formatRules: {
      sortBy: "metaMetadata.lastSaveDate:-1",
      queryFilters: {
        party: [
          {
            filterType: "text",
            filterFields: [
              { name: "Full Name", path: "metadata.full_name" },
              { name: "Email", path: "metadata.email" }
            ]
          }
        ]
      }
    }
  }
};

This will render a sortable, filterable table view of party records.

---

6. (Optional) Legacy Mint API Harvest Compatibility

For institutions still using the legacy Mint harvester, ReDBox provides a compatible endpoint:

Endpoint:

POST /:branding/:portal/api/mint/harvest/:recordType

Legacy-Compatible Payload Format:

{
  "records": [
    {
      "harvest_id": "s123456",
      "metadata": {
        "data": {
          "ID": "s123456",
          "GIVEN_NAME": "Andrew",
          "EMAIL": "notAReal@email.edu.au",
          "ORCID": "0000-0001-7269-2286"
        }
      }
    }
  ]
}

This endpoint transforms the payload internally and creates records using standard ReDBox logic.