Getting Started
- Fork the repository: https://github.com/JointSave-org/Joint_Save
- Clone your fork:
git clone https://github.com/<your-username>/Joint_Save.git
cd Joint_Save
- Create a new branch:
git checkout -b fix/transactions-csv-export-consistency
Overview
PR #154 added a well-built, well-tested shared CSV export utility (frontend/lib/csv-export.ts) with proper RFC 4180 cell escaping, and used it for the new admin audit log feature. However, the existing Transactions tab export (frontend/components/dashboard/transactions.tsx) still has its own separate, hand-rolled CSV logic that was never migrated to use this new utility — meaning the original issue this work was meant to address (#149) is only partially resolved.
Current Behavior
In transactions.tsx's exportCSV function:
const header = ["Date", "Pool Name", "Pool Type", "Activity Type", "Amount", "Transaction Hash"]
const rows = filtered.map((a) => [
new Date(a.created_at).toLocaleDateString(),
a.pool_name ?? "",
a.pool_type ?? "",
a.activity_type,
a.amount != null ? a.amount.toFixed(2) : "",
a.tx_hash ?? "",
])
Two real problems:
- No token symbol on amounts. The "Amount" column exports a bare number (e.g.
50.00) with no indication of which token it refers to. Since multi-token support has shipped, a pool using USDC and a pool using XLM would both export indistinguishable numbers, which is genuinely ambiguous when reading the file later, especially across multiple pools with different tokens.
- Locale-dependent date format.
new Date(a.created_at).toLocaleDateString() produces output that varies based on the viewer's browser locale (e.g. 6/27/2026 vs 27/6/2026), which is ambiguous in an exported file that might be opened on a different machine or shared with someone else.
Required Fix
- Migrate
transactions.tsx's exportCSV to use buildCsv/downloadCsv from frontend/lib/csv-export.ts, consistent with the admin audit log's usage
- Add a token symbol column (or append it to the Amount column, e.g.
"50.00 USDC") so each row's amount is unambiguous
- Replace
toLocaleDateString() with an unambiguous, fixed format (e.g. ISO 8601: 2026-06-27), consistent with how dates are already formatted elsewhere in exports
Acceptance Criteria
Getting Started
Overview
PR #154 added a well-built, well-tested shared CSV export utility (
frontend/lib/csv-export.ts) with proper RFC 4180 cell escaping, and used it for the new admin audit log feature. However, the existing Transactions tab export (frontend/components/dashboard/transactions.tsx) still has its own separate, hand-rolled CSV logic that was never migrated to use this new utility — meaning the original issue this work was meant to address (#149) is only partially resolved.Current Behavior
In
transactions.tsx'sexportCSVfunction:Two real problems:
50.00) with no indication of which token it refers to. Since multi-token support has shipped, a pool using USDC and a pool using XLM would both export indistinguishable numbers, which is genuinely ambiguous when reading the file later, especially across multiple pools with different tokens.new Date(a.created_at).toLocaleDateString()produces output that varies based on the viewer's browser locale (e.g.6/27/2026vs27/6/2026), which is ambiguous in an exported file that might be opened on a different machine or shared with someone else.Required Fix
transactions.tsx'sexportCSVto usebuildCsv/downloadCsvfromfrontend/lib/csv-export.ts, consistent with the admin audit log's usage"50.00 USDC") so each row's amount is unambiguoustoLocaleDateString()with an unambiguous, fixed format (e.g. ISO 8601:2026-06-27), consistent with how dates are already formatted elsewhere in exportsAcceptance Criteria
transactions.tsx's export uses the sharedcsv-export.tsutility, not its own separate implementation