Running on bare metal, 127.0.0.1 is a sensible choice of address
to bind on, but that is not the case when running inside a
container, so we add the ability to choose which IP to listen on.
This can be given via the environment variable HTTP_HOST when
starting the server or, if used as a module, as the second
argument of the start(port, host, path) function.
The postinstall script will (rightly) return non-zero if the API
docs cannot be built, but this creates a problem when building a
container (Docker) image. In that case, we expect the postinstall
to fail, as the required files (spec/*) will not have been copied
into the image when `npm install` is run.
By adding an explicit OR clause we allow postinstall to end
gracefully whether or not the API docs have been built.
This event handler checks if there is an UTC date jump between
consecutive shots. If a jump is detected, it sends to new entries
to the event log, for the last shot and first shot of the previous
and current dates, respectively.
Fixes#223.
Events being created or edited via the API now call
replace_placeholders() making it possible to use
shortcuts to enter some event-related information.
See #229 for details.
We take the first label associated with the event (if any) and use
the label's colour for the event marker. We override the colour for
QC events and use a default value for events with no labels or if
the label does not have an associated colour.
It uses https://github.com/debug-js/debug but it is meant to be
called like this:
const debug = require("DOUGAL_ROOT/debug")(__filename);
That way the calling module's path is used as the debug namespace.
This can be used as a shortcut when requiring a module from deep
within the file hierarchy, e.g., instead of:
require("../../../../lib/db");
one can do:
require("DOUGAL_ROOT/lib/db");
Strictly speaking, it doesn't consider (or know) what the shooting
status is (but see #214). All it does is colour events differently
if they have all three of: sequence, point and timestamp.
This is probably good enough for the time being to close#134.
Related to #206. If this is indeed what is causing the alerts,
we will change the logic so that it simply logs (or ignores)
invalid speeds rather than throwing.
When importing an old project, the first QC run could take a while
and cause a bit of backlog, but during normal shooting it is expected
that it will finish quite quickly (and this is monitored anyway).
NOTE: guests still do have access to the relevant API endpoint.
In theory, a persistent and computer literate guest user could
visit the API endpoint directly and retrieve the edit history.
As the edit history may need to be given to users who otherwise
do not have write access, it is considered quite acceptable to
allow guest users to access the endpoint.
Closes#194.
Commands used:
find . -type f -name '*.js'| while read FILE; do if echo $FILE |grep -qv node_modules; then sed -ri 's/^\s+$//' "$FILE"; fi; done
find . -type f -name '*.vue'| while read FILE; do if echo $FILE |grep -qv node_modules; then sed -ri 's/^\s+$//' "$FILE"; fi; done
find . -type f -name '*.py'| while read FILE; do if echo $FILE |grep -qv node_modules; then sed -ri 's/^\s+$//' "$FILE"; fi; done
In a label definition (in etc/surveys/*.yaml) we can now have
"dark" or "light" attributes under "view" to force the label
text to always use either the dark or light theme. This is
useful when a label's colour causes a bad contrast in either
theme.
Example:
labels:
Daily:
view:
colour: "#EFEBE9"
description: "Of interest in the daily report"
light: true # Text always displayed in a dark colour
model:
user: true
multiple: true
