@zeniai/client-epic-state 5.2.54-betaRD1 → 5.2.55

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

@@ -0,0 +1,102 @@
+"use strict";
+var __importDefault = (this && this.__importDefault) || function (mod) {
+    return (mod && mod.__esModule) ? mod : { "default": mod };
+};
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.applyBillRecommendationsToLocalStoreEpic = void 0;
+const get_1 = __importDefault(require("lodash/get"));
+const rxjs_1 = require("rxjs");
+const operators_1 = require("rxjs/operators");
+const accountListSelector_1 = require("../../../../accountList/accountListSelector");
+const classListSelector_1 = require("../../../../classList/classListSelector");
+const billDetailViewReducer_1 = require("../../billDetailView/billDetailViewReducer");
+const billDetailViewState_1 = require("../../billDetailView/billDetailViewState");
+const editBillViewReducer_1 = require("../editBillViewReducer");
+const initializeBillToLocalStoreEpic_1 = require("./initializeBillToLocalStoreEpic");
+/**
+ * Back-fills the edit local store once the standalone recommendations fetch
+ * resolves. `initializeBillToLocalStore` reads `transaction.recommendations`
+ * exactly once and is guarded against re-running, so the recommendation-derived
+ * line data (category/class autofill, `recommendedCategory` / `recommendedClass`
+ * behind the "update to" checkbox) has to be recomputed here instead.
+ *
+ * Recomputes from the entity lines with the same helper the initializer uses, so
+ * an untouched line ends up exactly as it would have had the recommendations
+ * been present at init time.
+ */
+const applyBillRecommendationsToLocalStoreEpic = (actions$, state$) => actions$.pipe((0, operators_1.filter)(billDetailViewReducer_1.fetchBillRecommendationsSuccess.match), 
+// The skip paths resolve the status without fetching — a draft whose
+// recommendations came on the bill detail response, or a stage that is not
+// served any. `initializeBillToLocalStore` has already read those, so
+// recomputing here would only reset the line's "update to" selections.
+(0, operators_1.filter)((action) => action.payload.didWriteRecommendations), (0, operators_1.mergeMap)((action) => {
+    const { billId } = action.payload;
+    const state = state$.value;
+    const key = (0, billDetailViewState_1.getBillTransactionDetailKey)(billId);
+    const editBillState = (0, get_1.default)(state.editBillDetailViewState.editBillStateById, key, undefined);
+    const transaction = (0, get_1.default)(state.billTransactionState.transactionById, billId, undefined);
+    const recommendations = transaction?.recommendations;
+    if (editBillState == null ||
+        transaction == null ||
+        transaction.lines == null ||
+        recommendations == null ||
+        Object.keys(recommendations).length === 0) {
+        return rxjs_1.EMPTY;
+    }
+    const localData = editBillState.billDetailLocalData;
+    // The recommendations were requested for the vendor on the bill. If the
+    // user has since switched vendors, `fetchVendorAndUpdateBillLocalData`
+    // owns the line data and these are stale — leave it alone.
+    //
+    // Both sides are QBO ids despite the field names suggesting otherwise.
+    // `transaction.vendor` is built by `mapVendorBasePayloadToVendorBase`,
+    // whose id is `getVendorPayloadIdentifier` = `vendor_id ?? qbo_id`, and
+    // on a bill transaction payload `vendor_id` IS the QBO id — the Zeni id
+    // rides separately as `zeni_vendor_id`. Verified against live DEV and QA
+    // responses, both of which have `vendor_id === qbo_vendor_id`.
+    if (localData.vendor?.qboId !== transaction.vendor?.id) {
+        return rxjs_1.EMPTY;
+    }
+    const accountList = (0, accountListSelector_1.getAccountList)(state.accountState, state.accountListState, 'billPayAccountList');
+    const classList = (0, classListSelector_1.getClassList)(state.classState, state.classListState);
+    const updatesByLineId = {};
+    transaction.lines.forEach((line) => {
+        // A line whose category/class the user already set keeps their input.
+        const localLine = localData.updatesByLineId[line.id];
+        if (localLine?.isCategoryOrClassUpdated) {
+            return;
+        }
+        // The helper spreads whatever line it is given into its result, and
+        // the reducer replaces the entry wholesale, so the local line has to
+        // go in or edits that leave `isCategoryOrClassUpdated` untouched — an
+        // amount or description changed while this fetch was in flight — get
+        // reverted.
+        //
+        // Category and class are the exception and come from the ENTITY line,
+        // exactly as at init. By now the local line may hold a category the
+        // vendor default autofilled when no recommendation was available yet,
+        // and the helper reads whatever it is given as the line's original
+        // value and will not replace one. Passing that back would leave an
+        // untouched line on the vendor default instead of the per-line
+        // recommendation, so the back-fill would not match what init would
+        // have produced had the recommendations been there all along.
+        const localLineWithEntityCategory = localLine == null || hasAccountAndClass(line) === false
+            ? line
+            : {
+                ...localLine,
+                account: line.account,
+                class: line.class,
+            };
+        updatesByLineId[line.id] = (0, initializeBillToLocalStoreEpic_1.getLineRecommendationsLocalData)(line.id, localLineWithEntityCategory, recommendations, accountList, classList, localData.vendor);
+    });
+    if (Object.keys(updatesByLineId).length === 0) {
+        return rxjs_1.EMPTY;
+    }
+    return (0, rxjs_1.of)((0, editBillViewReducer_1.updateBillLineRecommendationsInLocalStore)(billId, updatesByLineId));
+}));
+exports.applyBillRecommendationsToLocalStoreEpic = applyBillRecommendationsToLocalStoreEpic;
+// Only some `Line` members carry a category and class. A guard rather than a
+// cast so a shape change is a compile error, not a silent `undefined`.
+function hasAccountAndClass(line) {
+    return 'account' in line;
+}

