@zeniai/client-epic-state 5.0.90-betaAR3 → 5.0.90-betaAR5

package/lib/esm/view/spendManagement/billPay/billPaySetupApproverView/billPaySetupApproverViewReducer.js

@@ -28,9 +28,11 @@ const billPaySetupApproverView = createSlice({
                 draft.error = undefined;
             },
             // Approval Rules 3.0 — `useV3` arrives from the screen connector
-            // (`approval_rule_v3_config` dynamic config) and picks the v1 vs
-            // v2 endpoint in the fetch epic.
-            prepare(cacheOverride = false, includeUserRoles = true, useV3 = false) {
+            // ('approval_rule_v3_config' dynamic config) and picks the v1
+            // vs v2 endpoint in the fetch epic. Required (no default) so a
+            // missing screen-connector wire surfaces at compile time rather
+            // than silently falling back to v1 on a v3 tenant.
+            prepare(cacheOverride = false, includeUserRoles = true, useV3) {
                 return { payload: { cacheOverride, includeUserRoles, useV3 } };
             },
         },
@@ -117,9 +119,10 @@ const billPaySetupApproverView = createSlice({
                 };
             },
             // Approval Rules 3.0 — `useV3` flows from the screen connector
-            // (`approval_rule_v3_config` dynamic config) so the delete epic
-            // can pick the v1 vs v2 endpoint.
-            prepare(approvalRuleId, useV3 = false) {
+            // ('approval_rule_v3_config' dynamic config) so the delete epic
+            // can pick the v1 vs v2 endpoint. Required (no default) so a
+            // missing connector wire surfaces at compile time.
+            prepare(approvalRuleId, useV3) {
                 return { payload: { approvalRuleId, useV3 } };
             },
         },
@@ -187,7 +190,11 @@ const billPaySetupApproverView = createSlice({
                 // reconciles any drift.
                 draft.approvalRuleIds = approvalRuleIds;
             },
-            prepare(approvalRuleIds, useV3 = false) {
+            // Approval Rules 3.0 — `useV3` required so a missing wire
+            // surfaces at compile time. The reorder epic always hits the
+            // v2 endpoint (v1 has no reorder route), but the payload still
+            // carries the flag for the failure-path refetch which needs it.
+            prepare(approvalRuleIds, useV3) {
                 return { payload: { approvalRuleIds, useV3 } };
             },
         },

package/lib/esm/view/spendManagement/billPay/billPaySetupApproverView/types/commonPayload.js

@@ -91,15 +91,20 @@ export const toApprovalChangableInfoPayload = (approverViewUpdateData) => {
     return payload;
 };
 /**
- * V1 wire mapper — used when `approval_rule_v3_config` resolves to OFF
- * for the current tenant. Translates the form-side amount criteria into
- * the legacy `{rangeType, rangeEntity, range: {min, max}}` shape. The
- * V1 backend does not understand vendor / department criteria or the
- * rule-level 3.0 fields, so those are dropped on the wire.
+ * V1 wire mapper — used when 'approval_rule_v3_config' resolves to OFF
+ * for the current tenant. Emits the legacy snake_case array shape that
+ * '/approval-rules' historically consumed (see the V1 fixture in
+ * 'entity/entityApprovalStatus/__mocks__/json/entityApprovalStatusPayload.json'):
+ *   criteria: [{type: 'range', range_entity: 'currency', min, max,
+ *               currency_code, currency_symbol}]
  *
- * The form-side amount slot is always read as a `range`-style criteria
- * here: V1 schemas only supported ranges, so an absent `min` or `max`
- * falls back to `0` / `Number.MAX_SAFE_INTEGER`.
+ * Open-ended semantics are preserved on the wire: an absent 'min' or
+ * 'max' is sent as 'null' rather than synthesised to '0' or
+ * 'MAX_SAFE_INTEGER', so a 'greater_than' / 'less_than' rule stays
+ * one-sided after rollback rather than collapsing into a closed range.
+ *
+ * The V1 backend does not understand vendor / department criteria or
+ * the rule-level 3.0 fields, so those are dropped on the wire.
  */
 export const toApprovalChangableInfoPayloadV1 = (approverViewUpdateData) => {
     const amount = approverViewUpdateData.criteria?.amount;
@@ -125,25 +130,38 @@ export const toApprovalChangableInfoPayloadV1 = (approverViewUpdateData) => {
         };
     });
     const isUpdate = approverViewUpdateData.approvalRuleId != null;
+    const minValue = minAmount?.amount ?? null;
+    const maxValue = maxAmount?.amount ?? null;
+    // Approval Rules 3.0 — guard against the both-null case. The form
+    // is expected to always set at least one bound, but if drift ever
+    // hands us a rule with no min and no max we'd otherwise emit
+    // '[{type: range, min: null, max: null, ...}]' — a payload that
+    // (a) the read-side 'legacyAmountRangeToCriteria' decodes back to
+    // '[]' (asymmetric round-trip), and (b) the V1 backend will
+    // reject anyway. Emit 'criteria: []' instead so the save fails
+    // cleanly on the server side and we leave a breadcrumb in the
+    // console for diagnosis rather than persisting mis-shaped data.
+    const criteria = [];
+    if (minValue == null && maxValue == null) {
+        console.warn('[approvalRules][V1] toApprovalChangableInfoPayloadV1: rule has ' +
+            'no amount bounds; emitting empty criteria array. The V1 backend ' +
+            'will reject this save — caller should ensure at least one bound ' +
+            'is set on the form.');
+    }
+    else {
+        criteria.push({
+            type: 'range',
+            range_entity: 'currency',
+            min: minValue,
+            max: maxValue,
+            currency_code: currencyCode,
+            currency_symbol: currencySymbol,
+        });
+    }
     const payload = {
         steps,
         is_applicable_on_pending_approval_entity: approverViewUpdateData.isApplicableOnPendingApprovalEntity ?? true,
-        criteria: {
-            rangeType: 'range',
-            rangeEntity: 'currency',
-            range: {
-                min: {
-                    amount: minAmount?.amount ?? 0,
-                    currencyCode,
-                    currencySymbol,
-                },
-                max: {
-                    amount: maxAmount?.amount ?? Number.MAX_SAFE_INTEGER,
-                    currencyCode,
-                    currencySymbol,
-                },
-            },
-        },
+        criteria,
     };
     if (isUpdate) {
         payload.approval_rule_id = approverViewUpdateData.approvalRuleId;

package/lib/esm/view/spendManagement/billPay/editBillView/epics/fetchEditBillDetailPageEpic.js

@@ -38,7 +38,10 @@ export const fetchEditBillDetailPageEpic = (actions$, state$) => actions$.pipe(f
         else {
             billDetailActions.push(updateShowAutofill(true));
         }
-        billDetailActions.push(fetchBillPaySetupApproverView(true));
+        // Side-fetch from the edit-bill page bootstrap. The triggering
+        // action doesn't carry the V3 flag, so we explicitly target v1
+        // here; tenants on v3 re-fetch through their own screen connector.
+        billDetailActions.push(fetchBillPaySetupApproverView(true, true, false));
     }
     else {
         if (state.ownerListState.fetchState !== 'In-Progress' &&
@@ -81,7 +84,10 @@ export const fetchEditBillDetailPageEpic = (actions$, state$) => actions$.pipe(f
         // While opening New Bill Refresh Approval Rules and Payment Accounts
         if (approvalViewFetchState !== 'In-Progress' &&
             approvalViewFetchState !== 'Completed') {
-            billDetailActions.push(fetchBillPaySetupApproverView(true));
+            // Side-fetch from the edit-bill page bootstrap. The triggering
+            // action doesn't carry the V3 flag, so we explicitly target v1
+            // here; tenants on v3 re-fetch through their own screen connector.
+            billDetailActions.push(fetchBillPaySetupApproverView(true, true, false));
         }
     }
     return concat(from(billDetailActions));

package/lib/esm/view/spendManagement/reimbursement/editRemiView/epics/fetchEditRemiDetailPageEpic.js

@@ -63,7 +63,11 @@ export const fetchEditRemiDetailPageEpic = (actions$, state$) => actions$.pipe(f
             const approvalRules = state.remiSetupApproverViewState;
             if (approvalRules.fetchState !== 'Completed' &&
                 approvalRules.fetchState !== 'In-Progress') {
-                remiDetailActions.push(fetchRemiSetupApproverView(true));
+                // Side-fetch from the edit-reim page bootstrap. The
+                // triggering action doesn't carry the V3 flag, so we
+                // explicitly target v1; v3 tenants re-fetch via their
+                // own screen connector.
+                remiDetailActions.push(fetchRemiSetupApproverView(true, false, false, false));
             }
         }
     }

package/lib/esm/view/spendManagement/reimbursement/remiSetupApproverView/epic/reorderRemiApprovalRulesEpic.js

@@ -33,7 +33,13 @@ export const reorderRemiApprovalRulesEpic = (actions$, _state$, zeniAPI) => acti
                     messageText: 'failed',
                     type: 'error',
                 }),
-                fetchRemiSetupApproverView(true, true, useV3),
+                // Failure-recovery refetch — match the screen connector
+                // convention '(cacheOverride, resolveAttributeToUser,
+                // includeImplicitActors, useV3)' rather than copying BillPay's
+                // 3-arg shape. With the previous useV3-as-default-false the
+                // V3 flag was being smuggled in as 'includeImplicitActors',
+                // which silently broke V3 recovery refetches.
+                fetchRemiSetupApproverView(true, false, false, useV3),
             ]);
         }
     }), catchError((error) => from([
@@ -44,6 +50,12 @@ export const reorderRemiApprovalRulesEpic = (actions$, _state$, zeniAPI) => acti
             messageText: 'failed',
             type: 'error',
         }),
-        fetchRemiSetupApproverView(true, true, useV3),
+        // Failure-recovery refetch — match the screen connector
+        // convention '(cacheOverride, resolveAttributeToUser,
+        // includeImplicitActors, useV3)' rather than copying BillPay's
+        // 3-arg shape. With the previous useV3-as-default-false the
+        // V3 flag was being smuggled in as 'includeImplicitActors',
+        // which silently broke V3 recovery refetches.
+        fetchRemiSetupApproverView(true, false, false, useV3),
     ])));
 }));

