@mj-biz-apps/sales-entities 5.1.0

package/LICENSE

@@ -0,0 +1,183 @@
+Business Source License 1.1
+
+License text copyright (c) 2024 MariaDB plc, All Rights Reserved.
+"Business Source License" is a trademark of MariaDB plc.
+
+-----------------------------------------------------------------------------
+
+Parameters
+
+Licensor:             Blue Cypress, Inc.
+
+Licensed Work:        MemberJunction.
+                      The Licensed Work is (c) 2023-2026 Blue Cypress, Inc.
+
+Additional Use Grant: Subject to the terms of this License, Licensor grants
+                      you the following additional rights to make Production
+                      Use of the Licensed Work.
+
+                      1. Internal Use
+
+                      You may make production use of the Licensed Work for
+                      your own internal business or organizational operations.
+
+                      2. Nonprofit Use
+
+                      If you are a Nonprofit, you may make production use of
+                      the Licensed Work for the operations and activities of
+                      your Organizational Family.
+
+                      3. MemberJunction Certified Program Use
+
+                      If you are authorized by Licensor under the
+                      MemberJunction Certified Program to provide professional
+                      services using the Licensed Work, you may make
+                      production use of the Licensed Work in providing such
+                      professional services to a client, provided that:
+
+                      (a) the Licensed Work is deployed in, and the applicable
+                      production use occurs within, an environment owned,
+                      leased, licensed, subscribed to, or otherwise controlled
+                      by that client; and
+
+                      (b) the production use is for that client's own internal
+                      business or organizational operations or is otherwise
+                      independently permitted to that client under this
+                      Additional Use Grant.
+
+                      4. Definitions Applicable to the Additional Use Grant
+
+                      "Affiliate" means, with respect to a specified Person,
+                      any other Person that directly or indirectly Controls,
+                      is Controlled by, or is under common Control with such
+                      specified Person.
+
+                      "Control" (including the terms "Controls," "Controlled
+                      by," and "under common Control with") means the direct
+                      or indirect possession of the power to direct or cause
+                      the direction of the management and policies of a
+                      Person, whether through ownership of voting interests,
+                      by contract, or otherwise.
+
+                      "Organizational Family" means, with respect to a Person,
+                      (a) such Person and its Affiliates, and (b) any
+                      nonprofit organization, governmental entity, chapter,
+                      division, local affiliate, regional affiliate, state
+                      affiliate, national affiliate, or other entity that is
+                      formally affiliated with such Person through governing
+                      documents, a charter, bylaws, a membership agreement, or
+                      another written organizational instrument, and is
+                      recognized under such documents as part of the same
+                      organizational structure.
+
+                      "Nonprofit" means a Person recognized by the Internal
+                      Revenue Service as exempt from federal income taxation
+                      under Section 501(c)(3), 501(c)(4), 501(c)(5), or
+                      501(c)(6) of the Internal Revenue Code, or a foreign
+                      organization recognized under substantially equivalent
+                      laws.
+
+                      A Person claiming eligibility as a Nonprofit shall, upon
+                      Licensor's reasonable request, provide documentation
+                      reasonably sufficient to demonstrate that it qualifies
+                      as a Nonprofit. If such Person materially misrepresents,
+                      or is unable to demonstrate, its qualification as a
+                      Nonprofit, the rights granted to such Person under
+                      Section 2 of this Additional Use Grant shall terminate.
+
+                      "MemberJunction Certified Program" means Licensor's
+                      then-current program for certifying and authorizing a
+                      Person to provide professional services using the
+                      Licensed Work.
+
+                      "Person" means any individual, corporation, limited
+                      liability company, partnership, association, nonprofit
+                      organization, governmental entity, or other legal or
+                      organizational entity.
+
+Change Date:          Four (4) years from the date the Licensed Work is first
+                      made available.
+
+Change License:       MIT License.
+
+For information about alternative licensing arrangements for the Licensed
+Work, please contact Blue Cypress, Inc.
+
+-----------------------------------------------------------------------------
+
+Terms
+
+The Licensor hereby grants you the right to copy, modify, create derivative
+works, redistribute, and make non-production use of the Licensed Work. The
+Licensor may make an Additional Use Grant, above, permitting limited
+production use.
+
+Effective on the Change Date, or the fourth anniversary of the first publicly
+available distribution of a specific version of the Licensed Work under this
+License, whichever comes first, the Licensor hereby grants you rights under
+the terms of the Change License, and the rights granted in the paragraph
+above terminate.
+
+If your use of the Licensed Work does not comply with the requirements
+currently in effect as described in this License, you must purchase a
+commercial license from the Licensor, its affiliated entities, or authorized
+resellers, or you must refrain from using the Licensed Work.
+
+All copies of the original and modified Licensed Work, and derivative works
+of the Licensed Work, are subject to this License. This License applies
+separately for each version of the Licensed Work and the Change Date may vary
+for each version of the Licensed Work released by Licensor.
+
+You must conspicuously display this License on each original or modified copy
+of the Licensed Work. If you receive the Licensed Work in original or
+modified form from a third party, the terms and conditions set forth in this
+License apply to your use of that work.
+
+Any use of the Licensed Work in violation of this License will automatically
+terminate your rights under this License for the current and all other
+versions of the Licensed Work.
+
+This License does not grant you any right in any trademark or logo of
+Licensor or its affiliates (provided that you may use a trademark or logo of
+Licensor as expressly required by this License).
+
+TO THE EXTENT PERMITTED BY APPLICABLE LAW, THE LICENSED WORK IS PROVIDED ON
+AN "AS IS" BASIS. LICENSOR HEREBY DISCLAIMS ALL WARRANTIES AND CONDITIONS,
+EXPRESS OR IMPLIED, INCLUDING (WITHOUT LIMITATION) WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, AND
+TITLE.
+
+MariaDB hereby grants you permission to use this License's text to license
+your works, and to refer to it using the trademark "Business Source License",
+as long as you comply with the Covenants of Licensor below.
+
+-----------------------------------------------------------------------------
+
+Covenants of Licensor
+
+In consideration of the right to use this License's text and the "Business
+Source License" name and trademark, Licensor covenants to MariaDB, and to all
+other recipients of the licensed work to be provided by Licensor:
+
+1. To specify as the Change License the GPL Version 2.0 or any later version,
+   or a license that is compatible with GPL Version 2.0 or a later version,
+   where "compatible" means that software provided under the Change License
+   can be included in a program with software provided under GPL Version 2.0
+   or a later version. Licensor may specify additional Change Licenses without
+   limitation.
+
+2. To either: (a) specify an additional grant of rights to use that does not
+   impose any additional restriction on the right granted in this License, as
+   the Additional Use Grant; or (b) insert the text "None".
+
+3. To specify a Change Date.
+
+4. Not to modify this License in any other way.
+
+-----------------------------------------------------------------------------
+
+Notice
+
+The Business Source License (this document, or the "License") is not an Open
+Source license. However, the Licensed Work will eventually be made available
+under an Open Source License, as stated in this License.

package/dist/activities/activity-vocabulary.d.ts

@@ -0,0 +1,103 @@
+/**
+ * @fileoverview The activity vocabulary, and the one convention decision the whole feature turns on.
+ *
+ * Every union in this file is a CHECK constraint in `__mj_BizAppsCommon`, read off the live schema
+ * rather than guessed. They are declared as union types, not enums, so the values cross a package
+ * boundary as plain strings — and so a value the database would refuse cannot be constructed here.
+ *
+ * @module @mj-biz-apps/sales-core-entities-server
+ */
+/** `CK_Activity_Direction`. */
+export type ActivityDirection = 'Inbound' | 'Outbound' | 'Internal';
+/** `CK_Activity_Status`. */
+export type ActivityStatus = 'Logged' | 'Scheduled' | 'Completed' | 'Cancelled' | 'Failed';
+/** `CK_Activity_Source`. Sales writes `Manual` by hand and `Integration` from the ingest. */
+export type ActivitySource = 'Manual' | 'System' | 'Integration';
+/** `CK_Activity_Visibility`. */
+export type ActivityVisibility = 'Internal' | 'Private';
+/** `CK_Activity_Outcome`. Nullable — most activities have no outcome to state. */
+export type ActivityOutcome = 'Connected' | 'LeftVoicemail' | 'NoAnswer' | 'NoShow' | 'Bounced' | 'Interested' | 'NotInterested';
+/** `CK_ActivityLink_Role`. */
+export type ActivityLinkRole = 'Regarding' | 'Participant' | 'From' | 'To' | 'Cc' | 'Bcc' | 'Organizer' | 'Attendee' | 'LoggedFor';
+/** `CK_ActivityLink_IdentityKind` — the unresolved half of a link. */
+export type ActivityIdentityKind = 'Email' | 'Phone' | 'ExternalUser';
+/**
+ * The seeded `ActivityType.Code` values.
+ *
+ * RESOLVED BY CODE, NEVER BY NAME. `Code` and `Name` happen to be identical strings in today's seed
+ * (Call, Chat, Email, Meeting, Note, SMS), which is exactly why this must be explicit: a lookup written
+ * against `Name` would pass every test today and break silently the first time somebody renames the
+ * display label of a row whose code never changed. The vocabulary gate exists for this class of
+ * mistake.
+ */
+export type ActivityTypeCode = 'Call' | 'Chat' | 'Email' | 'Meeting' | 'Note' | 'SMS';
+/** Entity names. These strings are the whole dependency surface on the other two apps. */
+export declare const E_ACTIVITY = "MJ_BizApps_Common: Activities";
+export declare const E_ACTIVITY_LINK = "MJ_BizApps_Common: Activity Links";
+export declare const E_ACTIVITY_TYPE = "MJ_BizApps_Common: Activity Types";
+export declare const E_ACTIVITY_SYNC_CONNECTION = "MJ_BizApps_Common: Activity Sync Connections";
+export declare const E_ACTIVITY_SYNC_RULE = "MJ_BizApps_Common: Activity Sync Rules";
+export declare const E_CONTACT_METHOD = "MJ_BizApps_Common: Contact Methods";
+export declare const E_DEAL = "MJ_BizApps_Sales: Deals";
+export declare const E_DEAL_STATUS_TYPE = "MJ_BizApps_Sales: Deal Status Types";
+/**
+ * ─────────────────────────────────────────────────────────────────────────────────────────────────
+ *  THE LINK CONVENTION. Decided here, once, because nothing in the schema decides it.
+ * ─────────────────────────────────────────────────────────────────────────────────────────────────
+ *
+ * `SalesAccount.ID` IS `Organization.ID` and `SalesContact.ID` IS `Person.ID` — verified as real
+ * foreign keys, `FK_SalesAccount_Organization` and `FK_SalesContact_Person`, both on the `ID` column.
+ * Shared-primary-key IsA. So an `ActivityLink` to `Organizations/<id>` and one to
+ * `Sales Accounts/<id>` name **the same human or company under two different `EntityID`s**, and
+ * nothing anywhere normalizes between them.
+ *
+ * Left unpicked, that does not produce an error. It produces two half-timelines: the ingest writes
+ * one convention, a person logging a call by hand writes the other, and each view shows the half it
+ * happens to query. That is the failure this constant exists to prevent.
+ *
+ * ── THE PARTIES ARE LINKED UNDER COMMON'S ENTITIES ──
+ *
+ * Three reasons, in the order that decided it:
+ *
+ *   1. **The ingest resolves to common natively, and the alternative can fail.** A participant is
+ *      identified by matching an email address against `ContactMethod`, whose columns are `PersonID`
+ *      and `OrganizationID` — common's parents. Translating those to the sales children would be a
+ *      second lookup that can come back EMPTY: a Person with no `SalesContact` row is an ordinary
+ *      thing (any employee, any contact belonging to another app). Under a sales-child convention
+ *      that link would have to be dropped or a stub created, and the common migration explicitly
+ *      forbids auto-creating stub People. Under this convention it is simply written.
+ *
+ *   2. **The row is common's.** `Activity` lives in `__mj_BizAppsCommon`. An activity involving a
+ *      person is a fact about the person, not about their sales-contact role — and when a second app
+ *      extends `Person`, its activities point at the same rows and that human has one timeline
+ *      instead of one per app.
+ *
+ *   3. **It survives KI-1.** `AllowMultipleSubtypes` is still false on `Person` and `Organization`,
+ *      so the sales children are the only children today. A convention anchored on them would need
+ *      rewriting the day that changes; one anchored on the parents would not.
+ *
+ * ── WHAT SALES KEEPS ──
+ *
+ * The DEAL is still linked as a sales record — `MJ_BizApps_Sales: Deals`, role `Regarding`. That is
+ * the anchor every read starts from. So the split is clean rather than arbitrary: **sales owns the
+ * deal link, common owns the party links.**
+ *
+ * ── AND THE COST IS ZERO, WHICH IS WHY THIS IS NOT A TRADE-OFF ──
+ *
+ * The one argument for the sales children was that `Deal.AccountID` and `Deal.PrimaryContactID`
+ * already hold those IDs, so no translation is needed on the manual path. But because the PK is
+ * SHARED, those very same values ARE the Organization and Person IDs. `Deal.AccountID` can be used
+ * verbatim as a `RecordID` under `E_ORGANIZATION`. Nothing is converted in either direction.
+ */
+export declare const E_PERSON = "MJ_BizApps_Common: People";
+export declare const E_ORGANIZATION = "MJ_BizApps_Common: Organizations";
+/**
+ * The source-system name stamped on every ingested row, and half of the dedupe key.
+ *
+ * `UQ_Activity_External` is unique on `(SourceSystem, ExternalID)` and filtered to
+ * `WHERE ExternalID IS NOT NULL`, with `CK_Activity_External` requiring both or neither. So this
+ * string is not a label — it is a namespace, and changing it would orphan every row already ingested
+ * and re-import the lot.
+ */
+export declare const SOURCE_SYSTEM_M365 = "Microsoft365";
+//# sourceMappingURL=activity-vocabulary.d.ts.map

package/dist/activities/activity-vocabulary.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"activity-vocabulary.d.ts","sourceRoot":"","sources":["../../src/activities/activity-vocabulary.ts"],"names":[],"mappings":"AAAA;;;;;;;;GAQG;AAEH,+BAA+B;AAC/B,MAAM,MAAM,iBAAiB,GAAG,SAAS,GAAG,UAAU,GAAG,UAAU,CAAC;AAEpE,4BAA4B;AAC5B,MAAM,MAAM,cAAc,GAAG,QAAQ,GAAG,WAAW,GAAG,WAAW,GAAG,WAAW,GAAG,QAAQ,CAAC;AAE3F,6FAA6F;AAC7F,MAAM,MAAM,cAAc,GAAG,QAAQ,GAAG,QAAQ,GAAG,aAAa,CAAC;AAEjE,gCAAgC;AAChC,MAAM,MAAM,kBAAkB,GAAG,UAAU,GAAG,SAAS,CAAC;AAExD,kFAAkF;AAClF,MAAM,MAAM,eAAe,GACrB,WAAW,GACX,eAAe,GACf,UAAU,GACV,QAAQ,GACR,SAAS,GACT,YAAY,GACZ,eAAe,CAAC;AAEtB,8BAA8B;AAC9B,MAAM,MAAM,gBAAgB,GACtB,WAAW,GACX,aAAa,GACb,MAAM,GACN,IAAI,GACJ,IAAI,GACJ,KAAK,GACL,WAAW,GACX,UAAU,GACV,WAAW,CAAC;AAElB,sEAAsE;AACtE,MAAM,MAAM,oBAAoB,GAAG,OAAO,GAAG,OAAO,GAAG,cAAc,CAAC;AAEtE;;;;;;;;GAQG;AACH,MAAM,MAAM,gBAAgB,GAAG,MAAM,GAAG,MAAM,GAAG,OAAO,GAAG,SAAS,GAAG,MAAM,GAAG,KAAK,CAAC;AAEtF,0FAA0F;AAC1F,eAAO,MAAM,UAAU,kCAAkC,CAAC;AAC1D,eAAO,MAAM,eAAe,sCAAsC,CAAC;AACnE,eAAO,MAAM,eAAe,sCAAsC,CAAC;AACnE,eAAO,MAAM,0BAA0B,iDAAiD,CAAC;AACzF,eAAO,MAAM,oBAAoB,2CAA2C,CAAC;AAC7E,eAAO,MAAM,gBAAgB,uCAAuC,CAAC;AACrE,eAAO,MAAM,MAAM,4BAA4B,CAAC;AAChD,eAAO,MAAM,kBAAkB,wCAAwC,CAAC;AAExE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgDG;AACH,eAAO,MAAM,QAAQ,8BAA8B,CAAC;AACpD,eAAO,MAAM,cAAc,qCAAqC,CAAC;AAEjE;;;;;;;GAOG;AACH,eAAO,MAAM,kBAAkB,iBAAiB,CAAC"}

