* It accepts a `precision` parameter which truncates the timestamp to a
give precision. Can be `seconds`, `minutes`, `hours` or `days` / `date`.
* It tries to be more flexible in what it accepts as input.
* It accepts an input of "now" which returns the current timestamp. Can
be used along with `precision`.
We move most of the logic from the client (as it was until now) to the
server.
The PATCH command maintains the same format but it should provide only
one of the following keys per request:
* ts0
* ts1
* speed
* fsp
* lsp
* lagAfter
* sequence
Earlier keys in the list above take priority over latter ones.
The following keys may be provided by themselves or in combination with
each other (but not with any of the above):
* name
* remarks
* meta
As a special case, an empty string as the `name` value causes the name
to be auto-generated.
See comments in the code `patch.js` for details on the update logic.
* A ‘sun’ icon is shown when a line starts and ends in daytime
* A ‘moon’ icon is shown when a line starts and ends in nighttime
* A ‘sun/moon’ icon is shown in other cases
Sunrise and sunset times are provided as a tooltip when hovering over
the icon.
Closes#72.
The INSERT INTO raw_lines / final_lines will not always be executed as
the lines may already exist (particularly in raw_lines because of
*online*), so whether it worked or not we merge the metadata immediately
afterwards (this may cause an extra notification to be fired).
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.
Resolve "Make event log entries for start and end of line upon import of final sequence, if the entries do not already exist"
Closes#57
See merge request wgp/dougal/software!11
These files contain the sequence of SQL commands needed to bring
a database or project schema up to date with the latest template
database or project schema.
These files must be applied manually. Check the comments at the top of
the file for instructions.
The reason why need to do it like this instead of relying on a trigger
is because the entry in final_lines is created first and the final_shots
are populated. If we first the trigger on final_lines it is not going
to find any shots; if we fire it as a row trigger on final_shots it
would try to label every point in sequence as it is imported; finally if
we fire it as a statement trigger on final_shots we have no idea which
sequence was imported.
Adds:
* label_in_sequence (_sequence integer, _label text):
Returns events containing the specified label.
* handle_final_line_events (_seq integer, _label text, _column text):
- If _label does not exist in the events for sequence _seq:
it adds a new _label label at the shotpoint obtained from
final_lines_summary[_column].
- If _label does exist (and hasn't been auto-added by this function
in a previous run), it will add information about it to the final
line's metadata.
* final_line_post_import (_seq integer):
Calls handle_final_line_events() on the given sequence to check
for FSP, FGSP, LGSP and LSP labels.
* events_seq_labels_single ():
Trigger function to ensure that labels that have the attribute
`model.multiple` set to `false` occur at most only once per
sequence. If a new instance is added to a sequence, the previous
instance is deleted.
* Trigger on events_seq_labels that calls events_seq_labels_single().
* Trigger on events_timed_labels that calls events_seq_labels_single().
Not sure if this helps much. It might help with avoiding
out of order notifications and reducing the rate at which
the clients get spammed when importing database dumps and
such, but that hasn't been tested.
This also implements a generic handler mechanism that can be
reused for other purposes, such as sending email / XMPP notifications,
doing real-time QC checks and so on.
Fixes#113.