@mj-biz-apps/contracts-entities 0.1.0

package/dist/required-field-prose.js

@@ -0,0 +1,55 @@
+/**
+ * Swap the flat nullability prose for something actionable, and collapse duplicates, in place.
+ *
+ * WHY REPLACE AND NOT APPEND. One mistake must produce one error. Appending would leave the flat
+ * message beside the useful one, so a single empty field would mark itself twice.
+ *
+ * WHY COLLAPSE. A required field with a not-blank CHECK genuinely produces TWO absence errors on a
+ * create, and both are correct: MJ's nullability check refuses the null, and CodeGen's generated
+ * validator — derived from the CHECK — refuses null, empty AND whitespace, because the CHECK has to
+ * cover all three. Two rungs of the ladder saying the same thing about the same field; the user needs
+ * to be told once.
+ *
+ * WHY MATCH ON EMPTINESS RATHER THAN ON MJ'S WORDING. The obvious implementation greps the message
+ * text, which couples this to a string in MJ core it does not own and cannot see change. Matching on
+ * `Source` plus "the value really is absent" is stable across any rewording, and cannot capture the
+ * wrong error: the only other check MJ runs on these fields is `MaxLength`, which by construction
+ * fires only when a value is present.
+ *
+ * `result.Success` is deliberately not recomputed. Rewording cannot change a verdict, and collapsing
+ * cannot either — dropping a duplicate leaves at least one error standing for the same field.
+ */
+export function ExplainMissingRequiredFields(entity, result, prose) {
+    const explained = new Set();
+    const kept = [];
+    for (const error of result.Errors) {
+        const source = error.Source ?? '';
+        const sentence = prose[source];
+        if (!sentence || !fieldIsAbsent(entity, source)) {
+            kept.push(error);
+            continue;
+        }
+        if (explained.has(source))
+            continue;
+        explained.add(source);
+        error.Message = sentence;
+        kept.push(error);
+    }
+    result.Errors = kept;
+}
+/**
+ * Whether the named field is genuinely empty — the condition MJ's nullability check fires on, plus the
+ * blank-string case, which is what the app's `…_TextNotBlank` CHECK constraints add.
+ *
+ * A field the entity does not have returns FALSE, not true. That direction matters: an unknown field
+ * name means a prose map has drifted from the schema, and rewording an error for a field that does not
+ * exist would hide the drift behind a friendly sentence.
+ */
+function fieldIsAbsent(entity, fieldName) {
+    const field = entity.Fields.find((f) => f.EntityFieldInfo.Name === fieldName);
+    if (!field)
+        return false;
+    const value = field.Value;
+    return value === null || value === undefined || (typeof value === 'string' && value.trim().length === 0);
+}
+//# sourceMappingURL=required-field-prose.js.map

package/dist/required-field-prose.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"required-field-prose.js","sourceRoot":"","sources":["../src/required-field-prose.ts"],"names":[],"mappings":"AA2BA;;;;;;;;;;;;;;;;;;;;GAoBG;AACH,MAAM,UAAU,4BAA4B,CAAC,MAAkB,EAAE,MAAwB,EAAE,KAAyB;IAChH,MAAM,SAAS,GAAG,IAAI,GAAG,EAAU,CAAC;IACpC,MAAM,IAAI,GAA0B,EAAE,CAAC;IAEvC,KAAK,MAAM,KAAK,IAAI,MAAM,CAAC,MAAM,EAAE,CAAC;QAChC,MAAM,MAAM,GAAG,KAAK,CAAC,MAAM,IAAI,EAAE,CAAC;QAClC,MAAM,QAAQ,GAAG,KAAK,CAAC,MAAM,CAAC,CAAC;QAC/B,IAAI,CAAC,QAAQ,IAAI,CAAC,aAAa,CAAC,MAAM,EAAE,MAAM,CAAC,EAAE,CAAC;YAC9C,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC;YACjB,SAAS;QACb,CAAC;QACD,IAAI,SAAS,CAAC,GAAG,CAAC,MAAM,CAAC;YAAE,SAAS;QACpC,SAAS,CAAC,GAAG,CAAC,MAAM,CAAC,CAAC;QACtB,KAAK,CAAC,OAAO,GAAG,QAAQ,CAAC;QACzB,IAAI,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC;IACrB,CAAC;IAED,MAAM,CAAC,MAAM,GAAG,IAAI,CAAC;AACzB,CAAC;AAED;;;;;;;GAOG;AACH,SAAS,aAAa,CAAC,MAAkB,EAAE,SAAiB;IACxD,MAAM,KAAK,GAAG,MAAM,CAAC,MAAM,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,eAAe,CAAC,IAAI,KAAK,SAAS,CAAC,CAAC;IAC9E,IAAI,CAAC,KAAK;QAAE,OAAO,KAAK,CAAC;IACzB,MAAM,KAAK,GAAY,KAAK,CAAC,KAAK,CAAC;IACnC,OAAO,KAAK,KAAK,IAAI,IAAI,KAAK,KAAK,SAAS,IAAI,CAAC,OAAO,KAAK,KAAK,QAAQ,IAAI,KAAK,CAAC,IAAI,EAAE,CAAC,MAAM,KAAK,CAAC,CAAC,CAAC;AAC7G,CAAC"}