package/dist/activities/activity-vocabulary.js

@@ -0,0 +1,79 @@
+/**
+ * @fileoverview The activity vocabulary, and the one convention decision the whole feature turns on.
+ *
+ * Every union in this file is a CHECK constraint in `__mj_BizAppsCommon`, read off the live schema
+ * rather than guessed. They are declared as union types, not enums, so the values cross a package
+ * boundary as plain strings — and so a value the database would refuse cannot be constructed here.
+ *
+ * @module @mj-biz-apps/sales-core-entities-server
+ */
+/** Entity names. These strings are the whole dependency surface on the other two apps. */
+export const E_ACTIVITY = 'MJ_BizApps_Common: Activities';
+export const E_ACTIVITY_LINK = 'MJ_BizApps_Common: Activity Links';
+export const E_ACTIVITY_TYPE = 'MJ_BizApps_Common: Activity Types';
+export const E_ACTIVITY_SYNC_CONNECTION = 'MJ_BizApps_Common: Activity Sync Connections';
+export const E_ACTIVITY_SYNC_RULE = 'MJ_BizApps_Common: Activity Sync Rules';
+export const E_CONTACT_METHOD = 'MJ_BizApps_Common: Contact Methods';
+export const E_DEAL = 'MJ_BizApps_Sales: Deals';
+export const E_DEAL_STATUS_TYPE = 'MJ_BizApps_Sales: Deal Status Types';
+/**
+ * ─────────────────────────────────────────────────────────────────────────────────────────────────
+ *  THE LINK CONVENTION. Decided here, once, because nothing in the schema decides it.
+ * ─────────────────────────────────────────────────────────────────────────────────────────────────
+ *
+ * `SalesAccount.ID` IS `Organization.ID` and `SalesContact.ID` IS `Person.ID` — verified as real
+ * foreign keys, `FK_SalesAccount_Organization` and `FK_SalesContact_Person`, both on the `ID` column.
+ * Shared-primary-key IsA. So an `ActivityLink` to `Organizations/<id>` and one to
+ * `Sales Accounts/<id>` name **the same human or company under two different `EntityID`s**, and
+ * nothing anywhere normalizes between them.
+ *
+ * Left unpicked, that does not produce an error. It produces two half-timelines: the ingest writes
+ * one convention, a person logging a call by hand writes the other, and each view shows the half it
+ * happens to query. That is the failure this constant exists to prevent.
+ *
+ * ── THE PARTIES ARE LINKED UNDER COMMON'S ENTITIES ──
+ *
+ * Three reasons, in the order that decided it:
+ *
+ *   1. **The ingest resolves to common natively, and the alternative can fail.** A participant is
+ *      identified by matching an email address against `ContactMethod`, whose columns are `PersonID`
+ *      and `OrganizationID` — common's parents. Translating those to the sales children would be a
+ *      second lookup that can come back EMPTY: a Person with no `SalesContact` row is an ordinary
+ *      thing (any employee, any contact belonging to another app). Under a sales-child convention
+ *      that link would have to be dropped or a stub created, and the common migration explicitly
+ *      forbids auto-creating stub People. Under this convention it is simply written.
+ *
+ *   2. **The row is common's.** `Activity` lives in `__mj_BizAppsCommon`. An activity involving a
+ *      person is a fact about the person, not about their sales-contact role — and when a second app
+ *      extends `Person`, its activities point at the same rows and that human has one timeline
+ *      instead of one per app.
+ *
+ *   3. **It survives KI-1.** `AllowMultipleSubtypes` is still false on `Person` and `Organization`,
+ *      so the sales children are the only children today. A convention anchored on them would need
+ *      rewriting the day that changes; one anchored on the parents would not.
+ *
+ * ── WHAT SALES KEEPS ──
+ *
+ * The DEAL is still linked as a sales record — `MJ_BizApps_Sales: Deals`, role `Regarding`. That is
+ * the anchor every read starts from. So the split is clean rather than arbitrary: **sales owns the
+ * deal link, common owns the party links.**
+ *
+ * ── AND THE COST IS ZERO, WHICH IS WHY THIS IS NOT A TRADE-OFF ──
+ *
+ * The one argument for the sales children was that `Deal.AccountID` and `Deal.PrimaryContactID`
+ * already hold those IDs, so no translation is needed on the manual path. But because the PK is
+ * SHARED, those very same values ARE the Organization and Person IDs. `Deal.AccountID` can be used
+ * verbatim as a `RecordID` under `E_ORGANIZATION`. Nothing is converted in either direction.
+ */
+export const E_PERSON = 'MJ_BizApps_Common: People';
+export const E_ORGANIZATION = 'MJ_BizApps_Common: Organizations';
+/**
+ * The source-system name stamped on every ingested row, and half of the dedupe key.
+ *
+ * `UQ_Activity_External` is unique on `(SourceSystem, ExternalID)` and filtered to
+ * `WHERE ExternalID IS NOT NULL`, with `CK_Activity_External` requiring both or neither. So this
+ * string is not a label — it is a namespace, and changing it would orphan every row already ingested
+ * and re-import the lot.
+ */
+export const SOURCE_SYSTEM_M365 = 'Microsoft365';
+//# sourceMappingURL=activity-vocabulary.js.map

