Export History Panel
Component Detail
Description
Panel within the accounting export screen that lists previous export runs for the organization, showing timestamp, triggered-by user, claim count, and export status. Allows coordinators to verify that no double-export has occurred and to re-download prior export files.
export-history-panel
Summaries
The Export History Panel protects the organisation from costly double-export errors by giving coordinators a clear, auditable view of every past export run — who triggered it, when, how many claims were included, and whether it succeeded. In financial operations, exporting the same claims twice can cause duplicate accounting entries that require manual correction and can delay reimbursements. By making history instantly visible within the export screen, this panel reduces operational risk and supports compliance requirements by maintaining a transparent audit trail without requiring coordinators to access separate systems or request reports from administrators.
This panel depends on the `export-run-repository` for paginated data retrieval, meaning its delivery is gated on that repository being available and tested. Complexity is low, but pagination behaviour requires careful QA — particularly the interaction between the `loadExportHistory(orgId, limit, offset)` call and the re-download action. The re-download path (`onRedownload(exportRunId)`) requires coordination with the file storage layer to ensure previously generated export files are retained and retrievable. Plan for edge cases: empty history state on first use, partial/failed run display, and ensuring the re-download action does not trigger a new export run.
The panel runs across both frontend and mobile, so responsive layout testing is required.
The panel calls `loadExportHistory(orgId, limit, offset)` on mount and on `refreshHistory()`, fetching paginated `ExportRun` records from the `export-run-repository` dependency. Each record is rendered via `buildHistoryListItem(ExportRun)`, displaying status badges (completed, partial, failed), triggered-by user identity, timestamp, and claim count. The `onRedownload(exportRunId)` handler must retrieve the previously generated file rather than re-running the export — ensure the repository distinguishes file retrieval from export execution. The `export_run` data model drives display fields.
Implement virtual or windowed list rendering if history lists grow large. Status badge colors must align with the unified entity color system in `styles.css`. Runs in both frontend and mobile execution contexts.
Responsibilities
- Load and display paginated export run history per org
- Show status badge (completed, partial, failed) per run
- Provide re-download action for completed file exports
- Display triggered-by user and timestamp for audit traceability
Interfaces
loadExportHistory(orgId, limit, offset)
buildHistoryListItem(ExportRun)
onRedownload(exportRunId)
refreshHistory()