package/dist/value-list-validation.d.ts

@@ -0,0 +1,69 @@
+/**
+ * @fileoverview A STOPGAP for [MJ#3969](https://github.com/MemberJunction/MJ/issues/3969) — MJ does
+ * not validate value-list fields, so an `IN (…)` CHECK has no TypeScript counterpart at all.
+ *
+ * ## What is missing upstream
+ *
+ * When CodeGen meets `CHECK (Status IN ('Active','Inactive'))` it records the legal values as
+ * metadata — `EntityField.ValueListType = 'List'` plus `__mj.EntityFieldValue` rows — rather than
+ * emitting a generated `Validate()` method. That is the right call: the value list is also what the
+ * UI needs to render a dropdown, and one representation beats two.
+ *
+ * But `BaseEntity` then never reads it. `EntityField.Validate()` checks nullability, `MaxLength`,
+ * date parseability and numeric range, and stops. So this class of constraint is the one kind of
+ * schema rule with **no representation in TypeScript at all**: neither the browser nor a server
+ * subclass can preflight it, and an out-of-list value is refused only by SQL Server, as a raw
+ * constraint violation with no field attached.
+ *
+ * ## Why the dropdown is not the answer
+ *
+ * It protects the *form* path, which is presumably why nobody noticed. Every other path is
+ * unguarded — `mj sync push`, the GraphQL mutations, an Action, a subclass assigning the field in
+ * code, a data load — and those are precisely the paths where a typo is least likely to pass a human
+ * first.
+ *
+ * ## Why this is generic rather than three hand-written checks
+ *
+ * Three fields need it today (`ContractType.Status`, `ContractTemplateType.Status`,
+ * `ContractTemplateType.Status`). Naming them here would mean a fourth value-list field added next
+ * year is silently unguarded, and nothing would fail to say so. Driving off `ValueListTypeEnum`
+ * instead means the guard covers whatever the schema declares, now and later, and needs no edit when
+ * the schema changes — which is the same reason the rules it stands in for belong in MJ core.
+ *
+ * ## Deleting this
+ *
+ * When MJ#3969 lands, delete this file, drop the `ValidateValueLists(result)` call from every shared
+ * subclass, and delete `value-list-validation.test.ts`. Nothing else references it. The upstream fix
+ * produces the same errors from the same metadata, so the only observable change should be that the
+ * message is worded by MJ rather than by us.
+ *
+ * @module @mj-biz-apps/contracts-entities
+ */
+import { BaseEntity, ValidationResult } from '@memberjunction/core';
+/**
+ * Reject any value-list field whose value is not in its list.
+ *
+ * Call it from a shared subclass's `Validate()` override, after `super.Validate()`.
+ *
+ * Three exclusions, each of which would otherwise turn this from a guard into a bug:
+ *
+ * 1. **`List` only — never `ListOrUserEntry`.** That second mode exists precisely to allow values
+ *    outside the list; validating it would reject the very thing it was chosen to permit.
+ * 2. **An empty value set validates nothing.** A field marked `List` whose `EntityFieldValue` rows
+ *    have not been seeded would otherwise reject every value including the correct one, which is a
+ *    far worse failure than the one this prevents.
+ * 3. **Null and empty are left alone.** Whether the field may be empty is the nullability check's
+ *    question, and it has already answered it by the time this runs. Answering it again would report
+ *    one mistake as two errors.
+ *
+ * Read-only and virtual fields are skipped for the same reason `EntityField.Validate()` skips them:
+ * the caller cannot set them, so refusing a save over one is a dead end with no fix available.
+ *
+ * The message lists the legal values rather than merely saying the value is invalid — a refusal that
+ * does not say what would have been accepted sends the user back to guess.
+ *
+ * @param entity - The record being validated.
+ * @param result - The accumulating result; errors are pushed onto it and `Success` cleared.
+ */
+export declare function ValidateValueLists(entity: BaseEntity, result: ValidationResult): void;
+//# sourceMappingURL=value-list-validation.d.ts.map

