* Renamed verified to good
* Renamed no_data to bad
* Add failed status
* Remove unused data_not_verified
* Expose vetted status to API
* Simplify vetted status template markup
* Simplify vetted methods
* Utilize sass for vetted statuses
* Add option to undo vetting
* Add on_delete option to all ForeignKey fields
* Adjust all views
* Adjust initialize command
* Refactor tests
* Refactor API to make these changes transparent
* Adjust all templates
* UI refreshment on Observation tepmplate
* Add STRICT_TRANS_TABLES for mariadb
* Minor text changes to tle command
* Update requirements
Continue to use 'frequency' as minimum and displayed frequency. Adds a 'frequency_max' to provide a range we can use for an antenna.
fixessatnogs/satnogs-network#217
Stores the rising azimuth, max altitude, and setting azimuth for each payload scheduled in an observation when an observation is scheduled. This will help in comparing passes (ie: high pass vs low pass, obstructions, etc).
The view will not display anything if this data is missing, so legacy entries in the database that do not have this data will still display fine.
Fixessatnogs/satnogs-network#278
my new function for has_no_data in the Observation model was backward
this fix returns true iff all data in an observation is marked bad,
as was originally intended
Model change (with migration 0006) adds 3 fields to Data:
vetted_status (charfield with options for data status, default "unknown")
vetted_user (who vetted the data)
vetted_datetime (when it was vetted)
In addition, various boolean functions are added for the Data model
to check statuses. More functions are added to the Observation model
to check status of verification within an observation as well, assuming
multiple data entries in an Observation. With these, I also changed
"has_data" to "has_submitted_data" to be more specific alongside the
others.
For UX, we add a green check sign or red removal sign to the data
header in Observation view (along with green/red datetime in the footer)
if a data is verified good or bad, respectively. If there is an unknown
status, the data header is given a thumbs-up and thumbs-down button to
verify the data good or bad. These icons are only offered to is_staff,
the observation requestor, and any station owner in the observation.
These buttons trigger new URLs/functions in view:
data_verify(id)
data_mark_bad(id)
Returning the user back to the originating Observation page.
In the observation lists I changed the coloring of the ID button to be:
Future: light blue (same)
No uploaded data and/or all vetted bad data: red
Some or all unvetted data with no verified good data: orange
Some or all verified good data: green
These changes are reflected in the observations.html, home.html, and
user_detail.html templates.
solves satnogs/satnogs-network#171
This commit adds a "horizon" configuration item to stations. This
allows station owners to set a minimum horizon to avoid a noisy
or obstructed floor level.
The default minimum horizon is set to 10, which is still fairly
low for a satellite pass that could be captured but given the
appropriate setup someone may be successful setting it lower.
The horizon field is honored in both the calculation of upcoming
passes in the station view as well as excluding any "below horizon"
passes in prediction_windows.
In addition, the db migration will set a minimum horizon of "10"
for all existing stations in the network. This is the horizon that
was hard-coded for the upcoming passes view so the only change to
the end user will be the behavior of window prediction matching
the upcoming passes (along with the ability to configure their
minimum horizon, of course).
Nikos Roussos