package/dist/activities/activity-vocabulary.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"activity-vocabulary.js","sourceRoot":"","sources":["../../src/activities/activity-vocabulary.ts"],"names":[],"mappings":"AAAA;;;;;;;;GAQG;AAkDH,0FAA0F;AAC1F,MAAM,CAAC,MAAM,UAAU,GAAG,+BAA+B,CAAC;AAC1D,MAAM,CAAC,MAAM,eAAe,GAAG,mCAAmC,CAAC;AACnE,MAAM,CAAC,MAAM,eAAe,GAAG,mCAAmC,CAAC;AACnE,MAAM,CAAC,MAAM,0BAA0B,GAAG,8CAA8C,CAAC;AACzF,MAAM,CAAC,MAAM,oBAAoB,GAAG,wCAAwC,CAAC;AAC7E,MAAM,CAAC,MAAM,gBAAgB,GAAG,oCAAoC,CAAC;AACrE,MAAM,CAAC,MAAM,MAAM,GAAG,yBAAyB,CAAC;AAChD,MAAM,CAAC,MAAM,kBAAkB,GAAG,qCAAqC,CAAC;AAExE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgDG;AACH,MAAM,CAAC,MAAM,QAAQ,GAAG,2BAA2B,CAAC;AACpD,MAAM,CAAC,MAAM,cAAc,GAAG,kCAAkC,CAAC;AAEjE;;;;;;;GAOG;AACH,MAAM,CAAC,MAAM,kBAAkB,GAAG,cAAc,CAAC"}