package/dist/value-list-validation.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"value-list-validation.d.ts","sourceRoot":"","sources":["../src/value-list-validation.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAwCG;AACH,OAAO,EAAE,UAAU,EAAsE,gBAAgB,EAAE,MAAM,sBAAsB,CAAC;AAExI;;;;;;;;;;;;;;;;;;;;;;;;GAwBG;AACH,wBAAgB,kBAAkB,CAAC,MAAM,EAAE,UAAU,EAAE,MAAM,EAAE,gBAAgB,GAAG,IAAI,CAyBrF"}

package/dist/value-list-validation.js

@@ -0,0 +1,88 @@
+/**
+ * @fileoverview A STOPGAP for [MJ#3969](https://github.com/MemberJunction/MJ/issues/3969) — MJ does
+ * not validate value-list fields, so an `IN (…)` CHECK has no TypeScript counterpart at all.
+ *
+ * ## What is missing upstream
+ *
+ * When CodeGen meets `CHECK (Status IN ('Active','Inactive'))` it records the legal values as
+ * metadata — `EntityField.ValueListType = 'List'` plus `__mj.EntityFieldValue` rows — rather than
+ * emitting a generated `Validate()` method. That is the right call: the value list is also what the
+ * UI needs to render a dropdown, and one representation beats two.
+ *
+ * But `BaseEntity` then never reads it. `EntityField.Validate()` checks nullability, `MaxLength`,
+ * date parseability and numeric range, and stops. So this class of constraint is the one kind of
+ * schema rule with **no representation in TypeScript at all**: neither the browser nor a server
+ * subclass can preflight it, and an out-of-list value is refused only by SQL Server, as a raw
+ * constraint violation with no field attached.
+ *
+ * ## Why the dropdown is not the answer
+ *
+ * It protects the *form* path, which is presumably why nobody noticed. Every other path is
+ * unguarded — `mj sync push`, the GraphQL mutations, an Action, a subclass assigning the field in
+ * code, a data load — and those are precisely the paths where a typo is least likely to pass a human
+ * first.
+ *
+ * ## Why this is generic rather than three hand-written checks
+ *
+ * Three fields need it today (`ContractType.Status`, `ContractTemplateType.Status`,
+ * `ContractTemplateType.Status`). Naming them here would mean a fourth value-list field added next
+ * year is silently unguarded, and nothing would fail to say so. Driving off `ValueListTypeEnum`
+ * instead means the guard covers whatever the schema declares, now and later, and needs no edit when
+ * the schema changes — which is the same reason the rules it stands in for belong in MJ core.
+ *
+ * ## Deleting this
+ *
+ * When MJ#3969 lands, delete this file, drop the `ValidateValueLists(result)` call from every shared
+ * subclass, and delete `value-list-validation.test.ts`. Nothing else references it. The upstream fix
+ * produces the same errors from the same metadata, so the only observable change should be that the
+ * message is worded by MJ rather than by us.
+ *
+ * @module @mj-biz-apps/contracts-entities
+ */
+import { EntityFieldValueListType, ValidationErrorInfo, ValidationErrorType } from '@memberjunction/core';
+/**
+ * Reject any value-list field whose value is not in its list.
+ *
+ * Call it from a shared subclass's `Validate()` override, after `super.Validate()`.
+ *
+ * Three exclusions, each of which would otherwise turn this from a guard into a bug:
+ *
+ * 1. **`List` only — never `ListOrUserEntry`.** That second mode exists precisely to allow values
+ *    outside the list; validating it would reject the very thing it was chosen to permit.
+ * 2. **An empty value set validates nothing.** A field marked `List` whose `EntityFieldValue` rows
+ *    have not been seeded would otherwise reject every value including the correct one, which is a
+ *    far worse failure than the one this prevents.
+ * 3. **Null and empty are left alone.** Whether the field may be empty is the nullability check's
+ *    question, and it has already answered it by the time this runs. Answering it again would report
+ *    one mistake as two errors.
+ *
+ * Read-only and virtual fields are skipped for the same reason `EntityField.Validate()` skips them:
+ * the caller cannot set them, so refusing a save over one is a dead end with no fix available.
+ *
+ * The message lists the legal values rather than merely saying the value is invalid — a refusal that
+ * does not say what would have been accepted sends the user back to guess.
+ *
+ * @param entity - The record being validated.
+ * @param result - The accumulating result; errors are pushed onto it and `Success` cleared.
+ */
+export function ValidateValueLists(entity, result) {
+    for (const field of entity.Fields) {
+        const info = field.EntityFieldInfo;
+        if (info.ReadOnly || info.IsVirtual)
+            continue;
+        if (info.ValueListTypeEnum !== EntityFieldValueListType.List)
+            continue;
+        const allowed = info.EntityFieldValues;
+        if (!allowed || allowed.length === 0)
+            continue;
+        const value = field.Value;
+        if (value === null || value === undefined || value === '')
+            continue;
+        if (allowed.some((candidate) => candidate.Value === value))
+            continue;
+        result.Success = false;
+        result.Errors.push(new ValidationErrorInfo(info.Name, `${info.DisplayNameOrName} must be one of: ${allowed.map((candidate) => candidate.Value).join(', ')}. ` +
+            `"${String(value)}" is not one of them.`, value, ValidationErrorType.Failure));
+    }
+}
+//# sourceMappingURL=value-list-validation.js.map

