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
This is a conservative upgrade.
The upgraded version of leaflet-arrowheads uses optional chaining which
seems to cause webpack to choke, so added to "transpileDependencies" in
vue.config.js.
Closes#189.
QCs may be re-run for specific sequences or for a whole
project by defining an environment variable, as follows:
For an entire project:
* DOUGAL_FORCE_QC="project-id"
For specific sequences:
* DOUGAL_FORCE_QC="project-id sequence1 sequence2 … sequenceN"
When saving shot-by-shot results for a sequence,
*all* existing QC events for that sequence will be
removed first.
We do this because otherwise we may end up with QC
data for shots that no longer exist. Also, in the
case that we have QCed based on raw data, QC results
for shots which are not in the final data would stay
around even though those shots are no longer valid.
Using timestamps does not work as we might be
importing files with timestamps older than the
last QC run. Those would not be detected by a
timestamp based method but would be by this
digest based approach.
There is a project-wide digest and per sequence
digests. The former takes the path and hashes of
all files known to Dougal for this project (the
`files` table), concatenantes them and computes
the MD5 checksum. Sequence digests do the same
but only including the files related to that
sequence.
This provides essentially the same user experience as the old
endpoint, with one exception as of this commit:
* The user is not able to “accept” or “unaccept” QC events.
We return the QC definitions tree structure, augmented with
a `sequences` attribute which contains `raw_lines` tuples
which are in turn augmented with a `shots` attribute
containing `event_log` tuples. The whole structure looks
something like:
qc_test:
qc_test:
sequences:
- sequence0:
shots: [sp0, sp1, …]
- sequence1:
shots: [sp0, sp1, …]
qc_test:
sequences:
- sequence0:
shots: [sp0, sp1, …]
…
