This is for the usual case where only one sequence is requested.
When more than one sequence is requested, the suggested name comes out
as ${projectId}-${sequenceList}.${extension}, where `sequenceList` is
the list of sequence numbers separated by semicolons, e.g.:
eq21203-37;38;39.html.
Closes#116.
If the survey configuration does not itself have a template
we will use the one in etc/defaults/templates/sequence.html.njk.
It is not very likely that the template will be changed all that
often and it avoids issues when people forget to copy it across
to a new survey, etc.
If the `download` or `d` query parameter is supplied (even
without any value), the response will include a
`Content-Disposition: attachment` header. A filename will
also be suggested.
A button in the help dialogue takes the user to the
/feed/… frontend URL, where the latest development
activity is shown, taken from the GitLab RSS feed
for the project.
When a client makes a request for `/` (the root of
the API), the OpenAPI description is served in an
appropriate format according to the `Accept` request
header, as follows:
Accept: text/html => HTML version
Accept: application/json => JSON version
Accept: * => YAML version
The user is authenticated by one of the following
methods, in order of priority:
* The presence of a valid JWT.
* Its IP.
* Its hostname.
In the case of the latter two methods, if authentication
is successful a JWT valid for 15 minutes will be generated
and passed back to the user in a cookie.
We try to ensure that for each sequence we have
at least FSP and LSP entries. We do this by:
* If there exists a FGSP / LGSP, we clone those as
FSP / LSP respectively.
* Otherwise, we take the first and last shots
found in the final P1 which have a preplot.
We also include log comments whenever possible and
format the azimuth a bit better.
The events endpoint will return data in the format
agreed with Multiseis if the request has an
Accept: application/vnd.seis+json
header.
Related to #12.
The reason for refactoring was to accommodate
Multiseis / client sequence exports, which will be
served by this endpoint via a specific Content-Type.
In the process, the cache has been fixed and redesigned.
Related to #12.
This is not really a substitute for proper database
design but if deemed useful it might be refactored
into a more generic caching middleware and applied
to other requests as a low-cost alternative to
database refactoring while we gain usage and
performance information.
An alert is sent whenever an endpoint returns
an error other than an explicit failure (e.g.,
it won't send an alert if a middleware intentionally
returns a {status: XXX} object).
