Merge branch 'maker-checker' into dev: Product Approval workflow

Brings in the Product Approval feature (anshul.rathore) — a unified Approvals
screen for Loan/Savings/Current/Share/FD/RD/Charge product requests:
- Merges two existing pending-request sources into one list: staged product
  edits (m_saving_product_temp, via /{producttype}/pending) and native
  maker-checker entries (/makercheckers) for product CREATE/DELETE and
  LOANPRODUCT/CHARGE of any action.
- Checker Inbox no longer lists product requests at all — they now live only
  in Product Approval, so a checker isn't checking two queues for the same
  thing. Clicking a non-product row now navigates straight to that entity's
  own view page when one exists, instead of always opening a detail dialog.
- View Checker Inbox dialog gains a caller-supplied heading (used when opened
  from Product Approval) and a notice steering staged product edits back to
  Product Approval instead of being actioned in place.
- Route renamed pending-savings-products -> product-approval, with the old
  path kept as a redirect for existing bookmarks/links.

8 files conflicted with dev's own recent Checker Inbox work (popup-based
detail view, e8097bc2/63134f17) and were resolved by hand, keeping both
sides' real functionality rather than picking one branch wholesale:
- product-edit-diff-dialog.component.{ts,html,scss}: kept dev's diff dialog
  (resolves GL account ids to names, aliases fields like currencyCode against
  the stored product, normalises the two date shapes the API uses) over
  maker-checker's simpler raw-value version.
- pending-savings-products.component.{ts,html}: kept maker-checker's full
  isPendingEdit()-based dispatch (dev's version was a strict subset of it).
- view-checker-inbox.component.{ts,html,scss}: kept dev's per-entry Delete
  action and maker-checker's recursive Command-payload tree renderer and
  custom heading side by side.

Also recovered two regressions the merge introduced silently (no conflict
markers, so `git merge` gave no warning):
- tasks.service.ts lost deleteMakerChecker() entirely — restored.
- Checker Inbox's bulk Delete action (button, deleteChecker()/
  bulkDeleteChecker(), and its .cv-btn-delete style) was dropped across three
  files — restored to match dev's pre-merge behaviour exactly.

And one duplicate the merge produced without a conflict marker: two
independent viewEntry() implementations landed in checker-inbox.component.ts
(TS2393, caught at build). Kept maker-checker's entity-view-page-routing
version — a superset of dev's dialog-only version — and dropped the duplicate,
along with a leftover diagnostic console.log.

src/app/tasks/checker-inbox-and-tasks-tabs/checker-inbox/checker-inbox.component.ts

@@ -40,6 +40,7 @@ import { FaIconComponent } from '@fortawesome/angular-fontawesome';
 import { MatCheckbox } from '@angular/material/checkbox';
 import { DateFormatPipe } from '../../../pipes/date-format.pipe';
 import { STANDALONE_SHARED_IMPORTS } from 'app/standalone-shared.module';
