Telescope access
This page is the owner-facing model for who can observe with your telescope and how their time is prioritized. There are four things to know:
- Telescope ownership — who has full administrative control.
- Observing queues — the prioritized lanes that time on your telescope is divided into.
- Queue access grants — who can hold time on a given queue.
- Observing accounts — how those grants are bundled and presented to the people actually submitting observations.
Together these let you delegate time without delegating control, and share the telescope across audiences (institutional research, education, external collaborators, ToO follow-up) without conflating them.
Telescope ownership
Telescopes are owned by an entity — either an organization or an individual user. The owner has full administrative control: configuration, queues, access policy, and the ability to flip the telescope between automated and manual control.
A telescope's owner can additionally issue
TelescopeAccessGrants that delegate read, update, or delete
authority on the telescope record itself to other users, organizations,
or groups — useful for shared operations between a host institution and
a collaborating group.
Observing queues
Each telescope carries an ordered list of observing queues. A queue is a named lane of time — e.g. Maintenance, General Observing, ToO (target of opportunity), Education — and the order on the telescope is its priority order. The scheduler tries to satisfy higher queues first; lower queues fill remaining time.
Each queue has its own prioritization model:
- Static prioritization — fixed priority levels that don't change over time. Best for fully manual allocation policies.
- Schedule-based allocation — time on the queue is distributed according to a calendar (e.g. "this group has Mondays, that one has Tuesdays").
- Usage-based allocation — priority adjusts dynamically based on how much observing time each grantee has used relative to their allocation. Best for fairness across many users.
Queues are the right tool for coarse allocation policy ("classroom gets 20% of clear nights"); within a queue, observation requests compete by their own priority and the scheduler's slew/overhead model.
Queue access grants
An ObservingQueueAccessGrant says "this entity is allowed to put
observations through this queue, with this much weight." Grants can be
issued to users, organizations, or groups, and they can be revoked at
any time.
A queue without any access grants is reachable only by the telescope owner. As you grant access, you build up the audience of the queue.
Observing accounts
An observing account is what observers see — the practical handle they submit observations against. Internally it's a bundle of one or more queue access grants, possibly spanning multiple telescopes, aggregated under a single owner.
That layer exists for three reasons:
- Resource aggregation. A consortium with grants on five different telescopes can aggregate them into one observing account so its members don't have to think about which queue to hit for each request — the scheduler picks among eligible telescopes.
- Permission delegation. The account's owner controls who can submit observations through it. A research group lead can give submit-rights to their students without those students being personally grant-holders on the underlying queues.
- Quota throttling. Both the account and each grant under it
can carry one or more quotas
—
(period, max_credits)rules that cap how much can be spent within a window. Multiple quotas compose (a lifetime cap plus a rolling weekly cap, for example); all active quotas must be satisfied. This is where a parent grant can say "this delegated subaccount may not consume more than X per week" independently of the overall pool's policy.
So the flow is: owner → grants → account → observer. The owner issues queue access grants to entities. Those entities create observing accounts that bundle their grants. Members of those entities submit observations through the accounts.
In the web app
The owner-facing UI for this lives in the React port at:
org-telescope-queues.tsx— edit queues, their order, and prioritization models.org-telescope-access-grants.tsx— manage telescope-level access grants.org-settings-observing-policy.tsx— observing policy and operational constraints.
The Angular site has equivalents under
apps/website/src/app/features/entity/telescopes/.
Reference
ObservingQueueAccessGrant Schema
Properties
| Name | Type | Description |
|---|---|---|
| id | Integer |
The unique identifier for the queue access grant. |
| queue_id | Integer |
The ID of the queue to which the allocation belongs. |
| telescope_access_grant_id | Integer |
The ID of the telescope access grant providing access to this queue. |
| order | Integer |
The order used to prioritize this allocation within the queue. Lower values are higher priority. |
| revoked | Boolean |
Whether this allocation has been revoked. If true, the allocation is no longer valid. |
| effective_order | Integer |
The effective order used to prioritize thisa llocation within the queue, taking into account the queue's prioritization policy and the allocation's own priority. |
| time_used | Float |
The total time used by the account regardless of whether it was contested or not. |
| time_contested | Float |
The total time used by the account when sibling accounts also had observations which could have been scheduled. |
| time_waiting | Float |
The total time that the other accounts used while this account was waiting for its observations to be scheduled. |
| observing_policy_id | Integer (Optional) |
No description |
Relationships
| Relationship Name | Type |
|---|---|
| queue | ObservingQueue |
| telescope_access_grant | TelescopeAccessGrant |
| observing_accounts | ObservingAccount |
| observing_policy | ObservingPolicy |
ObservingAccount Schema
Properties
| Name | Type | Description |
|---|---|---|
| id | Integer |
Unique identifier of the observing account. |
| owner_id | Integer |
No description |
| managing_group_id | Integer (Optional) |
No description |
| name | String(256) (Optional) |
No description |
| slug | String(256) (Optional) |
No description |
| source_account_id | Integer (Optional) |
The ID of the parent node in the hierarchy. Null if this node is a root. |
| source_account_grant_id | Integer (Optional) |
The ID of the delegated observing grant that links this subaccount to its parent. Composite FK in table_args enforces that the grant's account_id matches source_account_id. |
| path | LtreeType() (Optional) |
The materialized path using the PostgreSQL ltree type, representing the hierarchical structure for efficient querying. [Automatically set by trigger] |
| credits_used | Float |
No description |
| is_deleted | Boolean |
Whether the observing account has been archived. |
| order | Integer |
The order used to prioritize the account among its siblings. Lower values are higher priority. |
| last_activity_on | DateTime (Optional) |
No description |
| observing_policy_id | Integer (Optional) |
No description |
Relationships
| Relationship Name | Type |
|---|---|
| observing_policy | ObservingPolicy |
| owner | Entity |
| managing_group | Group |
| observing_grants | ObservingGrant |
| quotas | ObservingQuota |
| queue_access_grants | ObservingQueueAccessGrant |
| source_account_grant | DelegatedObservingGrant |
| source_account | ObservingAccount |
| subaccounts | ObservingAccount |
| ancestors | ObservingAccount |
| descendants | ObservingAccount |
| root_account | ObservingAccount |