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.
The next sequence to shoot is normally retrieved from the
database via getSequence(), but it returns false if no
sequences have been shot yet.
In that case we use a default value of `1` to build the
name of the planned line.
Fixes#81Fixes#82
The `sequences` object now carries the attribute
`has_smsrc_data`, a boolean which is true iff
there is at least one `smsrc` record in the raw
shots metadata.
This is used by:
1. A new sequence-wise test which reports if gun
data is missing for the entire sequence.
2. The individual `missing_gun_data` test which
is inhibited if `has_smsrc_data` for the
corresponding sequence is false.
Closes#93.
We now check that a file is at least a few seconds old
before attempting to import it.
The actual minimum age can be configured in etc/config.yaml or
else is defaults to 10 seconds.
The idea is that this should give the OS enough time to fully
write the file before we import it.
The timestamp being looked at is the modification time.
Fixes#92.
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
When running `npm install`, a self-contained HTML document
with the contents of the OpenAPI specification is saved as
openapi.html in the same directory as openapi.yaml.
By default, change just the number of the sequence
being edited. It is checked for conflict with other
planned sequences but not with anything already acquired.
If the user ticks the ‘shift all’ checkbox, then all
planned sequences are shifted by the same amount.
If there are other lines in the planner, we increment the
highest numbered sequence in the planner by one.
If there are no planned lines, we take the highest numbered
raw sequence and increment by one.
Shows whether the user is logged in and presents
appropriate options according to whether this is
a manual or automatic login (a manual login is
when the user explicitly logs in with a user name
and password).
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.
This is a very basic implementation and doesn't
check that the points are indeed valid.
A proper solution is to request the list of preplots
for that line from the server and validate against those.