+import { isProductEntity, isTempTableAccountEdit } from '../../product-entities';
 
 @Component({
   selector: 'mifosx-checker-inbox',
@@ -105,27 +106,19 @@ export class CheckerInboxComponent implements OnInit {
   ];
 
   /**
-   * Entities whose pending edits are gated by our own custom staging tables (m_savings_product_temp
-   * for products, the savings account edit-request table for Nominee/Digital-Feature edits) rather
-   * than the native command-source pipeline. They're excluded from Checker Inbox entirely -
-   * approving/rejecting them here would call the native /makercheckers/{id}?command=approve endpoint,
-   * which replays the original command handler directly and never touches our staging table, leaving
-   * its lock/hold stuck forever. Action them from Approvals -> Pending Product Edits / Pending Account
-   * Edits instead, where that's handled correctly.
+   * The Checker Inbox holds non-product pending requests only. Two groups are routed elsewhere:
+   *
+   *  - Product requests of every action (CREATE, UPDATE, DELETE) belong to Approvals -> Product
+   *    Approval, which merges them with the product edits staged in m_saving_product_temp so a
+   *    checker sees one queue per product rather than two.
+   *  - Savings/current account edits are staged the same way as product edits and belong to
+   *    Approvals -> Pending Account Edits. Approving them here would call
+   *    /makercheckers/{id}?command=approve, which replays the original command handler and never
+   *    touches the staging table, leaving its lock held forever.
    */
-  private readonly productEditEntities = [
-    'SAVINGSPRODUCT',
-    'CURRENTPRODUCT',
-    'SHAREPRODUCT',
-    'FIXEDDEPOSITPRODUCT',
-    'RECURRINGDEPOSITPRODUCT',
-    'SAVINGSACCOUNT',
-    'CURRENTACCOUNT'
-  ];
-
-  private excludeProductEdits(items: any[]): any[] {
+  private excludeRoutedElsewhere(items: any[]): any[] {
     return (items || []).filter(
-      (item: any) => !(this.productEditEntities.includes(item?.entityName) && item?.actionName === 'UPDATE')
+      (item: any) => !isProductEntity(item?.entityName) && !isTempTableAccountEdit(item?.entityName, item?.actionName)
     );
   }
 
@@ -142,7 +135,7 @@ export class CheckerInboxComponent implements OnInit {
   constructor() {
     this.route.data.subscribe((data: { makerCheckerResource: any; makerCheckerTemplate: any }) => {
       const raw = data.makerCheckerResource;
-      this.searchData = this.excludeProductEdits(Array.isArray(raw) ? raw : (raw?.pageItems ?? []));
+      this.searchData = this.excludeRoutedElsewhere(Array.isArray(raw) ? raw : (raw?.pageItems ?? []));
       this.checkerData = this.searchData.length > 0;
       this.makerCheckerTemplate = data.makerCheckerTemplate ?? {};
       this.dataSource = new MatTableDataSource(this.searchData);
@@ -182,7 +175,7 @@ export class CheckerInboxComponent implements OnInit {
       makerDateTimeto: this.dateUtils.formatDate(this.makerCheckerSearchForm.value.makerDateTimeto, dateFormat)
     };
     this.tasksService.getMakerCheckerData(makerCheckerSearchParams).subscribe((response: any) => {
-      this.searchData = this.excludeProductEdits(response);
+      this.searchData = this.excludeRoutedElsewhere(response);
       if (this.searchData.length === 0) {
         this.noSearchedData = true;
       } else {
@@ -290,11 +283,66 @@ export class CheckerInboxComponent implements OnInit {
   }
 
   /**
-   * Opens one inbox entry in a popup rather than navigating to its own page, so the checker keeps
-   * the list (and any search/filter they set up) behind the dialog. The direct route stays available
-   * for a bookmarked link — ViewCheckerInboxComponent supports both entry points.
+   * Maps a maker-checker entityName to the Angular route path for that entity's existing view page.
+   * Returns null for entity types that have no dedicated view page in this application.
+   */
+  private entityRoute(entityName: string, resourceId: string | number): string | null {
+    const id = resourceId;
+    switch ((entityName ?? '').toUpperCase()) {
+      case 'LOANPRODUCT':
+        return `/products/loan-products/${id}`;
+      case 'SAVINGSPRODUCT':
+        return `/products/saving-products/${id}`;
+      case 'CURRENTPRODUCT':
+        return `/products/current-products/${id}`;
+      case 'SHAREPRODUCT':
+        return `/products/share-products/${id}`;
+      case 'FIXEDDEPOSITPRODUCT':
+        return `/products/fixed-deposit-products/${id}`;
+      case 'RECURRINGDEPOSITPRODUCT':
+        return `/products/recurring-deposit-products/${id}`;
+      case 'CHARGE':
+        return `/products/charges/${id}`;
+      case 'GLACCOUNT':
+        return `/accounting/chart-of-accounts/gl-accounts/view/${id}`;
+      case 'CLIENT':
+        return `/clients/${id}/general`;
+      case 'LOAN':
+        return `/loans/${id}`;
+      case 'SAVINGSACCOUNT':
+        return `/savings-accounts/${id}`;
+      case 'CURRENTACCOUNT':
+        return `/current-accounts/${id}`;
+      default:
+        return null;
+    }
+  }
+
+  /**
+   * Handles a row click in the Checker Inbox.
+   *
+   * Priority:
+   *  1. If the row has a known entityName and a resourceId → navigate to the entity's existing
+   *     view page (read-only; no maker-checker action buttons are present on those pages).
+   *  2. If no resourceId is available (e.g. a DELETE action where the entity no longer exists)
+   *     → show a brief informational snackbar.
+   *  3. If the entityName is unrecognised → fall back to the existing ViewCheckerInboxComponent
+   *     dialog so the checker can still view the command details and action the entry.
    */
   viewEntry(row: any): void {
+    const entityName: string = row.entityName ?? '';
+    const resourceId = row.resourceId;
+    const route = this.entityRoute(entityName, resourceId);
+
+    if (route && resourceId != null) {
+      // Navigate to the existing entity view page (no maker-checker buttons there).
+      this.router.navigate([route]);
+      return;
+    }
+
+    // resourceId is absent (CREATE rows: entity does not exist yet until approved),
+    // or entityName is unmapped — fall back to the detail dialog so the checker
+    // can still view the command payload and action the entry.
     this.dialog
       .open(ViewCheckerInboxComponent, {
         data: { checkerId: row.id },