Submissions Dashboard

/submissions is the facility-admin view of every ENA registration attempt this installation has ever made. Where Submitting to ENA describes how one submission flows, this page is the queue you watch them from and the forensic record you fall back on when one goes wrong.

It covers the XML registration path only. submg runs are pipeline runs and appear under pipeline monitoring instead.

Researchers cannot reach this page — they are redirected to /orders. In the public demo it is replaced by a notice explaining that external archive submission is blocked.

Layout

The page is titled Archive Queue. Under the title is a live count:

14 submissions · 9 accepted · 1 pending · 2 issues

“pending” counts PENDING and SUBMITTED; “issues” counts REJECTED, ERROR and PARTIAL. A Refresh button re-fetches without a page reload.

If there are no submissions at all the table is replaced by No submissions yet and a View Studies link, because registration is always started from a study, never from here.

Filters

Row summary

The subtitle under the entity name shows the submission type and appends · Test for test submissions.

Expanded row

Clicking a row expands it.

• Registration Steps — a timeline rebuilt from response.steps[]. Each step has a number, a name, a status, a timestamp, and an expandable details block. Step names are Validation, Generate XML, Send Study to ENA (or Reuse Existing Study), Send Samples to ENA, and Update Database. XML values inside the details render as scrollable code blocks with a Copy button.
• Accession Numbers — every entry in the map, each deep-linked into the ENA browser. Test rows link to wwwdev.ebi.ac.uk, production rows to www.ebi.ac.uk. The study entry is labelled “Study”; the rest are labelled Sample: <sampleId>. A footnote states whether these are temporary or permanent.
• Generated XML — the concatenated study, sample, and submission XML from xmlContent, exactly as sent.
• Actions — Retry Submission, Processing…, and Delete, depending on status.

Older rows written before the step timeline existed fall back to a Submission Details block showing just the server, the target, and the message.

Statuses

The registration path itself produces four of these. The rest exist for display and for manual state changes.

PARTIAL cannot be set manually — the PATCH endpoint accepts only PENDING, SUBMITTED, ACCEPTED, REJECTED, ERROR and CANCELLED, and rejects anything else with Invalid status.

Test-mode expiry

ENA’s test server drops accessions 24 hours after they are issued. The dashboard reflects that, but does not verify it:

• Test rows show Expires in Xh (or Xm in the final hour) beside the status badge.
• After the deadline the badge reads Expired, struck through.
• The countdown is computed entirely in the browser from createdAt plus 24 hours. SeqDesk never asks ENA whether the record is still there.

A row is treated as a test submission unless its stored response explicitly says otherwise, so a malformed or missing response is assumed to be a test.

Retry semantics

Retry Submission appears only on ERROR, REJECTED and PARTIAL rows whose entity type is study. PENDING rows show a disabled Processing… button; ACCEPTED rows offer no retry.

There is no dedicated retry endpoint. The button re-POSTs /api/admin/submissions with the same entityType, entityId, and the same test/production target the original attempt used. That means:

• Fresh XML is generated, so any database fixes you made since take effect.
• If the study already holds an accession for that target, the project registration is skipped and only the samples still missing an accession are sent.
• A new Submission row is created. The failed one stays for the record.
• The same pre-checks apply, so a retry can bounce immediately with, for example, Study and samples are already registered on the ENA Test Server.

Deleting

Delete asks for confirmation, warning that “For test submissions, this will also clear the accession numbers from the study.”

That warning is precise and important:

• Test submission — the study’s studyAccessionId, submitted, submittedAt and testRegisteredAt are cleared (only if the stored study accession still matches the one this submission recorded), and each sample’s sampleAccessionNumber is cleared where it matches. This is the intended way to reset after a test cycle.
• Production submission — nothing is cleared. Only the audit row disappears. Deleting it does not withdraw anything from ENA and does not let you re-register the study.

The Submission record

Defined in prisma/schema.prisma:

There is no receiptXml, requestPayload or error-message column. The receipt and all error text live inside response.

API

All five require FACILITY_ADMIN; anything else returns 401.

When to use it

• Watching a registration land. The step timeline is the only place the full request/response detail is kept.
• Post-mortem on a rejection. Expand, read the XML, read the receipt, fix the record, retry. See Troubleshooting ENA.
• Periodic test-mode cleanup. Delete expired test rows so the queue keeps reflecting real state — and so a stale accession does not block a future registration.
• Clearing a stuck PENDING row that is blocking new registrations with A submission for this study is already in progress.