Tria/emaui
1
0
Fork 0
mirror of https://github.com/Tria-plc/emaui.git synced 2026-08-29 16:28:13 +00:00
Code Issues Packages Projects Releases Wiki Activity

change

Browse Source
This commit is contained in:
Nati
2026-08-19 11:14:30 +00:00
parent 2b07cacce1
commit e1d52adb0c
7 changed files with 93 additions and 42 deletions
Download Patch File Download Diff File Expand all files Collapse all files

44
libs/api/src/lib/features/licensing/licensing.helpers.ts
View File

@@ -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)