package/dist/value-list-validation.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"value-list-validation.js","sourceRoot":"","sources":["../src/value-list-validation.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAwCG;AACH,OAAO,EAAc,wBAAwB,EAAE,mBAAmB,EAAE,mBAAmB,EAAoB,MAAM,sBAAsB,CAAC;AAExI;;;;;;;;;;;;;;;;;;;;;;;;GAwBG;AACH,MAAM,UAAU,kBAAkB,CAAC,MAAkB,EAAE,MAAwB;IAC3E,KAAK,MAAM,KAAK,IAAI,MAAM,CAAC,MAAM,EAAE,CAAC;QAChC,MAAM,IAAI,GAAG,KAAK,CAAC,eAAe,CAAC;QACnC,IAAI,IAAI,CAAC,QAAQ,IAAI,IAAI,CAAC,SAAS;YAAE,SAAS;QAC9C,IAAI,IAAI,CAAC,iBAAiB,KAAK,wBAAwB,CAAC,IAAI;YAAE,SAAS;QAEvE,MAAM,OAAO,GAAG,IAAI,CAAC,iBAAiB,CAAC;QACvC,IAAI,CAAC,OAAO,IAAI,OAAO,CAAC,MAAM,KAAK,CAAC;YAAE,SAAS;QAE/C,MAAM,KAAK,GAAG,KAAK,CAAC,KAAK,CAAC;QAC1B,IAAI,KAAK,KAAK,IAAI,IAAI,KAAK,KAAK,SAAS,IAAI,KAAK,KAAK,EAAE;YAAE,SAAS;QAEpE,IAAI,OAAO,CAAC,IAAI,CAAC,CAAC,SAAS,EAAE,EAAE,CAAC,SAAS,CAAC,KAAK,KAAK,KAAK,CAAC;YAAE,SAAS;QAErE,MAAM,CAAC,OAAO,GAAG,KAAK,CAAC;QACvB,MAAM,CAAC,MAAM,CAAC,IAAI,CACd,IAAI,mBAAmB,CACnB,IAAI,CAAC,IAAI,EACT,GAAG,IAAI,CAAC,iBAAiB,oBAAoB,OAAO,CAAC,GAAG,CAAC,CAAC,SAAS,EAAE,EAAE,CAAC,SAAS,CAAC,KAAK,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,IAAI;YACnG,IAAI,MAAM,CAAC,KAAK,CAAC,uBAAuB,EAC5C,KAAK,EACL,mBAAmB,CAAC,OAAO,CAC9B,CACJ,CAAC;IACN,CAAC;AACL,CAAC"}

package/package.json

@@ -0,0 +1,33 @@
+{
+  "name": "@mj-biz-apps/contracts-entities",
+  "version": "0.1.0",
+  "type": "module",
+  "description": "Generated entity subclasses for the app schema. TODO(template): rename package + description.",
+  "main": "dist/index.js",
+  "types": "dist/index.d.ts",
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/MemberJunction/bizapps-contracts"
+  },
+  "license": "BUSL-1.1",
+  "dependencies": {
+    "zod": "^3.25.76"
+  },
+  "peerDependencies": {
+    "@memberjunction/core": "^6.1.0-edge.3",
+    "@memberjunction/global": "^6.1.0-edge.3"
+  },
+  "devDependencies": {
+    "typescript": "^5.9.3"
+  },
+  "files": [
+    "/dist"
+  ],
+  "publishConfig": {
+    "access": "public"
+  },
+  "scripts": {
+    "build": "tsc && tsc-alias -f",
+    "test": "echo \"No tests configured yet\""
+  }
+}