change

libs/api/src/lib/features/licensing/licensing.helpers.ts

@@ -1,6 +1,7 @@
 import { resolveTokenFromStorage } from '../../session';
 import type {
   Bilingual,
+  FamilyKind,
   FormFieldConfig,
   FormSectionConfig,
   LicenseApplication,
@@ -172,21 +173,6 @@ export const APPLICANT_NAME_TYPE_KEYS = [
   'ENDORSEMENT_GOC',
 ];
 
-/**
- * Which business concept a licence type actually is, for terminology and
- * navigation only — never a workflow or eligibility branch. Mirrors
- * `resolveFamilyKind` in emaapi's `common/utils/family-terminology.ts`; the
- * two must be kept in step by hand since the value isn't sent over the wire
- * (nothing needs it server-side beyond notification copy, so a shared
- * package felt like more plumbing than the duplication it would save).
- *
- * A permission granted to a logistics operator, a seafarer's proof of
- * competence, and a seafarer/vessel's identity or statutory record are three
- * different things to the people using this system, even though they run
- * through the identical application pipeline — see BR-MTO-020.
- */
-export type FamilyKind = 'LOGISTICS_LICENSE' | 'CERTIFICATE' | 'DOCUMENT';
-
 const FAMILY_KIND_BY_KEY: Partial<Record<string, FamilyKind>> = {
   SEAMAN_BOOK: 'DOCUMENT',
   VESSEL_REGISTRATION: 'DOCUMENT',
@@ -203,10 +189,14 @@ const FAMILY_KIND_BY_KEY: Partial<Record<string, FamilyKind>> = {
 };
 
 /**
- * `FamilyKind` for a type key that may not be in the map yet. Falls back to
- * `LOGISTICS_LICENSE`, reproducing today's "Licence ___" wording — the safe
- * default for an unrecognised key, matching how the map above treats config
- * it doesn't know about.
+ * `FamilyKind` for a type key, for data that predates `familyKind` being a
+ * real column on the server (cached responses from before the rollout, or
+ * anything that only ever had a bare key to go on). Every fresh response now
+ * carries `familyKind` directly from the server's own `family_kind` column —
+ * prefer that over calling this. Kept only as a fallback, and only for keys
+ * this map happens to know about; falls back further to `LOGISTICS_LICENSE`
+ * for anything else, reproducing today's "Licence ___" wording — the safe
+ * default for an unrecognised key.
  */
 export function resolveFamilyKind(licenseTypeKey: string | undefined | null): FamilyKind {
   return (licenseTypeKey && FAMILY_KIND_BY_KEY[licenseTypeKey]) || 'LOGISTICS_LICENSE';
@@ -248,9 +238,21 @@ export function familyLabels(familyKind: FamilyKind): FamilyLabels {
   return FAMILY_LABELS[familyKind];
 }
 
-/** Company name, or applicant name for licence types that have no company. */
+/**
+ * Company name, or applicant name for applications with no company.
+ *
+ * Branches on `familyKind` — the real data-model column — rather than a
+ * hand-maintained key list. A certificate or document is filed by a person,
+ * never a business, so it never has a `companyName` to show; a logistics
+ * licence always does. This is what used to be `APPLICANT_NAME_TYPE_KEYS`, a
+ * frontend array that had to be remembered and kept in sync by hand every
+ * time a new certificate/document type was added — it silently missed
+ * `SEAMAN_BOOK`/`BTC_BASIC_TRAINING`, which is why those rows rendered "—"
+ * instead of the applicant's name in the backoffice queue. `familyKind` is
+ * correct for every current and future type without a matching array update.
+ */
 export function applicantOrCompanyName(app: LicenseApplication): string | undefined {
-  if (!app.licenseType?.key || !APPLICANT_NAME_TYPE_KEYS.includes(app.licenseType.key)) {
+  if (app.familyKind === 'LOGISTICS_LICENSE') {
     return app.companyName ?? undefined;
   }
   const applicantName = (app.formData?.account as Record<string, unknown> | undefined)

libs/api/src/lib/features/licensing/licensing.types.ts

@@ -109,6 +109,19 @@ export type LicenseCategory =
   | "VESSEL_SERVICES"
   | "WAIVER_SERVICES";
 
+/**
+ * Which business concept a licence type actually is — the real data-model
+ * classification (emaapi's `license_types.family_kind` column), not a label
+ * computed from `key`. A permission granted to a logistics operator, a
+ * seafarer's proof of competence, and a seafarer/vessel's identity or
+ * statutory record are three different things to the people using this
+ * system, even though they run through the identical application pipeline —
+ * see BR-MTO-020. Drives terminology, navigation, and which columns a grid
+ * shows (Company/TIN only make sense for LOGISTICS_LICENSE rows) — never a
+ * workflow or eligibility branch.
+ */
+export type FamilyKind = "LOGISTICS_LICENSE" | "CERTIFICATE" | "DOCUMENT";
+
 export interface LicenseCategoryDefinition {
   key: LicenseCategory;
   name: Bilingual;
@@ -135,6 +148,8 @@ export interface LicenseType {
   name: Bilingual;
   description?: Bilingual;
   category: LicenseCategory;
+  /** The real data-model classification — see `FamilyKind`. */
+  familyKind: FamilyKind;
   certificatePrefix: string;
   feeNewApplication: string | number | null;
   feeRenewal: string | number | null;
@@ -257,6 +272,8 @@ export interface LicenseApplication {
   applicationNumber: string;
   licenseTypeId: string;
   licenseType?: LicenseType;
+  /** Denormalized from `licenseType.familyKind` at submission time. */
+  familyKind: FamilyKind;
   applicantUserId: string;
   parentApplicationId?: string | null;
   kind: ApplicationKind;
@@ -611,6 +628,8 @@ export interface IssuedLicense {
   certificateNumber: string;
   licenseTypeId: string;
   licenseType?: LicenseType;
+  /** Denormalized from `licenseType.familyKind` at issuance time. */
+  familyKind: FamilyKind;
   applicationId: string;
   companyName: string | null;
   tinNumber: string | null;