package/dist/close-lock.d.ts

@@ -0,0 +1,72 @@
+/**
+ * @fileoverview The close lock's field rule, in ONE place.
+ *
+ * WHY THIS IS NOT A PRIVATE STATIC ANY MORE. The lock is enforced in
+ * `DealEntityServer.Save()` — deliberately, so an Action, an agent and a raw `BaseEntity.Save()` all hit
+ * the same wall (master plan §7.3, L-17). But the Explorer form has to know the SAME rule to be usable:
+ * a form that presents a frozen field as editable invites someone to type into it, press Save, and be
+ * refused by the server. That is a correct refusal delivered at the worst possible moment.
+ *
+ * Two copies of this list would drift, and the drift would be invisible until a user hit it — the form
+ * would offer a field the server refuses, or grey out one it would have accepted. So the server reads
+ * this and the form reads this, and there is nothing to keep in sync.
+ *
+ * It lives in `sales-entities` because that is the only package both the entity server and the Angular
+ * layer already depend on.
+ *
+ * ── THE RULE ────────────────────────────────────────────────────────────────────────────────────
+ *
+ * When a deal enters a status whose `DealStatusType.LocksDeal` is set, the deal, its lines and its team
+ * become immutable — **except** for these fields. The lock is field-by-field rather than a wall because
+ * a closed deal still needs notes: someone has to be able to write "customer asked about renewal"
+ * without reopening the deal and falsifying its provenance. Everything a contract or an order was
+ * derived from is frozen.
+ *
+ * Reopening is the one audited way back through, via `Sales.ReopenDeal`, which records a reason.
+ *
+ * @module @mj-biz-apps/sales-entities
+ */
+import { type UserInfo } from '@memberjunction/core';
+/**
+ * The deal fields that stay editable while the deal is locked.
+ *
+ * Pinned by integration check CD14, which closes a deal and then proves each of these is genuinely
+ * accepted and that a field outside the set is genuinely refused — so this constant cannot quietly
+ * stop describing what the server does.
+ */
+export declare const DEAL_FIELDS_EDITABLE_WHILE_LOCKED: ReadonlySet<string>;
+/**
+ * Whether `fieldName` may still be edited on a locked deal.
+ *
+ * Callers should prefer this to reaching into the set, so the membership test stays in one place if the
+ * rule ever grows a condition beyond simple membership.
+ */
+export declare function IsDealFieldEditableWhileLocked(fieldName: string): boolean;
+/** What a surface needs to know to render the lock: whether it is on, and what to say about it. */
+export interface DealLockState {
+    IsLocked: boolean;
+    /** The status' display name, for the notice. Null when not locked. */
+    StatusName: string | null;
+    /** A ready-to-render explanation, or null when the deal is open. */
+    Notice: string | null;
+}
+/**
+ * Resolves whether a PERSISTED status locks the deal.
+ *
+ * ── WHY THE LOOKUP IS SHARED, NOT JUST THE FIELD LIST ───────────────────────────────────────────
+ *
+ * Sharing `DEAL_FIELDS_EDITABLE_WHILE_LOCKED` alone would still leave two copies of the more subtle
+ * half — *how you decide a deal is locked at all*: read `LocksDeal` off the status ROW, by FLAG, and
+ * off the **persisted** status rather than whatever the user just picked in a dropdown. Both of those
+ * are easy to get quietly wrong in a second implementation, and a surface that resolved the lock from
+ * the pending status would unlock a deal the moment someone changed the dropdown.
+ *
+ * So every surface calls this. The Explorer record form and the deal workspace now share one answer.
+ *
+ * Reads the FLAG, never a status name — a deployment may call its winning status "Signed" (§3).
+ *
+ * @param persistedStatusID - `DealStatusTypeID`'s **OldValue**, not its current value.
+ * @param contextUser - Server callers must pass one; the browser omits it.
+ */
+export declare function ResolveDealLockState(persistedStatusID: string | null | undefined, contextUser?: UserInfo): Promise<DealLockState>;
+//# sourceMappingURL=close-lock.d.ts.map

