Skip to content
ARGUS User Manual

Permission errors

ARGUS permission errors usually originate from Firestore rules or from a role check in the web client. This page maps each common “denied” toast to its cause and the fix an operator or admin can apply.

”Permission denied” on a mission document

You can see the mission card but opening it shows a denied toast or an empty op.

Likely causes:

  1. You are not a participant. The mission’s Firestore rule requires your UID in the participants[] array. Commanders add participants from Mission → Edit → Participants.
  2. Wrong organisation. Missions are scoped to a single org. If your account switched org (via the org switcher) and the mission belongs to a different one, you won’t see it. Switch back.
  3. Mission archived. Archived missions are read-only and the app hides their ops. Unarchive from the dashboard (admin or commander) if you need to re-enter the op.

”Can’t Edit this mission”

The Edit button is greyed out or the wizard opens read-only.

  • You are not a commander on the op or an organisation admin. Ask a commander to promote you or to make the edit for you.
  • The mission is completed or cancelled. Completed missions are immutable by design — the after-action report is built against a frozen state. If you really need to edit a closed mission, an admin can re-open it but the audit log will show the reopen.

”Can’t take DRC authority”

You hit the DRC take-authority button and the toast says “denied” or “another operator has authority”.

  • Only one operator holds DRC at a time. Check the op toolbar — the current holder is named. Coordinate with them over PTT or chat.
  • Authority is commander-overridable: a commander on the op can force-transfer authority, which kicks the current holder. Forced transfers are logged to the blackbox and the audit log.
  • If you lost authority mid-op because someone took it from you, their name and timestamp are both in the timeline.

”Can’t see DJI docks”

Dock list is empty or some docks you expect are missing.

  • No role that grants dock visibility. Dock visibility needs Operator, Commander or Admin on the org. Observers only see live streams, not dock administration.
  • Docks paired to a different org. A dock’s updateTopo ties it to one org at a time. If it was repaired to another org, it disappears from yours until repaired back.
  • Org scope switched. Same as mission — if you switched orgs in the top bar, the list is scoped to the new one.

”Can’t export mission” / “Can’t delete mission”

Export requires commander or admin. Delete requires admin and is rate-limited to prevent accidental mass-deletion. Both actions are logged.

Audit log

Every permission-sensitive action — role changes, forced DRC transfers, legal-hold placements, geofence emergency-suspend co-signs, org scope changes, dock re-pair — is recorded in Admin → Audit. If you think a denial is wrong, check the audit log: it will either show the action that put you in this state or its absence will tell you the cause is elsewhere (a rule mismatch rather than an admin action).

The audit log is filterable by user, mission, action type and date. An admin can export a filtered view as CSV for an incident report.

When the denial is wrong

If the denial is genuinely wrong (the role is right, the org is right, the mission is current) the cause is almost always a rules deployment out of sync. Ask an admin to check that Firestore rules deployed cleanly to the production project.