refactor(PublishedData): replace published data table with dynamic mat table

[abdimo101]

Description

This PR replaces the old published data table with dynamic mat table & adds published data columns to externalSettings

Motivation

Background on use case, changes needed

Fixes:

Please provide a list of the fixes implemented in this PR

• Items added

Changes:

Please provide a list of the changes implemented by this PR

• changes made

Tests included

• Included for each change/fix?
• Passing? (Merge will not be approved unless this is checked)

Documentation

• swagger documentation updated [required]
• official documentation updated [nice-to-have]

official documentation info

If you have updated the official documentation, please provide PR # and URL of the pages where the updates are included

Backend version

• Does it require a specific version of the backend
• which version of the backend is required:

Summary by Sourcery

Replace the published data dashboard table with a dynamic Material table using server-side pagination and global text search.

New Features:

• Add dynamic-mat-table integration for the published data dashboard with configurable columns and table settings.
• Introduce global text search and server-side pagination controls for published data listings.

Enhancements:

• Refactor published data dashboard to use a BehaviorSubject-backed data source and centralized SciCatDataSource for loading data.
• Simplify selection and share logic by removing DOI selection and clipboard copy features that were tied to the old table component.
• Improve lifecycle management by consolidating subscriptions and ensuring proper cleanup on destroy.

[sourcery-ai]

Hey - I've found 2 issues, and left some high level feedback:

• The new loadData/getSort flow mixes parameters and internal state (e.g. loadData(filters, ...) then reading this.currentFilters.sortField instead of filters.sortField), and also leaves the const [field, direction] destructuring in ngOnInit unused, so it would be good to either consistently derive sort from the passed filters or remove the unused code to avoid confusion.
• The pending flag is always false and never updated around loadAllData, so the dynamic table’s loading state will never be shown; consider toggling pending when issuing requests and when data arrives (e.g. around loadData or via the data source observables).
• The previous table supported row navigation and DOI sharing (onRowClick, onShareClick, selection handlers), but these behaviors have been removed with the switch to dynamic-mat-table; if they are still required, consider re-implementing them via row click handlers or action menus on the new table.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The new `loadData`/`getSort` flow mixes parameters and internal state (e.g. `loadData(filters, ...)` then reading `this.currentFilters.sortField` instead of `filters.sortField`), and also leaves the `const [field, direction]` destructuring in `ngOnInit` unused, so it would be good to either consistently derive sort from the passed filters or remove the unused code to avoid confusion.
- The `pending` flag is always `false` and never updated around `loadAllData`, so the dynamic table’s loading state will never be shown; consider toggling `pending` when issuing requests and when data arrives (e.g. around `loadData` or via the data source observables).
- The previous table supported row navigation and DOI sharing (`onRowClick`, `onShareClick`, selection handlers), but these behaviors have been removed with the switch to `dynamic-mat-table`; if they are still required, consider re-implementing them via row click handlers or action menus on the new table.

## Individual Comments

### Comment 1
<location path="src/app/publisheddata/publisheddata-dashboard/publisheddata-dashboard.component.ts" line_range="101-102" />
<code_context>
+        const { skip, limit, sortField } = vm.filters;
+        const pageIndex = skip / limit;
+
+        const [field, direction] = sortField
+          ? sortField.split(" ")
+          : ["", "asc"];
+
</code_context>
<issue_to_address>
**nitpick:** Remove unused `field`/`direction` variables in `ngOnInit`.

`field` and `direction` from `sortField` in `ngOnInit` are never used, and `loadData` already derives sorting via `getSort`. Please remove this unused destructuring to avoid confusion about the sort source of truth.
</issue_to_address>

### Comment 2
<location path="src/app/publisheddata/publisheddata-dashboard/publisheddata-dashboard.component.ts" line_range="162-169" />
<code_context>
+    return sortField ? sortField.split(" ") : ["", "asc"];
+  }
+
+  loadData(filters: any, pageIndex: number, pageSize: number) {
+    const [field, direction] = this.getSort();
+    this.scicatDataSource.loadAllData(
+      filters,
+      field,
+      direction,
+      pageIndex,
+      pageSize,
+    );
   }
</code_context>
<issue_to_address>
**issue (bug_risk):** `loadData` ignores the `filters` argument for sorting and relies on `currentFilters`, which may be stale.

Because `getSort` reads from `this.currentFilters`, there are paths (e.g. `onGlobalTextSearchAction`) where `loadData` is invoked before `currentFilters` is updated, so the request can be sent with stale sort parameters. Consider either deriving `field`/`direction` directly from the `filters` argument, or updating `this.currentFilters` before calling `loadData` and then always treating `currentFilters` as the single source of truth.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}