tin-spa 20.14.29 → 20.14.32

package/fesm2022/tin-spa.mjs

@@ -375,7 +375,22 @@ class Core {
         return false;
     }
     static getInitialValue(field) {
-        if (field.defaultValue) {
+        // Changed (E21): was `if (field.defaultValue)` — a TRUTHINESS test, so a deliberately falsy default
+        // (0, false, '') was silently ignored and the field fell through to the type default below. For most
+        // types that is harmless, because the fallthrough happens to land on the same value anyway (number -> 0,
+        // checkbox -> false, text -> ''). For a SELECT it is not: the fallthrough is `return null`, and a null
+        // posted into a non-nullable backend enum is rejected at model binding with an HTTP 400 that the user
+        // sees as the generic "Something went wrong ... a technical problem in the app" panel
+        // (api-error.service.ts:138-144). Nothing is logged server-side, because a binding failure is not an
+        // exception — which is exactly why this stayed hidden through a 124k-line API log.
+        //
+        // Measured before changing it: across ng-space and all four consumer apps exactly 11 fields declare a
+        // falsy defaultValue. Seven are number/money/checkbox and are unaffected, their fallthrough already
+        // producing the same value. The other four are selects that asked for 0 and were silently getting null:
+        // accounting.service.ts:152 itemType, :574 kind, assets.service.ts:25 defaultDepreciationMethod and
+        // :115 disposalType — three of them required, so users were being made to re-pick a value the config had
+        // already chosen for them. This is therefore behaviour-neutral everywhere except where it repairs a bug.
+        if (field.defaultValue !== undefined && field.defaultValue !== null) {
             if ((field.type == 'date' || field.type == 'datetime') && field.defaultValue == 'now')
                 return this.nowDate(true);
             return field.defaultValue;
@@ -6766,7 +6781,13 @@ class AccountingService {
                 { name: 'code', type: 'text', alias: 'Account Code', section: 'classification', infoMessage: 'Chart of accounts code (1xxx assets, 2xxx liabilities, 3xxx equity, 4xxx revenue, 5xxx expenses)' }, // Changed: COA code (B1); moved into the collapsed section
                 { name: 'includeInCashTotal', type: 'checkbox', alias: 'Include in Cash Total', section: 'classification', hidden: (data) => data.type !== 0 }, // Changed: Only visible for Asset accounts (type 0)
                 { name: 'includeInBankTotal', type: 'checkbox', alias: 'Include in Bank Total', section: 'classification', hidden: (data) => data.type !== 0 }, // Changed: Only visible for Asset accounts (type 0)
-                { name: 'cashFlow', type: 'select', alias: 'Cash Flow Section', section: 'classification', infoMessage: 'IAS 7 cash flow statement classification', // Changed: C5 cash flow category
+                // Changed (E21): defaultValue added. An untouched select initialises to null (TinCore.getInitialValue
+                // `case 'select': return null`), and Account.CashFlow is a NON-NULLABLE CashFlowCategory, so creating an
+                // account without opening this collapsed section posted cashFlow:null and was rejected at model binding
+                // with a 400 — surfaced to the user as "Something went wrong ... a technical problem in the app" and
+                // logged nowhere. 0 is Operating, which is the model's own C# default (Account.cs:69), so this makes the
+                // form agree with the entity rather than inventing a value.
+                { name: 'cashFlow', type: 'select', alias: 'Cash Flow Section', section: 'classification', defaultValue: 0, infoMessage: 'IAS 7 cash flow statement classification', // Changed: C5 cash flow category
                     options: [
                         { name: 'Operating', value: 0 },
                         { name: 'Investing', value: 1 },
@@ -17362,6 +17383,7 @@ class TableComponent {
         this.apiErrorService = apiErrorService;
         this.runtimeConfig = runtimeConfig;
         this.subs = []; // TS-8: breakpoint + parent-owned reload subscriptions leaked on table teardown; stacked reload subs also caused duplicate loadData fetches
+        this.initialized = false; // Added: guards ensureInitialized — initialization must happen exactly once, whichever hook reaches it first
         this.elevation = "mat-elevation-z5";
         this.actionsWidth = "50px";
         // Added: collapsible flat section header (sectionConfig) — Day Book sections
@@ -17465,6 +17487,17 @@ class TableComponent {
         }));
     }
     ngOnInit() {
+        this.ensureInitialized(); // Changed: the body moved to ensureInitialized so ngOnChanges can pull it forward when it has to start a load first
+    }
+    // Added: Angular runs ngOnChanges BEFORE ngOnInit on the first pass. A lazy tab that is already active on the
+    // first binding (a details dialog's tableConfigs[0]) therefore started its load from ngOnChanges while
+    // setupPagination() had not yet run, so pagedMode was still false and the rows landed on the legacy path;
+    // ngOnInit then flipped pagedMode on and the next updateSlice() drew from the empty loadedRows window and
+    // replaced the good rows with nothing. Initialization is now idempotent so the load site can order it first.
+    ensureInitialized() {
+        if (this.initialized)
+            return;
+        this.initialized = true;
         this.sectionCollapsed = !!this.config?.sectionConfig?.collapsed; // Added: seed section collapse from config — state lives on the component, never written back to the shared config
         if (this.config?.formConfig) {
             this.hasFormAccess = Core.hasFormAccess(this.config.formConfig, this.authService.currentRoleSource.value);
@@ -17487,6 +17520,7 @@ class TableComponent {
         }
         if (this.inTab && changes['activeTab']) {
             if (!this.hasBeenActivated && this.activeTab && this.config?.lazyLoad && this.config.loadAction) {
+                this.ensureInitialized(); // Changed: this is the ONLY load ngOnChanges can start, and it must not run ahead of setupPagination() — see ensureInitialized
                 this.loadData(this.config.loadAction, "");
                 this.hasBeenActivated = true;
             }
@@ -18548,13 +18582,17 @@ class TableComponent {
             return "mat-elevation-z5";
         }
     }
-    // Changed: Real-time tables fall back to a refresh when SignalR is disconnected.
+    // Changed: this now ALWAYS refreshes. The old body refreshed only when realTime was OFF or SignalR was DOWN,
+    // so a healthy real-time table did nothing after a write and simply waited for a broadcast. But the SignalR
+    // streams below are filtered on this table's own entityName, and an action that writes a DIFFERENT entity
+    // (invoicing a rental writes an Invoice) never emits a matching one — grip's rentals grid kept rendering
+    // "Returned" for a row already Invoiced in the database. Nothing correlates a broadcast back to the action
+    // just performed, so "refresh unless a broadcast arrives" is not implementable without new machinery.
+    // A same-URL re-read after a user-initiated write is idempotent; a broadcast that does arrive patches the same rows.
     // In paged mode this is NOT a full reload — refreshClicked routes through loadDataPaged's same-URL branch,
     // which re-fetches only the loaded window (skip=0, take=loadedCount), never the whole dataset.
     realTimeRefreshOrFallback() {
-        if (!this.effRealTime || !this.isSignalRConnected) { // Changed: resolves via the app-wide default
-            this.refreshClicked();
-        }
+        this.refreshClicked(); // Changed: unconditional — was `if (!this.effRealTime || !this.isSignalRConnected)`, which made the healthy real-time case a silent no-op
     }
     //---------------- TinSync offline support ----------------
     // Registers the table's URLs with the offline service, starts the sync engine, and wires live overlay updates