@zeniai/client-epic-state 5.1.45-betaDI1 → 5.1.45-betaDI2

package/lib/esm/view/taskManager/taskListView/taskListReducer.js

@@ -824,26 +824,24 @@ const getGroupedTaskIds = (tasks) => {
         ...initialTaskIdsByDueDate,
     };
     const taskIdsByTags = {};
-    // Which parents are actually present in this payload. A subtask is
-    // only treated as "nested" (and dropped from the count / groupings)
-    // if its parent is in the visible set — otherwise it renders as an
-    // orphan top-level row in the UI (SubtaskDetailTable has no parent to
-    // attach under) and MUST count. Customer callers routinely see this:
-    // the parent is Zeni-internal / private and filtered server-side, but
-    // the subtask itself is public and lands in the payload.
-    const visibleTaskIds = new Set(tasks.map((t) => t.task_id));
+    // A task is a "nested subtask" (hidden from the flat top-level list +
+    // dropped from the tab count) iff a parent in the same payload claims
+    // it via its `subtasks: [...]` array. Match this criterion exactly to
+    // WC's `allSubtaskIds` union in TaskManagementPage.tsx — otherwise
+    // the tab count and the visible top-level row count disagree
+    // whenever the BE emits `parent_task_id` on a subtask but omits it
+    // from the parent's `subtasks` array (a real inconsistency this UI
+    // sees today).
+    //
+    // Using `parent_task_id` here would sometimes drop a task from the
+    // count that WC still renders as a flat top-level row — that's the
+    // bug we're fixing.
+    const nestedSubtaskIds = new Set();
     tasks.forEach((task) => {
-        // A task is a "nested subtask" only when its parent is in the
-        // visible payload — otherwise it's an orphan and renders as a
-        // top-level row in the UI (customer callers routinely see this:
-        // the parent is Zeni-internal / private and filtered server-side,
-        // but the subtask itself is public and lands in the payload).
-        // Datastore string properties default to '' when unset, so treat
-        // empty string as null. Matches the sibling `updateTasks` guard
-        // at L719-722.
-        const isNestedSubtask = task.parent_task_id != null &&
-            task.parent_task_id !== '' &&
-            visibleTaskIds.has(task.parent_task_id);
+        (task.subtasks ?? []).forEach((subtaskId) => nestedSubtaskIds.add(subtaskId));
+    });
+    tasks.forEach((task) => {
+        const isNestedSubtask = nestedSubtaskIds.has(task.task_id);
         // Subtasks stay in every groupBy array so the UI can render them
         // nested under their parent (WC's TaskManagementPage builds
         // `subtasksByParentId` from `group.tasks` and then filters them

package/lib/view/taskManager/taskListView/taskListReducer.js

@@ -828,26 +828,24 @@ const getGroupedTaskIds = (tasks) => {
         ...initialTaskIdsByDueDate,
     };
     const taskIdsByTags = {};
-    // Which parents are actually present in this payload. A subtask is
-    // only treated as "nested" (and dropped from the count / groupings)
-    // if its parent is in the visible set — otherwise it renders as an
-    // orphan top-level row in the UI (SubtaskDetailTable has no parent to
-    // attach under) and MUST count. Customer callers routinely see this:
-    // the parent is Zeni-internal / private and filtered server-side, but
-    // the subtask itself is public and lands in the payload.
-    const visibleTaskIds = new Set(tasks.map((t) => t.task_id));
+    // A task is a "nested subtask" (hidden from the flat top-level list +
+    // dropped from the tab count) iff a parent in the same payload claims
+    // it via its `subtasks: [...]` array. Match this criterion exactly to
+    // WC's `allSubtaskIds` union in TaskManagementPage.tsx — otherwise
+    // the tab count and the visible top-level row count disagree
+    // whenever the BE emits `parent_task_id` on a subtask but omits it
+    // from the parent's `subtasks` array (a real inconsistency this UI
+    // sees today).
+    //
+    // Using `parent_task_id` here would sometimes drop a task from the
+    // count that WC still renders as a flat top-level row — that's the
+    // bug we're fixing.
+    const nestedSubtaskIds = new Set();
     tasks.forEach((task) => {
-        // A task is a "nested subtask" only when its parent is in the
-        // visible payload — otherwise it's an orphan and renders as a
-        // top-level row in the UI (customer callers routinely see this:
-        // the parent is Zeni-internal / private and filtered server-side,
-        // but the subtask itself is public and lands in the payload).
-        // Datastore string properties default to '' when unset, so treat
-        // empty string as null. Matches the sibling `updateTasks` guard
-        // at L719-722.
-        const isNestedSubtask = task.parent_task_id != null &&
-            task.parent_task_id !== '' &&
-            visibleTaskIds.has(task.parent_task_id);
+        (task.subtasks ?? []).forEach((subtaskId) => nestedSubtaskIds.add(subtaskId));
+    });
+    tasks.forEach((task) => {
+        const isNestedSubtask = nestedSubtaskIds.has(task.task_id);
         // Subtasks stay in every groupBy array so the UI can render them
         // nested under their parent (WC's TaskManagementPage builds
         // `subtasksByParentId` from `group.tasks` and then filters them

package/package.json

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