@kelpie/schemas 0.8.0 → 0.10.0

package/src/values.ts

@@ -90,6 +90,7 @@ export const EXTENSIBLE_RECORD_TYPES = [
   'opportunity',
   'partnership',
   'raise',
+  'enquiry',
   'role',
   'candidate',
 ] as const
@@ -110,6 +111,7 @@ export const RECORD_TARGET_TYPES = [
   'opportunity',
   'partnership',
   'raise',
+  'enquiry',
   'candidate',
 ] as const
 
@@ -123,6 +125,7 @@ export const RECORD_TARGET_TYPE_LABELS: Readonly<Record<RecordTargetType, string
   opportunity: 'Opportunity',
   partnership: 'Partnership',
   raise: 'Raise',
+  enquiry: 'Enquiry',
   candidate: 'Candidate',
 }
 
@@ -142,6 +145,7 @@ export const SEARCH_COLLECTIONS = [
   'person',
   'role',
   'company',
+  'enquiry',
   'deal',
   'opportunity',
   'raise',
@@ -207,16 +211,23 @@ export const INTERVIEW_STAGE_LABELS: Readonly<Record<InterviewStage, string>> =
 export const FIRST_INTERVIEW_STAGE: InterviewStage = INTERVIEW_STAGES[0]
 
 /**
- * The four pipelines whose board columns live in `pipeline_stages`. A Deal moves
+ * The five pipelines whose board columns live in `pipeline_stages`. A Deal moves
  * through `deal` stages and so on; the kinds are fixed even though the stages
  * within each are workspace-configurable.
  */
-export const PIPELINE_KINDS = ['deal', 'opportunity', 'raise', 'partnership'] as const
+export const PIPELINE_KINDS = [
+  'enquiry',
+  'deal',
+  'opportunity',
+  'raise',
+  'partnership',
+] as const
 
 export type PipelineKind = (typeof PIPELINE_KINDS)[number]
 
 /** Display names for `PIPELINE_KINDS`. "Fundraising" is what the nav calls a Raise. */
 export const PIPELINE_KIND_LABELS: Readonly<Record<PipelineKind, string>> = {
+  enquiry: 'Enquiry',
   deal: 'Deal',
   opportunity: 'Opportunity',
   raise: 'Fundraising',
@@ -313,24 +324,46 @@ export type FormStatus = (typeof FORM_STATUSES)[number]
  * uploads, multi-page forms and branching out of scope, and every type here is
  * one `<input>`, `<textarea>` or `<select>`.
  */
-export const FORM_FIELD_TYPES = ['text', 'email', 'textarea', 'select'] as const
+export const FORM_FIELD_TYPES = ['text', 'email', 'textarea', 'select', 'consent', 'notice'] as const
 
 export type FormFieldType = (typeof FORM_FIELD_TYPES)[number]
 
+/**
+ * The field types whose answer is stored as a boolean, not a string. A
+ * `consent` field renders as a checkbox whose label carries the consent
+ * statement; the answer records whether the visitor ticked it.
+ */
+export const FORM_BOOLEAN_FIELD_TYPES = ['consent'] as const
+
+export type FormBooleanFieldType = (typeof FORM_BOOLEAN_FIELD_TYPES)[number]
+
 /**
  * Where a field's answer lands on submit.
  *
  * `position.title` rather than a person field, because a job title belongs to the
  * Person↔Company link and nowhere else. `submission` stores the answer without
  * writing any CRM record, which is what a free-text "How can we help?" wants.
+ *
+ * A form asks for a name the way its author wants it asked: one `person.name`
+ * box, or the `person.first_name` / `person.last_name` pair most sign-up forms
+ * use. Mapping the pair and no `person.name` composes the display name from the
+ * two, so neither arrangement makes a nameless person. `salutation` and `suffix`
+ * are storable on a Person but are not offered here — a public form asking for
+ * them is rare enough that the choice is not worth the room in this list.
  */
 export const FORM_FIELD_MAP_TARGETS = [
   'person.name',
+  'person.first_name',
+  'person.last_name',
   'person.email',
+  'person.consent',
   'company.name',
   'company.domain',
   'position.title',
+  'enquiry.name',
   'deal.name',
+  'opportunity.name',
+  'partnership.name',
   'submission',
 ] as const
 
@@ -338,14 +371,23 @@ export type FormFieldMapTarget = (typeof FORM_FIELD_MAP_TARGETS)[number]
 
 export const FORM_FIELD_MAP_TARGET_LABELS: Readonly<Record<FormFieldMapTarget, string>> = {
   'person.name': 'Person · name',
+  'person.first_name': 'Person · first name',
+  'person.last_name': 'Person · last name',
   'person.email': 'Person · email',
+  'person.consent': 'Person · consent',
   'company.name': 'Company · name',
   'company.domain': 'Company · domain',
   'position.title': 'Position · title',
+  'enquiry.name': 'Enquiry · name',
   'deal.name': 'Deal · name',
+  'opportunity.name': 'Opportunity · name',
+  'partnership.name': 'Partnership · name',
   submission: 'Submission only',
 }
 
+/** The map target for a consent field. Repeats per purpose, unlike `person.email`. */
+export const PERSON_CONSENT_TARGET: FormFieldMapTarget = 'person.consent'
+
 /** The one mapping a form cannot process without, and may carry at most once. */
 export const PERSON_EMAIL_TARGET: FormFieldMapTarget = 'person.email'
 
@@ -359,6 +401,16 @@ export const FORM_OPTION_VALUE_TYPES = ['string', 'number', 'boolean'] as const
 
 export type FormOptionValueType = (typeof FORM_OPTION_VALUE_TYPES)[number]
 
+/**
+ * Each post-submit action lands one of these on the submission's `action_log`.
+ * `ok` = the action ran; `skipped` = its precondition was absent (a company
+ * list on a submit that never resolved one); `error` = the savepoint rolled
+ * back so the rest of the submit could continue.
+ */
+export const FORM_ACTION_STATUSES = ['ok', 'skipped', 'error'] as const
+
+export type FormActionStatus = (typeof FORM_ACTION_STATUSES)[number]
+
 /**
  * The domain events a webhook can subscribe to.
  *
@@ -415,6 +467,7 @@ export const AGENT_TASK_TARGET_TYPES = [
   'opportunity',
   'partnership',
   'raise',
+  'enquiry',
   'candidate',
   'role',
   'handbook',
@@ -444,3 +497,116 @@ export const AGENT_RUN_STATUS_LABELS: Readonly<Record<AgentRunStatus, string>> =
   succeeded: 'Succeeded',
   failed: 'Failed',
 }
+
+/**
+ * The seven record types a workspace may attach custom field definitions to.
+ *
+ * The ones that already carry `tags` and agent-oriented fields on the record
+ * itself. Role and Candidate are absent on purpose: hiring state hangs off the
+ * Candidate link and a Role is a header rather than a rich record, so the demand
+ * signal for custom fields on either has not landed. Kept separate from
+ * `RECORD_TARGET_TYPES` and `EXTENSIBLE_RECORD_TYPES` so a later addition here
+ * cannot silently widen either of those.
+ */
+export const CUSTOM_FIELD_OBJECT_TYPES = [
+  'person',
+  'company',
+  'deal',
+  'opportunity',
+  'partnership',
+  'raise',
+  'enquiry',
+] as const
+
+export type CustomFieldObjectType = (typeof CUSTOM_FIELD_OBJECT_TYPES)[number]
+
+export const CUSTOM_FIELD_OBJECT_TYPE_LABELS: Readonly<Record<CustomFieldObjectType, string>> = {
+  person: 'Person',
+  company: 'Company',
+  deal: 'Deal',
+  opportunity: 'Opportunity',
+  partnership: 'Partnership',
+  raise: 'Raise',
+  enquiry: 'Enquiry',
+}
+
+/**
+ * The nine editor types a custom field can carry.
+ *
+ * Deliberately distinct from `FORM_FIELD_TYPES`: a form asks a stranger for four
+ * kinds of text over one submit; a custom field is a first-class attribute on a
+ * record with numeric, date, boolean and currency answers. Sharing one list
+ * would drag either surface toward the other's shape.
+ *
+ * `record_reference` is intentionally absent from v1 — it needs the polymorphic
+ * existence check and delete-transaction cleanup that Phase 2 owns.
+ */
+export const CUSTOM_FIELD_TYPES = [
+  'text',
+  'long_text',
+  'number',
+  'currency',
+  'date',
+  'checkbox',
+  'select',
+  'multi_select',
+  'url',
+] as const
+
+export type CustomFieldType = (typeof CUSTOM_FIELD_TYPES)[number]
+
+export const CUSTOM_FIELD_TYPE_LABELS: Readonly<Record<CustomFieldType, string>> = {
+  text: 'Text',
+  long_text: 'Long text',
+  number: 'Number',
+  currency: 'Currency',
+  date: 'Date',
+  checkbox: 'Checkbox',
+  select: 'Select',
+  multi_select: 'Multi-select',
+  url: 'URL',
+}
+
+/**
+ * The custom-field types whose definition carries an `options` list. Every
+ * other type stores its `options` as `[]` and any non-empty write is `422`.
+ */
+export const CUSTOM_FIELD_TYPES_WITH_OPTIONS = ['select', 'multi_select'] as const
+
+export type CustomFieldTypeWithOptions = (typeof CUSTOM_FIELD_TYPES_WITH_OPTIONS)[number]
+
+/**
+ * The default a consent purpose starts with, and what a person without an
+ * explicit `person_consents` row inherits for that purpose. `unknown` is the
+ * safest default — silence about a person's wishes is not a grant.
+ */
+export const CONSENT_PURPOSE_STATUSES = ['unknown', 'granted', 'withdrawn'] as const
+
+export type ConsentPurposeStatus = (typeof CONSENT_PURPOSE_STATUSES)[number]
+
+export const CONSENT_PURPOSE_STATUS_LABELS: Readonly<Record<ConsentPurposeStatus, string>> = {
+  unknown: 'Unknown',
+  granted: 'Granted',
+  withdrawn: 'Withdrawn',
+}
+
+/**
+ * The explicit status on a `person_consents` row. `unknown` is deliberately
+ * absent: no row is the unknown, so a stored row always carries a decision.
+ */
+export const CONSENT_STATUSES = ['granted', 'withdrawn'] as const
+
+export type ConsentStatus = (typeof CONSENT_STATUSES)[number]
+
+export const CONSENT_STATUS_LABELS: Readonly<Record<ConsentStatus, string>> = {
+  granted: 'Granted',
+  withdrawn: 'Withdrawn',
+}
+
+/**
+ * Where a `person_consents` row came from. `form:<form_id>` and `list:<list_id>`
+ * are prefixed so the origin is inspectable; `import` and `manual` need no id.
+ */
+export const CONSENT_SOURCE_KINDS = ['form', 'list', 'import', 'manual'] as const
+
+export type ConsentSourceKind = (typeof CONSENT_SOURCE_KINDS)[number]