package/dist/close-lock.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"close-lock.d.ts","sourceRoot":"","sources":["../src/close-lock.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2BG;AACH,OAAO,EAAW,KAAK,QAAQ,EAAE,MAAM,sBAAsB,CAAC;AAE9D;;;;;;GAMG;AACH,eAAO,MAAM,iCAAiC,EAAE,WAAW,CAAC,MAAM,CAGhE,CAAC;AAEH;;;;;GAKG;AACH,wBAAgB,8BAA8B,CAAC,SAAS,EAAE,MAAM,GAAG,OAAO,CAEzE;AAKD,mGAAmG;AACnG,MAAM,WAAW,aAAa;IAC1B,QAAQ,EAAE,OAAO,CAAC;IAClB,sEAAsE;IACtE,UAAU,EAAE,MAAM,GAAG,IAAI,CAAC;IAC1B,oEAAoE;IACpE,MAAM,EAAE,MAAM,GAAG,IAAI,CAAC;CACzB;AAED;;;;;;;;;;;;;;;;;GAiBG;AACH,wBAAsB,oBAAoB,CACtC,iBAAiB,EAAE,MAAM,GAAG,IAAI,GAAG,SAAS,EAC5C,WAAW,CAAC,EAAE,QAAQ,GACvB,OAAO,CAAC,aAAa,CAAC,CA6BxB"}