package/lib/esm/view/spendManagement/reimbursement/remiSetupApproverView/remiSetupApproverViewReducer.js

@@ -28,9 +28,10 @@ const remiSetupApproverView = createSlice({
                 draft.error = undefined;
             },
             // Approval Rules 3.0 — `useV3` arrives from the screen connector
-            // (`approval_rule_v3_config` dynamic config) and picks v1 vs v2
-            // endpoint in the fetch epic.
-            prepare(cacheOverride = false, resolveAttributeToUser = false, includeImplicitActors = false, useV3 = false) {
+            // ('approval_rule_v3_config' dynamic config) and picks v1 vs v2
+            // endpoint in the fetch epic. Required (no default) so a missing
+            // connector wire surfaces at compile time.
+            prepare(cacheOverride = false, resolveAttributeToUser = false, includeImplicitActors = false, useV3) {
                 return {
                     payload: {
                         cacheOverride,
@@ -140,9 +141,10 @@ const remiSetupApproverView = createSlice({
                 };
             },
             // Approval Rules 3.0 — `useV3` flows from the screen connector
-            // (`approval_rule_v3_config` dynamic config) so the delete epic
-            // can pick the v1 vs v2 endpoint.
-            prepare(approvalRuleId, useV3 = false) {
+            // ('approval_rule_v3_config' dynamic config) so the delete epic
+            // can pick the v1 vs v2 endpoint. Required (no default) so a
+            // missing connector wire surfaces at compile time.
+            prepare(approvalRuleId, useV3) {
                 return { payload: { approvalRuleId, useV3 } };
             },
         },
@@ -193,7 +195,9 @@ const remiSetupApproverView = createSlice({
                 }
                 draft.approvalRuleIds = approvalRuleIds;
             },
-            prepare(approvalRuleIds, useV3 = false) {
+            // Approval Rules 3.0 — `useV3` required so a missing wire
+            // surfaces at compile time. Mirror of BillPay's reorder.prepare.
+            prepare(approvalRuleIds, useV3) {
                 return { payload: { approvalRuleIds, useV3 } };
             },
         },

package/lib/view/spendManagement/billPay/billPaySetupApproverView/billPaySetupApproverViewReducer.d.ts

@@ -2,10 +2,10 @@ import { ZeniAPIStatus } from '../../../../responsePayload';
 import { BillPaySetupApproverViewState } from './billPaySetupApproverViewState';
 import { ApprovalRuleCreateData, ApprovalRuleUpdateData } from './types/commonState';
 export declare const initialState: BillPaySetupApproverViewState;
-export declare const fetchBillPaySetupApproverView: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[cacheOverride?: any, includeUserRoles?: any, useV3?: any], {
+export declare const fetchBillPaySetupApproverView: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[cacheOverride: any, includeUserRoles: any, useV3: boolean], {
     cacheOverride: any;
     includeUserRoles: any;
-    useV3: any;
+    useV3: boolean;
 }, "billPaySetupApproverView/fetchBillPaySetupApproverView", never, never>, fetchBillPaySetupApproverViewSuccess: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[approvalRuleIds: string[]], {
     approvalRuleIds: string[];
 }, "billPaySetupApproverView/fetchBillPaySetupApproverViewSuccess", never, never>, fetchBillPaySetupApproverViewFailure: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[status: ZeniAPIStatus<Record<string, unknown>>], ZeniAPIStatus<Record<string, unknown>>, "billPaySetupApproverView/fetchBillPaySetupApproverViewFailure", never, never>, fetchBillPayApproversDetails: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[cacheOverride?: any, includeUserRoles?: any], {
@@ -19,18 +19,18 @@ export declare const fetchBillPaySetupApproverView: import("@reduxjs/toolkit").A
     attributes: ("manager" | "vendor_owner" | "manager_of_manager")[];
 }, "billPaySetupApproverView/fetchBillPayApproversListSuccess", never, never>, fetchBillPayApproversListFailure: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[status: ZeniAPIStatus<Record<string, unknown>>], {
     status: ZeniAPIStatus<Record<string, unknown>>;
-}, "billPaySetupApproverView/fetchBillPayApproversListFailure", never, never>, deleteBillPayApprovalRule: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[approvalRuleId: string, useV3?: any], {
+}, "billPaySetupApproverView/fetchBillPayApproversListFailure", never, never>, deleteBillPayApprovalRule: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[approvalRuleId: string, useV3: boolean], {
     approvalRuleId: string;
-    useV3: any;
+    useV3: boolean;
 }, "billPaySetupApproverView/deleteBillPayApprovalRule", never, never>, deleteBillPayApprovalRuleSuccess: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[deletedApprovalRuleId: string, approvalRuleIds: string[]], {
     deletedApprovalRuleId: string;
     approvalRuleIds: string[];
 }, "billPaySetupApproverView/deleteBillPayApprovalRuleSuccess", never, never>, deleteBillPayApprovalRuleFailure: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[approvalRuleId: string, status: ZeniAPIStatus<Record<string, unknown>>], {
     approvalRuleId: string;
     status: ZeniAPIStatus<Record<string, unknown>>;
-}, "billPaySetupApproverView/deleteBillPayApprovalRuleFailure", never, never>, reorderBillPayApprovalRules: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[approvalRuleIds: string[], useV3?: any], {
+}, "billPaySetupApproverView/deleteBillPayApprovalRuleFailure", never, never>, reorderBillPayApprovalRules: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[approvalRuleIds: string[], useV3: boolean], {
     approvalRuleIds: string[];
-    useV3: any;
+    useV3: boolean;
 }, "billPaySetupApproverView/reorderBillPayApprovalRules", never, never>, reorderBillPayApprovalRulesSuccess: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[approvalRuleIds: string[]], {
     approvalRuleIds: string[];
 }, "billPaySetupApproverView/reorderBillPayApprovalRulesSuccess", never, never>, reorderBillPayApprovalRulesFailure: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[status: ZeniAPIStatus<Record<string, unknown>>], {

package/lib/view/spendManagement/billPay/billPaySetupApproverView/billPaySetupApproverViewReducer.js

@@ -32,9 +32,11 @@ const billPaySetupApproverView = (0, toolkit_1.createSlice)({
                 draft.error = undefined;
             },
             // Approval Rules 3.0 — `useV3` arrives from the screen connector
-            // (`approval_rule_v3_config` dynamic config) and picks the v1 vs
-            // v2 endpoint in the fetch epic.
-            prepare(cacheOverride = false, includeUserRoles = true, useV3 = false) {
+            // ('approval_rule_v3_config' dynamic config) and picks the v1
+            // vs v2 endpoint in the fetch epic. Required (no default) so a
+            // missing screen-connector wire surfaces at compile time rather
+            // than silently falling back to v1 on a v3 tenant.
+            prepare(cacheOverride = false, includeUserRoles = true, useV3) {
                 return { payload: { cacheOverride, includeUserRoles, useV3 } };
             },
         },
@@ -121,9 +123,10 @@ const billPaySetupApproverView = (0, toolkit_1.createSlice)({
                 };
             },
             // Approval Rules 3.0 — `useV3` flows from the screen connector
-            // (`approval_rule_v3_config` dynamic config) so the delete epic
-            // can pick the v1 vs v2 endpoint.
-            prepare(approvalRuleId, useV3 = false) {
+            // ('approval_rule_v3_config' dynamic config) so the delete epic
+            // can pick the v1 vs v2 endpoint. Required (no default) so a
+            // missing connector wire surfaces at compile time.
+            prepare(approvalRuleId, useV3) {
                 return { payload: { approvalRuleId, useV3 } };
             },
         },
@@ -191,7 +194,11 @@ const billPaySetupApproverView = (0, toolkit_1.createSlice)({
                 // reconciles any drift.
                 draft.approvalRuleIds = approvalRuleIds;
             },
-            prepare(approvalRuleIds, useV3 = false) {
+            // Approval Rules 3.0 — `useV3` required so a missing wire
+            // surfaces at compile time. The reorder epic always hits the
+            // v2 endpoint (v1 has no reorder route), but the payload still
+            // carries the flag for the failure-path refetch which needs it.
+            prepare(approvalRuleIds, useV3) {
                 return { payload: { approvalRuleIds, useV3 } };
             },
         },

package/lib/view/spendManagement/billPay/billPaySetupApproverView/types/commonPayload.d.ts

@@ -30,42 +30,51 @@ interface ApprovalUpdatableInfoPayload {
 }
 /**
  * V1 / pre-3.0 wire shape. Kept so the rollback flag (gated by
- * `approval_rule_v3_config` dynamic config) can target the original
- * `/approval-rules` endpoint with the legacy `{rangeType, rangeEntity, range}`
- * criteria. None of the 3.0 rule-level fields are sent.
+ * 'approval_rule_v3_config' dynamic config) can target the original
+ * '/approval-rules' endpoint with the legacy snake_case array of
+ * range entries. None of the 3.0 rule-level fields are sent.
+ *
+ * Reference: 'entityApprovalStatusPayload.json' fixture, which carries
+ * a real V1 approval rule from the legacy backend:
+ *   criteria: [{type: 'range', range_entity: 'currency',
+ *               min, max, currency_code, currency_symbol}]
+ * with 'min' / 'max' as scalar numbers and 'null' representing an
+ * absent bound for one-sided rules. The read-side mapper in
+ * 'approvalRulePayload.ts' (see 'LegacyAmountRangeCriterionPayload')
+ * decodes the same shape — write-side has to match.
  */
+interface ApprovalUpdatableInfoPayloadV1CriterionEntry {
+    currency_code: string;
+    currency_symbol: string;
+    /** Upper bound. 'null' for a 'greater_than' (open-upper) rule. */
+    max: number | null;
+    /** Lower bound. 'null' for a 'less_than' (open-lower) rule. */
+    min: number | null;
+    range_entity: 'currency';
+    type: 'range';
+}
 interface ApprovalUpdatableInfoPayloadV1 {
-    criteria: {
-        range: {
-            max: {
-                amount: number;
-                currencyCode: string;
-                currencySymbol: string;
-            };
-            min: {
-                amount: number;
-                currencyCode: string;
-                currencySymbol: string;
-            };
-        };
-        rangeEntity: 'currency';
-        rangeType: 'range';
-    };
+    criteria: ApprovalUpdatableInfoPayloadV1CriterionEntry[];
     is_applicable_on_pending_approval_entity: boolean;
     steps: ApproverViewStepPayload[];
     approval_rule_id?: ID;
 }
 export declare const toApprovalChangableInfoPayload: (approverViewUpdateData: ApprovalRuleUpdateData | ApprovalRuleCreateData) => Partial<ApprovalUpdatableInfoPayload>;
 /**
- * V1 wire mapper — used when `approval_rule_v3_config` resolves to OFF
- * for the current tenant. Translates the form-side amount criteria into
- * the legacy `{rangeType, rangeEntity, range: {min, max}}` shape. The
- * V1 backend does not understand vendor / department criteria or the
- * rule-level 3.0 fields, so those are dropped on the wire.
+ * V1 wire mapper — used when 'approval_rule_v3_config' resolves to OFF
+ * for the current tenant. Emits the legacy snake_case array shape that
+ * '/approval-rules' historically consumed (see the V1 fixture in
+ * 'entity/entityApprovalStatus/__mocks__/json/entityApprovalStatusPayload.json'):
+ *   criteria: [{type: 'range', range_entity: 'currency', min, max,
+ *               currency_code, currency_symbol}]
+ *
+ * Open-ended semantics are preserved on the wire: an absent 'min' or
+ * 'max' is sent as 'null' rather than synthesised to '0' or
+ * 'MAX_SAFE_INTEGER', so a 'greater_than' / 'less_than' rule stays
+ * one-sided after rollback rather than collapsing into a closed range.
  *
- * The form-side amount slot is always read as a `range`-style criteria
- * here: V1 schemas only supported ranges, so an absent `min` or `max`
- * falls back to `0` / `Number.MAX_SAFE_INTEGER`.
+ * The V1 backend does not understand vendor / department criteria or
+ * the rule-level 3.0 fields, so those are dropped on the wire.
  */
 export declare const toApprovalChangableInfoPayloadV1: (approverViewUpdateData: ApprovalRuleUpdateData | ApprovalRuleCreateData) => Partial<ApprovalUpdatableInfoPayloadV1>;
 export {};

package/lib/view/spendManagement/billPay/billPaySetupApproverView/types/commonPayload.js

@@ -95,15 +95,20 @@ const toApprovalChangableInfoPayload = (approverViewUpdateData) => {
 };
 exports.toApprovalChangableInfoPayload = toApprovalChangableInfoPayload;
 /**
- * V1 wire mapper — used when `approval_rule_v3_config` resolves to OFF
- * for the current tenant. Translates the form-side amount criteria into
- * the legacy `{rangeType, rangeEntity, range: {min, max}}` shape. The
- * V1 backend does not understand vendor / department criteria or the
- * rule-level 3.0 fields, so those are dropped on the wire.
+ * V1 wire mapper — used when 'approval_rule_v3_config' resolves to OFF
+ * for the current tenant. Emits the legacy snake_case array shape that
+ * '/approval-rules' historically consumed (see the V1 fixture in
+ * 'entity/entityApprovalStatus/__mocks__/json/entityApprovalStatusPayload.json'):
+ *   criteria: [{type: 'range', range_entity: 'currency', min, max,
+ *               currency_code, currency_symbol}]
  *
- * The form-side amount slot is always read as a `range`-style criteria
- * here: V1 schemas only supported ranges, so an absent `min` or `max`
- * falls back to `0` / `Number.MAX_SAFE_INTEGER`.
+ * Open-ended semantics are preserved on the wire: an absent 'min' or
+ * 'max' is sent as 'null' rather than synthesised to '0' or
+ * 'MAX_SAFE_INTEGER', so a 'greater_than' / 'less_than' rule stays
+ * one-sided after rollback rather than collapsing into a closed range.
+ *
+ * The V1 backend does not understand vendor / department criteria or
+ * the rule-level 3.0 fields, so those are dropped on the wire.
  */
 const toApprovalChangableInfoPayloadV1 = (approverViewUpdateData) => {
     const amount = approverViewUpdateData.criteria?.amount;
@@ -129,25 +134,38 @@ const toApprovalChangableInfoPayloadV1 = (approverViewUpdateData) => {
         };
     });
     const isUpdate = approverViewUpdateData.approvalRuleId != null;
+    const minValue = minAmount?.amount ?? null;
+    const maxValue = maxAmount?.amount ?? null;
+    // Approval Rules 3.0 — guard against the both-null case. The form
+    // is expected to always set at least one bound, but if drift ever
+    // hands us a rule with no min and no max we'd otherwise emit
+    // '[{type: range, min: null, max: null, ...}]' — a payload that
+    // (a) the read-side 'legacyAmountRangeToCriteria' decodes back to
+    // '[]' (asymmetric round-trip), and (b) the V1 backend will
+    // reject anyway. Emit 'criteria: []' instead so the save fails
+    // cleanly on the server side and we leave a breadcrumb in the
+    // console for diagnosis rather than persisting mis-shaped data.
+    const criteria = [];
+    if (minValue == null && maxValue == null) {
+        console.warn('[approvalRules][V1] toApprovalChangableInfoPayloadV1: rule has ' +
+            'no amount bounds; emitting empty criteria array. The V1 backend ' +
+            'will reject this save — caller should ensure at least one bound ' +
+            'is set on the form.');
+    }
+    else {
+        criteria.push({
+            type: 'range',
+            range_entity: 'currency',
+            min: minValue,
+            max: maxValue,
+            currency_code: currencyCode,
+            currency_symbol: currencySymbol,
+        });
+    }
     const payload = {
         steps,
         is_applicable_on_pending_approval_entity: approverViewUpdateData.isApplicableOnPendingApprovalEntity ?? true,
-        criteria: {
-            rangeType: 'range',
-            rangeEntity: 'currency',
-            range: {
-                min: {
-                    amount: minAmount?.amount ?? 0,
-                    currencyCode,
-                    currencySymbol,
-                },
-                max: {
-                    amount: maxAmount?.amount ?? Number.MAX_SAFE_INTEGER,
-                    currencyCode,
-                    currencySymbol,
-                },
-            },
-        },
+        criteria,
     };
     if (isUpdate) {
         payload.approval_rule_id = approverViewUpdateData.approvalRuleId;

package/lib/view/spendManagement/billPay/editBillView/epics/fetchEditBillDetailPageEpic.js

@@ -41,7 +41,10 @@ const fetchEditBillDetailPageEpic = (actions$, state$) => actions$.pipe((0, oper
         else {
             billDetailActions.push((0, editBillViewReducer_1.updateShowAutofill)(true));
         }
-        billDetailActions.push((0, billPaySetupApproverViewReducer_1.fetchBillPaySetupApproverView)(true));
+        // Side-fetch from the edit-bill page bootstrap. The triggering
+        // action doesn't carry the V3 flag, so we explicitly target v1
+        // here; tenants on v3 re-fetch through their own screen connector.
+        billDetailActions.push((0, billPaySetupApproverViewReducer_1.fetchBillPaySetupApproverView)(true, true, false));
     }
     else {
         if (state.ownerListState.fetchState !== 'In-Progress' &&
@@ -84,7 +87,10 @@ const fetchEditBillDetailPageEpic = (actions$, state$) => actions$.pipe((0, oper
         // While opening New Bill Refresh Approval Rules and Payment Accounts
         if (approvalViewFetchState !== 'In-Progress' &&
             approvalViewFetchState !== 'Completed') {
-            billDetailActions.push((0, billPaySetupApproverViewReducer_1.fetchBillPaySetupApproverView)(true));
+            // Side-fetch from the edit-bill page bootstrap. The triggering
+            // action doesn't carry the V3 flag, so we explicitly target v1
+            // here; tenants on v3 re-fetch through their own screen connector.
+            billDetailActions.push((0, billPaySetupApproverViewReducer_1.fetchBillPaySetupApproverView)(true, true, false));
         }
     }
     return (0, rxjs_1.concat)((0, rxjs_1.from)(billDetailActions));

package/lib/view/spendManagement/reimbursement/editRemiView/epics/fetchEditRemiDetailPageEpic.js

@@ -66,7 +66,11 @@ const fetchEditRemiDetailPageEpic = (actions$, state$) => actions$.pipe((0, oper
             const approvalRules = state.remiSetupApproverViewState;
             if (approvalRules.fetchState !== 'Completed' &&
                 approvalRules.fetchState !== 'In-Progress') {
-                remiDetailActions.push((0, remiSetupApproverViewReducer_1.fetchRemiSetupApproverView)(true));
+                // Side-fetch from the edit-reim page bootstrap. The
+                // triggering action doesn't carry the V3 flag, so we
+                // explicitly target v1; v3 tenants re-fetch via their
+                // own screen connector.
+                remiDetailActions.push((0, remiSetupApproverViewReducer_1.fetchRemiSetupApproverView)(true, false, false, false));
             }
         }
     }

package/lib/view/spendManagement/reimbursement/remiSetupApproverView/epic/reorderRemiApprovalRulesEpic.js

@@ -36,7 +36,13 @@ const reorderRemiApprovalRulesEpic = (actions$, _state$, zeniAPI) => actions$.pi
                     messageText: 'failed',
                     type: 'error',
                 }),
-                (0, remiSetupApproverViewReducer_1.fetchRemiSetupApproverView)(true, true, useV3),
+                // Failure-recovery refetch — match the screen connector
+                // convention '(cacheOverride, resolveAttributeToUser,
+                // includeImplicitActors, useV3)' rather than copying BillPay's
+                // 3-arg shape. With the previous useV3-as-default-false the
+                // V3 flag was being smuggled in as 'includeImplicitActors',
+                // which silently broke V3 recovery refetches.
+                (0, remiSetupApproverViewReducer_1.fetchRemiSetupApproverView)(true, false, false, useV3),
             ]);
         }
     }), (0, operators_1.catchError)((error) => (0, rxjs_1.from)([
@@ -47,7 +53,13 @@ const reorderRemiApprovalRulesEpic = (actions$, _state$, zeniAPI) => actions$.pi
             messageText: 'failed',
             type: 'error',
         }),
-        (0, remiSetupApproverViewReducer_1.fetchRemiSetupApproverView)(true, true, useV3),
+        // Failure-recovery refetch — match the screen connector
+        // convention '(cacheOverride, resolveAttributeToUser,
+        // includeImplicitActors, useV3)' rather than copying BillPay's
+        // 3-arg shape. With the previous useV3-as-default-false the
+        // V3 flag was being smuggled in as 'includeImplicitActors',
+        // which silently broke V3 recovery refetches.
+        (0, remiSetupApproverViewReducer_1.fetchRemiSetupApproverView)(true, false, false, useV3),
     ])));
 }));
 exports.reorderRemiApprovalRulesEpic = reorderRemiApprovalRulesEpic;

