ENA Submission
This is the section where SeqDesk stops being an internal tool and starts writing to a public archive. Everything that reaches the ENA Production server becomes a permanent, citable, world-readable record. Read the irreversibility rules before you use it in anger.
Two paths, not one
The most common source of confusion is that “submitting to ENA” in SeqDesk is two separate mechanisms that run at different times, against different endpoints, with different permissions and different failure modes.
| XML registration | The submg pipeline | |
|---|---|---|
| UI entry point | Study → Publishing tab → Register at ENA | Study → Publishing tab → Submit to ENA |
| What it sends | Study (PROJECT) and sample metadata as ENA XML | The actual data files: FASTQ reads, assembly FASTA, optional bins |
| How it runs | A synchronous HTTP POST from the SeqDesk server | A pipeline run on your local or SLURM executor |
| Target selection | Chosen per click with a Test / Production toggle | Follows the global enaTestMode admin setting |
| Records created | One Submission row per attempt, visible in the Submissions Dashboard | One PipelineRun with logs and artifacts |
| Accessions written back | PRJEB… on the study, ERS… on each sample | ERS… and SAMEA… on samples, ERR…/ERX… on reads, ERZ… on the assembly, and bin accessions |
| Who can start it | FACILITY_ADMIN | FACILITY_ADMIN (the package sets userCanStart: false) |
The order is fixed. The submg path refuses to start until the study already
carries a PRJ… accession, because ENA needs an existing project to attach
runs and analyses to. Register first, submit data second.
Neither path is available to researchers. Both require the
FACILITY_ADMIN role, and the Submissions Dashboard redirects everyone
else to /orders.
Where to start
A newcomer should read them in that order. If you have never submitted from this installation before, do a full dry run on the ENA Test server against one small study first — it costs nothing, expires by itself, and exercises every code path except the permanent write.
What is irreversible
Understand these before you touch the Production toggle.
- A production
PRJEB…accession cannot be withdrawn from SeqDesk. Once a production registration completes for the whole study, SeqDesk setssubmittedon it and every later attempt is rejected withStudy already registered with ENA (PRJEB…). Deleting theSubmissionrow does not clear a production accession — the delete handler only clears accessions for submissions it recorded as test submissions. - Public data stays public. ENA supports suppression and updates through the Webin portal, not through SeqDesk. SeqDesk has no “unsubmit” action for anything on the production server.
- Deleting a test submission does mutate your database. It clears
studyAccessionId,submitted,submittedAtandtestRegisteredAton the study, and the matchingsampleAccessionNumberon each sample. That is the intended cleanup path for expired test rows, but it is a real write.
Everything else is safe to retry: the registration path regenerates fresh XML on every attempt, and a submg run that fails validation writes nothing to ENA at all.
What the test server is for
ENA runs a full second copy of the submission service at
wwwdev.ebi.ac.uk. It accepts the same credentials, applies the same
validation, and returns accession numbers in the same format — but it
discards everything after 24 hours.
Use it to prove three things that only a real submission can prove:
- Your Webin credentials authenticate against the drop-box endpoint.
- Your XML passes ENA’s schema and checklist validation with the metadata currently in your database.
- Your sample aliases are not already taken in your submission account.
SeqDesk enforces this: the Register at Production button stays disabled until the study has an unexpired test registration. See Submitting to ENA.
Prerequisites and neighbouring sections
- Credentials. A Webin account, entered under
Administration → ENA Credentials.
The username must match
Webin-12345; SeqDesk rejects anything else before it makes a network call, and stores the password encrypted at rest. - A study. Samples are never submitted on their own — they are submitted as members of a study. See Studies for how samples get grouped and Study Metadata & MIxS for the checklist that becomes ENA sample attributes.
- Taxonomy on every sample. See Organism & Taxonomy.
- For submg only: analysis results. Reads with MD5 checksums plus an assembly FASTA on disk, which normally means the MAG pipeline has already run.