SatNOGS Network Permissions proposal 2019-01

Hello all,

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:

  1. 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)”.
  2. The main difference with the existing permission model is the removal of scheduling ability for users that are on “Station Owner (Offline) and (Future)”.
  3. 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!


I think that seems totally fair and reasonable.

That looks good to me!

1 Like

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.

1 Like

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 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.

1 Like

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.

1 Like

‘per hour’ could be too short, there are maybe around four “full” passes per hour.
‘per 24 hours’ would be better I think!

Anyway: a duty-cycle should be implemented. :slight_smile:

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).


Excellent news! Thank you @pierros !

1 Like

The new permission mode is now active in network, if you see any bug please open an issue.

Wiki page is also updated.