package/lib/view/spendManagement/reimbursement/remiSetupApproverView/remiSetupApproverViewReducer.d.ts

@@ -2,11 +2,11 @@ import { ZeniAPIStatus } from '../../../../responsePayload';
 import { ApprovalRuleCreateData, ApprovalRuleUpdateData } from '../../billPay/billPaySetupApproverView/types/commonState';
 import { RemiSetupApproverViewState } from './remiSetupApproverViewState';
 export declare const initialState: RemiSetupApproverViewState;
-export declare const fetchRemiSetupApproverView: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[cacheOverride?: any, resolveAttributeToUser?: any, includeImplicitActors?: any, useV3?: any], {
+export declare const fetchRemiSetupApproverView: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[cacheOverride: any, resolveAttributeToUser: any, includeImplicitActors: any, useV3: boolean], {
     cacheOverride: any;
     resolveAttributeToUser: any;
     includeImplicitActors: any;
-    useV3: any;
+    useV3: boolean;
 }, "remiSetupApproverView/fetchRemiSetupApproverView", never, never>, fetchRemiSetupApproverViewSuccess: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[approvalRuleIds: string[]], {
     approvalRuleIds: string[];
 }, "remiSetupApproverView/fetchRemiSetupApproverViewSuccess", never, never>, fetchRemiSetupApproverViewFailure: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[status: ZeniAPIStatus<Record<string, unknown>>], ZeniAPIStatus<Record<string, unknown>>, "remiSetupApproverView/fetchRemiSetupApproverViewFailure", never, never>, fetchRemiApproversDetails: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[cacheOverride?: any, includeUserRoles?: any, includeAttributesUserIds?: any, lastUpdatedByUserId?: any], {
@@ -25,18 +25,18 @@ export declare const fetchRemiSetupApproverView: import("@reduxjs/toolkit").Acti
     attributeSubTypeToUserIdMapping: Record<"manager" | "vendor_owner" | "manager_of_manager", string> | undefined;
 }, "remiSetupApproverView/fetchRemiApproversListSuccess", never, never>, fetchRemiApproversListFailure: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[status: ZeniAPIStatus<Record<string, unknown>>], {
     status: ZeniAPIStatus<Record<string, unknown>>;
-}, "remiSetupApproverView/fetchRemiApproversListFailure", never, never>, deleteRemiApprovalRule: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[approvalRuleId: string, useV3?: any], {
+}, "remiSetupApproverView/fetchRemiApproversListFailure", never, never>, deleteRemiApprovalRule: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[approvalRuleId: string, useV3: boolean], {
     approvalRuleId: string;
-    useV3: any;
+    useV3: boolean;
 }, "remiSetupApproverView/deleteRemiApprovalRule", never, never>, deleteRemiApprovalRuleSuccess: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[deletedApprovalRuleId: string, approvalRuleIds: string[]], {
     deletedApprovalRuleId: string;
     approvalRuleIds: string[];
 }, "remiSetupApproverView/deleteRemiApprovalRuleSuccess", never, never>, deleteRemiApprovalRuleFailure: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[approvalRuleId: string, status: ZeniAPIStatus<Record<string, unknown>>], {
     approvalRuleId: string;
     status: ZeniAPIStatus<Record<string, unknown>>;
-}, "remiSetupApproverView/deleteRemiApprovalRuleFailure", never, never>, reorderRemiApprovalRules: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[approvalRuleIds: string[], useV3?: any], {
+}, "remiSetupApproverView/deleteRemiApprovalRuleFailure", never, never>, reorderRemiApprovalRules: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[approvalRuleIds: string[], useV3: boolean], {
     approvalRuleIds: string[];
-    useV3: any;
+    useV3: boolean;
 }, "remiSetupApproverView/reorderRemiApprovalRules", never, never>, reorderRemiApprovalRulesSuccess: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[approvalRuleIds: string[]], {
     approvalRuleIds: string[];
 }, "remiSetupApproverView/reorderRemiApprovalRulesSuccess", never, never>, reorderRemiApprovalRulesFailure: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[status: ZeniAPIStatus<Record<string, unknown>>], {

package/lib/view/spendManagement/reimbursement/remiSetupApproverView/remiSetupApproverViewReducer.js

@@ -32,9 +32,10 @@ const remiSetupApproverView = (0, toolkit_1.createSlice)({
                 draft.error = undefined;
             },
             // Approval Rules 3.0 — `useV3` arrives from the screen connector
-            // (`approval_rule_v3_config` dynamic config) and picks v1 vs v2
-            // endpoint in the fetch epic.
-            prepare(cacheOverride = false, resolveAttributeToUser = false, includeImplicitActors = false, useV3 = false) {
+            // ('approval_rule_v3_config' dynamic config) and picks v1 vs v2
+            // endpoint in the fetch epic. Required (no default) so a missing
+            // connector wire surfaces at compile time.
+            prepare(cacheOverride = false, resolveAttributeToUser = false, includeImplicitActors = false, useV3) {
                 return {
                     payload: {
                         cacheOverride,
@@ -144,9 +145,10 @@ const remiSetupApproverView = (0, toolkit_1.createSlice)({
                 };
             },
             // Approval Rules 3.0 — `useV3` flows from the screen connector
-            // (`approval_rule_v3_config` dynamic config) so the delete epic
-            // can pick the v1 vs v2 endpoint.
-            prepare(approvalRuleId, useV3 = false) {
+            // ('approval_rule_v3_config' dynamic config) so the delete epic
+            // can pick the v1 vs v2 endpoint. Required (no default) so a
+            // missing connector wire surfaces at compile time.
+            prepare(approvalRuleId, useV3) {
                 return { payload: { approvalRuleId, useV3 } };
             },
         },
@@ -197,7 +199,9 @@ const remiSetupApproverView = (0, toolkit_1.createSlice)({
                 }
                 draft.approvalRuleIds = approvalRuleIds;
             },
-            prepare(approvalRuleIds, useV3 = false) {
+            // Approval Rules 3.0 — `useV3` required so a missing wire
+            // surfaces at compile time. Mirror of BillPay's reorder.prepare.
+            prepare(approvalRuleIds, useV3) {
                 return { payload: { approvalRuleIds, useV3 } };
             },
         },

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zeniai/client-epic-state",
-  "version": "5.0.90-betaAR3",
+  "version": "5.0.90-betaAR5",
   "description": "Shared module between Web & Mobile containing required abstractions for state management, async network communication. ",
   "main": "lib/index.js",
   "module": "lib/esm/index.js",