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

package/lib/view/invoicing/editInvoicingCatalogItemDetailView/invoicingCatalogItemFormHelper.d.ts

@@ -1,12 +1,12 @@
 import { InvoicingPlan } from '../../../entity/invoicing/plan/planState';
-import { InvoicingProduct } from '../../../entity/invoicing/product/productState';
+import { InvoicingCatalogPricingModel, InvoicingProduct } from '../../../entity/invoicing/product/productState';
 import { InvoicingCatalogItemFormLocalData, InvoicingCatalogItemFormSubFamily, InvoicingCatalogItemFormTier } from './editInvoicingCatalogItemDetailViewState';
 /**
  * Value sets the catalog item form still owns locally: the backend has no enum
  * for pricing model, tier type, proration or applicability yet, so these stay
  * here until it does. Everything else on this form comes from `/1.0/config`.
  */
-export declare const INVOICING_CATALOG_PRICING_MODEL_VALUES: readonly ["flat_fee", "per_unit", "tiered", "volume", "stairstep"];
+export declare const INVOICING_CATALOG_PRICING_MODEL_VALUES: readonly InvoicingCatalogPricingModel[];
 export declare const INVOICING_CATALOG_TIER_TYPE_VALUES: readonly ["per_unit", "flat_fee", "package"];
 export declare const INVOICING_CATALOG_PRORATION_VALUES: readonly ["site_default", "partial_term", "full_term"];
 export declare const INVOICING_CATALOG_APPLICABILITY_VALUES: readonly ["all", "restricted"];

package/lib/view/invoicing/editInvoicingCatalogItemDetailView/invoicingCatalogItemFormHelper.js

@@ -6,13 +6,7 @@ exports.entityToInvoicingCatalogItemFormLocalData = exports.initialInvoicingCata
  * for pricing model, tier type, proration or applicability yet, so these stay
  * here until it does. Everything else on this form comes from `/1.0/config`.
  */
-exports.INVOICING_CATALOG_PRICING_MODEL_VALUES = [
-    'flat_fee',
-    'per_unit',
-    'tiered',
-    'volume',
-    'stairstep',
-];
+exports.INVOICING_CATALOG_PRICING_MODEL_VALUES = ['flat_fee', 'per_unit', 'tiered', 'volume', 'stairstep'];
 exports.INVOICING_CATALOG_TIER_TYPE_VALUES = [
     'per_unit',
     'flat_fee',

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zeniai/client-epic-state",
-  "version": "5.2.54-betaRD1",
+  "version": "5.2.54",
   "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))))));