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.
