As we are scaling our Network (we just crossed 400 stations - 100 online!) and operations, it is essential to fine-tune our permissions model for observations. Below is a table of the proposed new permissions:
User
View Observation
Vet Observation
Delete Observation
Schedule Observation
Non Authenticated
All
None
None
None
Authenticated
All
None
None
None
Station Owner (Future)
All
None
None
None
Station Owner (Offline)
All
Own Station & Own Obs
Own Station & Own Obs
None
Station Owner (Testing)
All
Own Station & Own Obs
Own Station & Own Obs
Own Station
Station Owner (Online)
All
All
Own Station & Own Obs
All
Some notes:
Station owner status (Future, Offline, Testing, Online) will be determined taking into account all GS of a user. The higher status will be the current one. i.e. If a user has one āonlineā station and two āfutureā his/her permissions will be calculated as āStation Owner (Online)ā.
The main difference with the existing permission model is the removal of scheduling ability for users that are on āStation Owner (Offline) and (Future)ā.
Those are just the permissions computed and enforced by our backend. In practice the UI of Network could (and should) be finetuned with warnings and notices. e.g. vetting someone else station observations should have a note about familiarizing yourself with previous observations by that station.
Please provide any feedback on the proposed changes. Thanks!
Rather than scheduling being such a binary decision I would welcome any authenticated user being able to schedule observations on a time available basis. Perhaps a ālast minute optionā allowing them to fill any available times not already scheduled 72 (?) hours before the event. (Alternatively allow a station owner priority to cancel an āauthenticated userāsā scheduled observation, although that seems less attractive.)
As you can see on the proposed matrix of permissions a station owner is able to ādeleteā (thus override existing) observations scheduled for his/her station. So essentially we have already factored that in. UI (and notices) around that would be crucial but the premise is reflected on the permissions proposal.
Good point. Then since deletions are allowed, it seems that authenticated users and future station owners should be allowed to schedule observations. While it is great to encourage more stations, I think it would be good to recognize that the community is larger than those that can contribute a station.
Indeed the driving force for us to enforce a policy of āyou need an online station to schedule an observationā is the expansion of the network and the culture of fairness among contributors. That said,
you are absolutely right. But consider this: Creating an account on network.satnogs.org and even filling a form for a station (without ever putting it online) cannot be equated with suggestions on DB, coding in python, battling with kaitai structs, hunting down satellite teams to do the right thing (publish your encoding details people!) or operating a good station. There are contributions and contributions, and we need to draw the line on who gets to have scheduling rights on our production network. Also note that we are constantly listening for tracking needs from satellite teams and schedule accordingly on our network (@BOCTOK-1 and @fredy are on top of that!). Especially with auto-scheduling coming gradually online the scheduling rights will not be the most important thing.
A compromise could be that new/testing users are allowed to schedule a certain number of observations. If they want to schedule more observations they must put their own station online.
I would suggest a way to limit the utilization percentage of any station that request it. If a GS is cranking out better and better observations, I fear said station may become overwhelmed with obs requests to the point where az-el rotors exceed their duty cycle, possibly causing damage. A āmax allowable observations per hourā GS parameter would do it.
OK that sounds like it would work work for full duty-cycle limiting, but what about immediate consecutive requests? IOW, would it be possible to build-in a rest period after a search of, say, 5-10 minutes after a pass where no new observations could be started? Trying to keep the heat down in the rotator.
@windsaloft we will be implementing a āutilization factorā indeed as an owner-editable attribute of the station. Whether that would be per day, per hour or something else, is still to be determined (and most likely will be set us a setting that admins can change in network).