package/dist/close-lock.js

@@ -0,0 +1,94 @@
+/**
+ * @fileoverview The close lock's field rule, in ONE place.
+ *
+ * WHY THIS IS NOT A PRIVATE STATIC ANY MORE. The lock is enforced in
+ * `DealEntityServer.Save()` — deliberately, so an Action, an agent and a raw `BaseEntity.Save()` all hit
+ * the same wall (master plan §7.3, L-17). But the Explorer form has to know the SAME rule to be usable:
+ * a form that presents a frozen field as editable invites someone to type into it, press Save, and be
+ * refused by the server. That is a correct refusal delivered at the worst possible moment.
+ *
+ * Two copies of this list would drift, and the drift would be invisible until a user hit it — the form
+ * would offer a field the server refuses, or grey out one it would have accepted. So the server reads
+ * this and the form reads this, and there is nothing to keep in sync.
+ *
+ * It lives in `sales-entities` because that is the only package both the entity server and the Angular
+ * layer already depend on.
+ *
+ * ── THE RULE ────────────────────────────────────────────────────────────────────────────────────
+ *
+ * When a deal enters a status whose `DealStatusType.LocksDeal` is set, the deal, its lines and its team
+ * become immutable — **except** for these fields. The lock is field-by-field rather than a wall because
+ * a closed deal still needs notes: someone has to be able to write "customer asked about renewal"
+ * without reopening the deal and falsifying its provenance. Everything a contract or an order was
+ * derived from is frozen.
+ *
+ * Reopening is the one audited way back through, via `Sales.ReopenDeal`, which records a reason.
+ *
+ * @module @mj-biz-apps/sales-entities
+ */
+import { RunView } from '@memberjunction/core';
+/**
+ * The deal fields that stay editable while the deal is locked.
+ *
+ * Pinned by integration check CD14, which closes a deal and then proves each of these is genuinely
+ * accepted and that a field outside the set is genuinely refused — so this constant cannot quietly
+ * stop describing what the server does.
+ */
+export const DEAL_FIELDS_EDITABLE_WHILE_LOCKED = new Set([
+    'Description',
+    'NextStep',
+]);
+/**
+ * Whether `fieldName` may still be edited on a locked deal.
+ *
+ * Callers should prefer this to reaching into the set, so the membership test stays in one place if the
+ * rule ever grows a condition beyond simple membership.
+ */
+export function IsDealFieldEditableWhileLocked(fieldName) {
+    return DEAL_FIELDS_EDITABLE_WHILE_LOCKED.has(fieldName);
+}
+/** Sales' deal-status type table. Named here so the lock lookup below has one spelling of it. */
+const E_DEAL_STATUS_TYPE = 'MJ_BizApps_Sales: Deal Status Types';
+/**
+ * Resolves whether a PERSISTED status locks the deal.
+ *
+ * ── WHY THE LOOKUP IS SHARED, NOT JUST THE FIELD LIST ───────────────────────────────────────────
+ *
+ * Sharing `DEAL_FIELDS_EDITABLE_WHILE_LOCKED` alone would still leave two copies of the more subtle
+ * half — *how you decide a deal is locked at all*: read `LocksDeal` off the status ROW, by FLAG, and
+ * off the **persisted** status rather than whatever the user just picked in a dropdown. Both of those
+ * are easy to get quietly wrong in a second implementation, and a surface that resolved the lock from
+ * the pending status would unlock a deal the moment someone changed the dropdown.
+ *
+ * So every surface calls this. The Explorer record form and the deal workspace now share one answer.
+ *
+ * Reads the FLAG, never a status name — a deployment may call its winning status "Signed" (§3).
+ *
+ * @param persistedStatusID - `DealStatusTypeID`'s **OldValue**, not its current value.
+ * @param contextUser - Server callers must pass one; the browser omits it.
+ */
+export async function ResolveDealLockState(persistedStatusID, contextUser) {
+    const open = { IsLocked: false, StatusName: null, Notice: null };
+    if (!persistedStatusID) {
+        return open;
+    }
+    const result = await new RunView().RunView({
+        EntityName: E_DEAL_STATUS_TYPE,
+        ExtraFilter: `ID = '${String(persistedStatusID).replace(/'/g, "''")}'`,
+        ResultType: 'simple',
+        Fields: ['LocksDeal', 'Name'],
+    }, contextUser);
+    const row = result?.Success ? (result.Results ?? [])[0] : undefined;
+    if (!row?.LocksDeal) {
+        return open;
+    }
+    const editable = [...DEAL_FIELDS_EDITABLE_WHILE_LOCKED].join(' and ');
+    return {
+        IsLocked: true,
+        StatusName: row.Name,
+        Notice: `This deal is closed (${row.Name}) and locked. A contract or an order was derived from it, so ` +
+            `its terms are frozen — only ${editable} can still be changed. To change anything else, reopen ` +
+            'the deal, which records a reason.',
+    };
+}
+//# sourceMappingURL=close-lock.js.map

