It replaces the `Actions` column in the old table and provides
more actions.
The user can now edit not just the comments and labels but also
the timestamp / shotpoint as requested in #78 (closes#78).
Because events are grouped by timestamp / shotpoint (each row
represents a unique timestamp or shotpoint), the behaviour is
slightly different depending on whether the user clicks on a
row containing a single (editable) event, or on one of multiple
editable events in the same row. Also, rows containing only
read-only events are recognised and no edition actions are
provided for those.
It implements the same functionality as in other tabs
such as sequences, lines, etc., but it is disabled here
because in my opinion it doesn't look too nice.
It will probably be a matter of enabling it at some point
and asking for feedback on user preference.
Returns a list of labels used in the current view,
in order of popularity (most used first).
NOTE: this property is not actually used. It's
technically dead code.
This assumes that adding or removing labels is a relatively
common action to do on an event and provides a quicker
and simpler mechanism than bringing up the full event
dialogue.
This is meant to be invoked from a context menu action or
similar.
When an event has been modified, this control opens a dialogue
where the previous version of the event may be reviewed and if
necessary restored.
Technically, this was the quid of and closes#138.
This reports the current server version, from Git by
default.
Also, and of more interest, it reports whether the
current database schema is compatible with the
server code.
This code implements the backend processing side
of the ASAQC queue, i.e., the bit that communicates
with the remote API.
Its expected use it to have it running at regular
intervals, e.g., via cron. The entry point is:
lib/www/server/queues/asaqc/index.js
That file is executable and can be run directly
from the shell or within a script. Read the comments
in that file for further instructions.
These functions, in general following the same HTTP-verb
approach as the rest of the database interface, are for
use with both the HTTP API and the queue processor.
