Station Editor & Admin Guide
Running a station instance: the editorial flow, the manuscripts table, authorship, email notifications and station identity.
For station staff who manage submissions, publish records, and configure the platform. Examples use iPlaces Gump Station; everything is written to apply to any station.
1. The editorial flow at a glance
An author submits a record → the editorial team is notified by email → an editor opens the record (Control link in the Manuscripts table), reviews the metadata, and publishes → the record appears on the public station site with a DOI, and appears in each ORCID-identified author's dashboard.
Records are versioned: changes after submission happen through new versions, not in-place edits. The public page and DOI always reflect the latest published version.
2. The Manuscripts table
Manuscripts in the left menu lists every record in the station.
The Manuscripts table. The Author team column lists everyone with account access to each record.
- Author team — everyone whose account is connected to the record. This is access, distinct from the byline: the byline comes from the record's author metadata; the author team is who can see and edit it. They usually match, but an author without an ORCID appears in the byline only.
- Control — the editorial view: decision, metadata, manuscript text, team, tasks & notifications.
- View / Production — reading view and production (PDF/export) view.
Columns are configurable per station (Configuration → General →
tableColumns).
3. Managing authorship
Inviting someone to claim authorship
Sending an author invitation from a record's Tasks & Notifications tab.
From a record's Tasks & Notifications tab, choose the person and the Author Invitation template, then Notify. They receive an email with Accept / Decline links. Accepting requires ORCID login and connects the record to their account automatically.
Use this for records that list authors who don't yet have platform accounts — the invitation walks them through registration.
Two facts worth knowing
- Everyone on a record's author team has the same rights — view, edit, create new versions, resubmit. There is no read-only author role.
- Published records remain editable by their author team. If a published record's metadata changes, republish so the public page and DOI record stay current.
4. Email: how notifications work
Email lives in Settings → Configuration, across three tabs that work together:
| tab | what it holds |
|---|---|
| Email Settings | The SMTP connection — sender address, host, port, credentials. Nothing sends until this is configured. |
| Notification Templates | The content of each email — subject and body, edited here. |
| Notification Events | When emails go out and to whom — each platform event (submission, publication, invitation…) can have one or more notifications, each pointing at a template and a recipient. |
The split matters: to change an email's wording, edit the template; to change who receives it or on which event, edit the event's notification.
The Notification Events list. Bold + green toggle = active event; struck-through entries are disabled notifications.
One notification's settings. The body shown here is a preview — edit the wording on the Notification Templates tab.
Template variables
Templates use {{ variable }} placeholders, filled in per email. Common ones:
| variable | meaning |
|---|---|
{{ recipientName }} |
the recipient's name |
{{ manuscriptTitle }} |
the record's title |
{{ manuscriptNumber }} |
the short ID |
{{ authorName }} |
the submitting author |
{{ brandName }} |
the station's name (from Configuration → General → Brand name) — use this instead of typing the station name, so templates work unchanged on every station |
{{ submissionResourcetype }} |
the record's type (Project, Dataset, ConferencePaper…) |
{{{ manuscriptLink }}} |
a link to the record, resolved per recipient (editors land on the decision view, authors on their submission) |
{{{ acceptInviteLink }}} / {{{ declineInviteLink }}} |
invitation response links |
Links use triple braces {{{ … }}} — they are pre-built HTML; double
braces would render the code instead of the link. Every submission.<field>
in the form is also available as {{ submission<Field> }}.
A variable that doesn't exist renders as nothing — no error, just a hole in the sentence. Test templates with a real send before relying on them.
Recommended baseline notifications
- A manuscript is submitted → to the station address
(e.g.
gumpstation@iplacesalliance.org): "New {{ submissionResourcetype }} submitted" — the editor alert. Same event → to the author: submission confirmation. - A manuscript is published → to the station address: publication notice (operational log).
Note the event named "New manuscript version submitted" is a different event (a revision was opened) — the submission alert belongs on the manuscript submitted event, which fires for first submissions and resubmissions alike.
Delivery caveat
Notifications to a person (rather than a literal address) are delivered to the email on their platform account. Accounts created in advance from author metadata may have no email on file — those notifications are skipped silently. The submission-confirmation email is the exception: it uses the email typed into the submission form.
5. Station email conventions (iPlaces Alliance hosted)
-
Sender address:
<groupname>@iplacesalliance.org(e.g.gumpstation@iplacesalliance.org), created as a Google Group whose members are the station staff who should receive replies — replies to every notification go there.
Email Settings for an Alliance-hosted station: SES host, port 465, secure connection on. -
SMTP: Amazon SES, one credential per station, configured in Email Settings. Port 465, secure connection on, Require TLS off.
-
The username is the SES SMTP username (starts
AKIA…); the password is the SES SMTP password, not an AWS secret key. -
Stations may instead use their own email provider — enter their SMTP details in the same form.
6. Station identity: one name everywhere
Five places name the station; keep them consistent:
| where | holds | example |
|---|---|---|
| Configuration → General → Title | the institution | UC Berkeley Gump South Pacific Research Station |
| Configuration → General → Brand name | the publishing venue — feeds {{ brandName }} |
iPlaces Gump Station |
| Configuration → General → Abbreviated name | short venue name (PDF headers) | iPlaces Gump Station |
Public site masthead (CMS station.json) |
venue name shown to readers | should match Brand name |
| Station email address | <groupname>@iplacesalliance.org |
gumpstation@iplacesalliance.org |
Rule of thumb: institution in Title; the same venue name everywhere else.
7. Common problems
"I can't type in the editor" — Grammarly (or a similar extension) is interfering. Disable it for the site, hard-refresh. This is the most common author support request; the fix is on the author guide too.
"An author says they can't see their record" — check whether their ORCID iD is on the record's author metadata. Access follows the ORCID connection; a byline name with no ORCID has no account link. Fix: add their ORCID to the record (new version), or send an author invitation.
"The notification never arrived" — in order: is Email Settings configured? Is the event's notification toggled active? Does the recipient resolve to a real email (see the delivery caveat above)? Check spam — a station's first sends sometimes land there before the domain's reputation settles.
"Two of us edited and my change vanished" — same-field edits are last-save-wins, and the author list is replaced as a whole. Coordinate list edits; don't work in the same record simultaneously.