Saltearse al contenido

Errores de permisos

Los errores de permisos de ARGUS suelen originarse en las reglas de Firestore o en una comprobación de rol en el cliente web. Esta página mapea cada toast de “denegado” común a su causa y a la solución que un operador o administrador puede aplicar.

”Permiso denegado” en un documento de misión

Puedes ver la tarjeta de misión pero al abrirla aparece un toast de denegado o una operación vacía.

Causas probables:

  1. No eres participante. La regla de Firestore de la misión requiere tu UID en el array participants[]. Los comandantes añaden participantes desde Misión → Editar → Participantes.
  2. Organización equivocada. Las misiones están delimitadas a una única organización. Si tu cuenta cambió de organización (vía el selector de organización) y la misión pertenece a otra, no la verás. Cambia de vuelta.
  3. Misión archivada. Las misiones archivadas son de solo lectura y la app oculta sus operaciones. Desarchivar desde el panel (admin o comandante) si necesitas volver a entrar en la operación.

”No puedes editar esta misión”

El botón Editar está deshabilitado o el asistente se abre en solo lectura.

  • No eres comandante en la operación ni administrador de la organización. Pide a un comandante que te promueva o que haga la edición por ti.
  • La misión está completada o cancelada. Las misiones completadas son inmutables por diseño: el informe posterior a la acción se construye contra un estado congelado. Si realmente necesitas editar una misión cerrada, un administrador puede reabrirla, pero el log de auditoría mostrará la reapertura.

”No puedes tomar autoridad DRC”

Pulsas el botón de tomar autoridad DRC y el toast dice “denegado” o “otro operador tiene la autoridad”.

  • Solo un operador mantiene DRC a la vez. Revisa la barra de herramientas de la operación: el titular actual está nombrado. Coordina con él vía PTT o chat.
  • La autoridad es anulable por el comandante: un comandante en la operación puede forzar la transferencia de autoridad, lo que desplaza al titular actual. Las transferencias forzadas se registran en la blackbox y en el log de auditoría.
  • Si perdiste la autoridad a mitad de la operación porque alguien te la quitó, su nombre y marca de tiempo están ambos en la línea de tiempo.

”No puedes ver los docks DJI”

La lista de docks está vacía o faltan algunos docks que esperas.

  • Ningún rol que conceda visibilidad del dock. La visibilidad de los docks necesita Operador, Comandante o Admin en la organización. Los observadores solo ven los streams en vivo, no la administración de docks.
  • Docks emparejados a una organización diferente. El updateTopo de un dock lo ata a una organización a la vez. Si se reparó a otra organización, desaparece de la tuya hasta que se vuelva a emparejar.
  • Scope de organización cambiado. Igual que la misión: si cambiaste de organizaciones en la barra superior, la lista está delimitada a la nueva.

”No puedes exportar la misión” / “No puedes eliminar la misión”

Exportar requiere comandante o admin. Eliminar requiere admin y está limitado en tasa para prevenir eliminación masiva accidental. Ambas acciones se registran.

Log de auditoría

Cada acción sensible a permisos — cambios de rol, transferencias DRC forzadas, colocaciones de retención legal, cofirmas de suspensión de emergencia de geofence, cambios de scope de organización, re- emparejamiento de dock — se registra en Admin → Auditoría. Si crees que una denegación es errónea, revisa el log de auditoría: o bien mostrará la acción que te puso en este estado, o bien su ausencia te indicará que la causa está en otra parte (un desajuste de reglas en lugar de una acción de administrador).

El log de auditoría es filtrable por usuario, misión, tipo de acción y fecha. Un administrador puede exportar una vista filtrada como CSV para un informe de incidente.

Cuando la denegación es errónea

Si la denegación es genuinamente errónea (el rol es correcto, la organización es correcta, la misión está en curso) la causa es casi siempre un despliegue de reglas desincronizado. Pide a un administrador que revise que las reglas de Firestore se desplegaron limpiamente al proyecto de producción.

Relacionado