package/package.json

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

package/lib/esm/view/expenseAutomationView/epics/jeSchedule/fetchFailedJePostingsEpic.js

@@ -1,39 +0,0 @@
-import { from, of } from 'rxjs';
-import { catchError, filter, switchMap, takeUntil } from 'rxjs/operators';
-import { updateJESchedules, updateJESchedulesDetails, } from '../../../../entity/jeSchedules/jeSchedulesReducer';
-import { createZeniAPIStatus, isSuccessResponse, } from '../../../../responsePayload';
-import { clearAll } from '../../../../rootActions';
-import { fetchFailedJePostings, fetchFailedJePostingsFailure, fetchFailedJePostingsSuccess, initializeJeScheduleLocalData, } from '../../reducers/jeSchedulesViewReducer';
-/**
- * Fetches every currently-failing posting for the tenant, on its own endpoint and with no window.
- *
- * Sends no query at all. The endpoint takes an optional `expected_post_start_date` floor and the
- * client deliberately omits it: a failure is outstanding work until someone resolves it, whatever
- * month it belongs to, and windowing this list is exactly what kept older failures off the only
- * screen that can resolve them.
- *
- * `switchMap`, not `mergeMap`: there is one list per tenant, so a second trigger supersedes the
- * first rather than racing it.
- */
-export const fetchFailedJePostingsEpic = (actions$, _state$, zeniAPI) => actions$.pipe(filter(fetchFailedJePostings.match), switchMap(() => zeniAPI
-    .getJSON(`${zeniAPI.apiEndPoints.accountMicroServiceBaseUrl}/1.0/expenses_automation/failed_je_postings`)
-    .pipe(switchMap((response) => {
-    if (!isSuccessResponse(response) || response.data == null) {
-        return of(fetchFailedJePostingsFailure(response.status));
-    }
-    const { je_schedules: failedJeSchedules, scheduled_journal_entries: failedScheduledJournalEntries, } = response.data.failed_je_postings;
-    // Order matters and matches fetchJeSchedulesEpic: updateJESchedules fans out to the
-    // vendor / account / class / user entities, updateJESchedulesDetails then attaches the
-    // journal entries, and only then can initializeJeScheduleLocalData read them back.
-    return from([
-        updateJESchedules(failedJeSchedules),
-        updateJESchedulesDetails(failedJeSchedules, failedScheduledJournalEntries),
-        initializeJeScheduleLocalData(failedJeSchedules),
-        fetchFailedJePostingsSuccess(failedJeSchedules, failedScheduledJournalEntries),
-    ]);
-}), catchError((error) => of(fetchFailedJePostingsFailure(createZeniAPIStatus('Unexpected Error', 'fetch failed JE postings REST API call errored out' +
-    JSON.stringify(error))))), 
-// A tenant switch clears the store while this request is still in flight. Without this
-// the old tenant's rows are written back into the freshly cleared store and stay on
-// screen under the new tenant until a manual refresh.
-takeUntil(actions$.pipe(filter(clearAll.match))))));