... and pass it to Transport.notify_flip().
This allows us to pass flip-specific information (the flip timestamp,
the new status) to transport classes.
I'm planning to change Channel.notify() signature to take a Flip
object as an argument instead of a Check object. This change is
in preparation for these changes.
If timestamps are equal, put flips chronologically after pings.
We are showing events in reverse chronological order (newer
events at the top), so the flips will now display
*above* the pings that caused them.
The live-updating code still needs float timestamps, but
we only need them for the most recent event (so we know
the lower threshold for fetching new events). We now send
the float timestamp separately:
* in the `/log/` view, we put it in HTML content, in a <script> tag
* in the `/log_events/` view we put it in response header
The main benefit of this is smaller response sizes for the
`/log/` and `/log_events/` views.
log_events was using Check.created as the lower bound.
If a check has many pings, we need to use the oldest
visible ping's date as the lower bound, otherwise
we may return notifications older than the oldest visible
ping.
* Switch from nouislider to simpler <input type="range">
* Move it to a sidebar
Also, fix a bug in _get_events where the "start" local variable
got clobbered, and made the date range for the Notification
query wrong.
If the recipient has set up an username, the responses
from Signal will return "number": null.
Example scenario:
* Alice sets up a Signal integration
* Alice sets up an username for their Signal account
* Alice deletes their Signal account
* Healthchecks sends a message to Alice's Signal account
* Signal responds with UNREGISTERED_FAILURE, but the
number field in the response is null
The fix is to:
* Allow null in the "number" field as a valid value
* Ignore the value of the "number" field when reading Signal responses
In some rare cases the last ping can be None (i.e., there was no
last ping). In these cases we would need to omit the
"Last ping was <time interval> ago." part from the message.
To avoid creating a *third* WhatsApp content template, remove
the "Last ping was <time interval> ago." part from the message
altogether.
What are the cases when last ping could be None? Here's one:
* User creates a check
* User sends a "/start" signal
* The grace time passes, the check goes down. There's no
previous "success" or "fail" signal, so the check's
"last_ping" field will be None.
