ngx-t-workflow-typings 3.2.2 → 3.2.3

package/dist/interfaces/Requirements/StepReferenceRules.constant.d.ts

@@ -1,6 +1,7 @@
 import type { ElementTypes } from 'ngx-t-forms-types';
 import type { AdjudicationSteps } from 'ngx-t-forms-types';
 import type { InputDataTypes } from 'ngx-t-forms-types';
+import type { InputTypes } from 'ngx-t-forms-types';
 import { WorkflowStepTypeEnum } from '../ProcessStep/WorkflowStepType.interface.js';
 import { AdjudicationType } from '../ProcessStep/ProcessStep.interface.js';
 import { type StepReferenceRule, type WorkflowReferenceRule } from './StepReferenceRules.interface.js';
@@ -26,6 +27,23 @@ export type DatePickerElementLiteralAgrees = AssertTrue<`${ElementTypes.DatePick
 export type DateRangePickerElementLiteralAgrees = AssertTrue<`${ElementTypes.DateRangePicker}` extends 'dateRangePicker' ? true : false>;
 /** `InputDataTypes.Date` — the date `dataType` fallback (PRODUCT SPEC #14). */
 export type DateDataTypeLiteralAgrees = AssertTrue<`${InputDataTypes.Date}` extends 'date' ? true : false>;
+/**
+ * `ElementTypes.DateTimePicker` — the date+time editor
+ * (`F/.../t-form-input/elements/date-time-picker-input-element`, registered at
+ * `F/.../t-form-input/element-registry.ts:54-56`).
+ *
+ * DELIBERATELY UNGUARDED, unlike its siblings. The member was added upstream
+ * AFTER `ngx-t-forms-types@0.0.29`, which is this package's dependency floor and
+ * the copy its own build compiles against; a `${ElementTypes.DateTimePicker}`
+ * assertion would therefore fail to compile here rather than catch anything.
+ * Guard it the moment the floor moves past the release that carries it.
+ */
+/** `InputTypes.Date` — a plain `input` rendered as a native date picker. */
+export type DateInputTypeLiteralAgrees = AssertTrue<`${InputTypes.Date}` extends 'date' ? true : false>;
+/** `InputTypes.DateTimeLocal` — a plain `input` rendered as a native date+time picker. */
+export type DateTimeLocalInputTypeLiteralAgrees = AssertTrue<`${InputTypes.DateTimeLocal}` extends 'datetime-local' ? true : false>;
+/** `InputTypes.Month` — a plain `input` whose `YYYY-MM` value `new Date()` still parses. */
+export type MonthInputTypeLiteralAgrees = AssertTrue<`${InputTypes.Month}` extends 'month' ? true : false>;
 /**
  * Every cross-reference rule, per step type. Exhaustive over
  * `WorkflowStepTypeEnum` for the same reason `STEP_TYPE_REQUIREMENTS` is: a new

package/dist/interfaces/Requirements/StepReferenceRules.constant.js

@@ -6,8 +6,16 @@ import { ReferenceCatalog, ReferenceTargetKind, } from './StepReferenceRules.int
 const WORKFLOW_ADJUDICATION_ELEMENT = 'workflowAdjudication';
 const TOGGLE_ELEMENT = 'toggle';
 const DATE_PICKER_ELEMENT = 'datePicker';
+const DATE_TIME_PICKER_ELEMENT = 'dateTimePicker';
 const DATE_RANGE_PICKER_ELEMENT = 'dateRangePicker';
 const DATE_DATA_TYPE = 'date';
+/* The native `<input type>` values whose stored string `new Date()` PARSES.
+ * `week` (`2026-W37`) and `time` (`10:30`) are excluded on purpose: those two
+ * really do yield an `Invalid Date`, which is the failure this rule exists to
+ * catch. `month` (`2026-09`) parses to the first of that month. */
+const DATE_INPUT_TYPE = 'date';
+const DATE_TIME_LOCAL_INPUT_TYPE = 'datetime-local';
+const MONTH_INPUT_TYPE = 'month';
 /* -------------------------------------------------------------------------- */
 /* Shared rule fragments                                                      */
 /* -------------------------------------------------------------------------- */
@@ -667,12 +675,28 @@ export const STEP_REFERENCE_RULES = {
             // TYPED index so the date predicate below can inspect `element`/`dataType`.
             targetKind: ReferenceTargetKind.FormControlInWorkflowForm,
             // PRODUCT SPEC #14: it must be a DATE input — a date picker, a date-range
-            // picker, or any input whose `dataType` is `date`.
+            // picker, the date+time editor, any input whose `dataType` is `date`, or a
+            // plain `input` carrying a native date `type`. THREE independent shapes,
+            // because the builder can author a date field three ways while the engine
+            // only ever does `new Date(document.form[key])`.
+            //
+            // The `type` leaf is what stopped this rule false-violating: the `input`
+            // template seeds `dataType: 'string'` (`FT/FormBuilder/DefaultEelement.ts:51-52`)
+            // and switching `type` to `date` / `datetime-local` does NOT restamp it, so
+            // a perfectly good native date control matched neither of the other two
+            // leaves and was reported as "not a date field".
             predicates: [
                 {
                     anyOf: [
-                        { targetField: 'element', in: [DATE_PICKER_ELEMENT, DATE_RANGE_PICKER_ELEMENT] },
+                        {
+                            targetField: 'element',
+                            in: [DATE_PICKER_ELEMENT, DATE_TIME_PICKER_ELEMENT, DATE_RANGE_PICKER_ELEMENT],
+                        },
                         { targetField: 'dataType', equals: DATE_DATA_TYPE },
+                        {
+                            targetField: 'type',
+                            in: [DATE_INPUT_TYPE, DATE_TIME_LOCAL_INPUT_TYPE, MONTH_INPUT_TYPE],
+                        },
                     ],
                     message: 'the control it names is not a date field. The engine parses this value as a Date to schedule the post\'s expiry, so a non-date control reads as `Invalid Date`, the closing job is never queued, and the post never closes.',
                     severity: StepRequirementSeverity.Error,
@@ -682,7 +706,9 @@ export const STEP_REFERENCE_RULES = {
             mismatchSeverity: StepRequirementSeverity.Error,
             message: 'This is what closes the public post. The engine reads the expiry date from `document.form[thisField]` and schedules the job that completes the step; an unresolvable control makes the date `undefined`, no job is scheduled, and — because a public-portal step has no members to hand it to either — the document PARKS on the step with no task and no expiry, indefinitely.',
             evidence: [
-                'PRODUCT SPEC #14: `postExpiryDateControlName` must be a date input (datePicker / dateRangePicker / `dataType === "date"`).',
+                'PRODUCT SPEC #14: `postExpiryDateControlName` must be a date input — a `datePicker`, `dateTimePicker` or `dateRangePicker` element, OR `dataType === "date"`, OR a native `type` of `date` / `datetime-local` / `month`.',
+                'FT/formInput/BasicFormInputInterface.ts:46-48,66-80 (the element and input-type enums the three leaves match; `dateTimePicker` and the native types are all authorable today) and F/.../t-form-input/element-registry.ts:48-56 (all three date editors are registered and rendered).',
+                'FT/FormBuilder/DefaultEelement.ts:51-52,421-422,465-466,512-513 (WHY THE `type` LEAF IS NEEDED: the three picker templates seed `dataType: date`, but the plain `input` template seeds `dataType: string` and choosing a date `type` never restamps it — so an `<input type="date">` used to violate this rule).',
                 'E/services/workflow.ts:813-817 (`const initDate = document.form[inititDateParam]; if (initDate) {`)',
                 'E/services/workflow.ts:818-840 (the `workflow-task-expiry` job carrying `completeStep: true` — the only thing that closes the post)',
                 'E/services/workflow.ts:812,842-850 (neither branch runs: no members means no job card, and a present-but-unresolvable field skips the `updateR` fall-through too)',

package/dist/interfaces/Requirements/StepReferenceRules.interface.d.ts

@@ -241,7 +241,8 @@ export type ReferenceContentPredicate =
 /**
  * The target's `targetField` must be one of a fixed set — the disjunctive
  * sibling of `equals`. Used where the spec lists alternatives, e.g. a date
- * input's `element` may be `datePicker` OR `dateRangePicker`.
+ * input's `element` may be `datePicker`, `dateTimePicker` OR
+ * `dateRangePicker`.
  */
  | (ReferencePredicateBase & {
     readonly targetField: string;
@@ -250,8 +251,9 @@ export type ReferenceContentPredicate =
 /**
  * At least ONE of the listed leaf comparisons must hold — a disjunction across
  * possibly-different `targetField`s. This is how "the input is a date control"
- * is expressed declaratively: `element ∈ {datePicker, dateRangePicker}` OR
- * `dataType === 'date'` (PRODUCT SPEC #14, `postExpiryDateControlName`).
+ * is expressed declaratively: `element ∈ {datePicker, dateTimePicker, dateRangePicker}` OR
+ * `dataType === 'date'` OR a native date `type` (PRODUCT SPEC #14,
+ * `postExpiryDateControlName`).
  */
  | (ReferencePredicateBase & {
     readonly anyOf: readonly ReferenceLeafPredicate[];

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ngx-t-workflow-typings",
-  "version": "3.2.2",
+  "version": "3.2.3",
   "description": "Typings and interfaces for the ngx-t-workflows library.",
   "keywords": [
     "typings",
@@ -42,14 +42,14 @@
     "test": "echo \"Error: no test specified\" && exit 1"
   },
   "peerDependencies": {
-    "ngx-t-forms-types": ">=0.0.29",
+    "ngx-t-forms-types": ">=0.0.33",
     "rxjs": ">=7.8.0"
   },
   "dependencies": {
     "joi": "^18.0.2"
   },
   "devDependencies": {
-    "ngx-t-forms-types": "^0.0.29",
+    "ngx-t-forms-types": "^0.0.33",
     "rimraf": "^6.1.3",
     "typescript": "^5.9.3"
   }