package/dist/close-lock.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"close-lock.js","sourceRoot":"","sources":["../src/close-lock.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2BG;AACH,OAAO,EAAE,OAAO,EAAiB,MAAM,sBAAsB,CAAC;AAE9D;;;;;;GAMG;AACH,MAAM,CAAC,MAAM,iCAAiC,GAAwB,IAAI,GAAG,CAAS;IAClF,aAAa;IACb,UAAU;CACb,CAAC,CAAC;AAEH;;;;;GAKG;AACH,MAAM,UAAU,8BAA8B,CAAC,SAAiB;IAC5D,OAAO,iCAAiC,CAAC,GAAG,CAAC,SAAS,CAAC,CAAC;AAC5D,CAAC;AAED,iGAAiG;AACjG,MAAM,kBAAkB,GAAG,qCAAqC,CAAC;AAWjE;;;;;;;;;;;;;;;;;GAiBG;AACH,MAAM,CAAC,KAAK,UAAU,oBAAoB,CACtC,iBAA4C,EAC5C,WAAsB;IAEtB,MAAM,IAAI,GAAkB,EAAE,QAAQ,EAAE,KAAK,EAAE,UAAU,EAAE,IAAI,EAAE,MAAM,EAAE,IAAI,EAAE,CAAC;IAChF,IAAI,CAAC,iBAAiB,EAAE,CAAC;QACrB,OAAO,IAAI,CAAC;IAChB,CAAC;IAED,MAAM,MAAM,GAAG,MAAM,IAAI,OAAO,EAAE,CAAC,OAAO,CACtC;QACI,UAAU,EAAE,kBAAkB;QAC9B,WAAW,EAAE,SAAS,MAAM,CAAC,iBAAiB,CAAC,CAAC,OAAO,CAAC,IAAI,EAAE,IAAI,CAAC,GAAG;QACtE,UAAU,EAAE,QAAQ;QACpB,MAAM,EAAE,CAAC,WAAW,EAAE,MAAM,CAAC;KAChC,EACD,WAAW,CACd,CAAC;IACF,MAAM,GAAG,GAAG,MAAM,EAAE,OAAO,CAAC,CAAC,CAAC,CAAC,MAAM,CAAC,OAAO,IAAI,EAAE,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,SAAS,CAAC;IACpE,IAAI,CAAC,GAAG,EAAE,SAAS,EAAE,CAAC;QAClB,OAAO,IAAI,CAAC;IAChB,CAAC;IAED,MAAM,QAAQ,GAAG,CAAC,GAAG,iCAAiC,CAAC,CAAC,IAAI,CAAC,OAAO,CAAC,CAAC;IACtE,OAAO;QACH,QAAQ,EAAE,IAAI;QACd,UAAU,EAAE,GAAG,CAAC,IAAI;QACpB,MAAM,EACF,wBAAwB,GAAG,CAAC,IAAI,+DAA+D;YAC/F,+BAA+B,QAAQ,yDAAyD;YAChG,mCAAmC;KAC1C,CAAC;AACN,CAAC"}