Submissions Dashboard

The Submissions Dashboard at /submissions is the facility-admin view of every ENA submission attempt the install has ever made. It complements Submitting to ENA, which describes how a single submission flows; this page describes the dashboard you watch the queue from.

Researchers cannot reach this page — they are redirected to /orders if they try. It’s a facility-admin tool.

Layout

The dashboard is a single table titled Archive Queue with one row per Submission record. Each row collapses to a summary line and expands to a full timeline.

Top bar

Control	Behavior
Search box	Filters by entity name, submitting user, submission type, or submission id
Status filter	`PENDING`, `SUBMITTED`, `PARTIAL`, `ACCEPTED`, `REJECTED`, `ERROR`, `CANCELLED`
Type filter	Limit to `study` or `sample` submissions

Row summary

Each collapsed row shows:

Column	Source
Entity	Study title or sample id (resolved from `entityType` + `entityId`)
Status	Current `status` field, color-coded; test rows also show an expiry countdown
Accession	The first value from the `accessionNumbers` JSON map
Date	`createdAt`

Expanded row

Clicking a row expands it to show:

Registration steps — a vertical timeline reconstructed from response.steps[]. Each step has a name (Validation, Generate XML, Send Study to ENA or Reuse Existing Study, Send Samples to ENA, Update Database), a status (completed / error), a timestamp, and the details SeqDesk recorded.
Accession numbers — every entry in accessionNumbers, with deep links into the ENA browser (the study entry is labelled “Study”; sample entries are labelled by sample id).
Generated XML — the exact XML SeqDesk sent to ENA (from xmlContent), useful when ENA rejects a submission and you need to inspect what shipped.
Actions — Retry (only for ERROR / REJECTED / PARTIAL study submissions) and Delete.

Submission states

The study-registration path produces PENDING, ACCEPTED, PARTIAL, and ERROR. The dashboard also recognizes SUBMITTED, REJECTED, and CANCELLED for filtering and display; CANCELLED can be set by an operator via the status PATCH endpoint.

State	Set when
`PENDING`	Record created, registration not yet finished (shown with a disabled “Processing…” button)
`ACCEPTED`	Study accession received and every sample has an accession
`PARTIAL`	Study registered but some samples failed
`ERROR`	The study call failed, or an internal error occurred before/after it
`CANCELLED`	An operator set the status via `PATCH`

Test-mode expiry

ENA’s test server (wwwdev.ebi.ac.uk) drops accession numbers after 24 hours. The dashboard reflects this:

Test submissions display an “Expires in Xh” (or “Xm”) countdown next to the status badge.
After expiry the countdown shows “Expired” rendered struck through.
The dashboard does not call ENA to verify; the countdown is purely client-side, derived from the createdAt timestamp plus 24 hours.

To clear stale test submissions, use the Delete action — they will not clean themselves up automatically. Deleting a test study submission also clears the accession numbers it set on the study and its samples.

Retry semantics

Retry is shown only on ERROR, REJECTED, and PARTIAL study submissions. It does not hit a dedicated retry endpoint — it simply re-POSTs /api/admin/submissions with the same entityType/entityId (and the original test/production target). SeqDesk regenerates fresh XML, so any database fixes since the last attempt take effect. When the study already has an accession the re-run reuses it and submits only the samples still missing one.

PENDING rows show a disabled “Processing…” button; ACCEPTED rows have no retry button.

Submission record

Defined at prisma/schema.prisma:

Field	Type	Purpose
`id`	cuid	Submission identifier
`submissionType`	string	`STUDY` for the XML registration path
`status`	string	Current state; default `PENDING`
`xmlContent`	string?	The XML SeqDesk built and sent (kept for debugging)
`response`	string? (JSON)	Server, test flag, message, the `steps[]` timeline, a nested `receipt` (containing the raw receipt XML), and any error text
`accessionNumbers`	string? (JSON map)	Returned accessions, e.g. `{ "study": "PRJEB12345", "<sampleId>": "ERS..." }`
`entityType`	string	`study` or `sample`
`entityId`	string	FK into the Study or Sample table
`createdAt` / `updatedAt`	datetime	Standard timestamps

There is no receiptXml or requestPayload column — the receipt and error text are nested inside the response JSON.

API

The dashboard reads from GET /api/admin/submissions. “Retry” re-POSTs POST /api/admin/submissions; “Delete” calls DELETE /api/admin/submissions/[id]; an operator can change a status with PATCH /api/admin/submissions/[id]. All are facility-admin-only.

When to use it

Day-to-day operations — the place to see what’s queued, what’s failed, what’s in flight.
Post-mortem on rejected submissions — expand the row, read the XML, read ENA’s response, fix the underlying record, retry.
Periodic test-mode cleanup — filter to test submissions whose countdown reads “Expired” and delete them one by one (deleting a test study submission also clears the accessions it wrote).