Refactor permissions to Django auth Permission and Group model

Abierto
  • ¿Algo no está bien?
#355 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
15/100
Tipo de issue
Refactorización
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
django, python
Área
authorization, backend

Línea de trabajo

This is design work, not a first task. Start by reading Meshflow/common/access.py and Meshflow/common/drf_permissions.py, then the permission matrix in docs/permissions/README.md and docs/permissions/outstanding-tasks.md. Agree on the custom permission codenames and the feeder/admin group design with maintainers before writing code. Done means the views use has_perm checks, a migration creates the groups and permissions, and the #346 access matrix tests still pass.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement permissions

Context

Follow-on from #346 (site-wide guest / user / feeder / admin model). Implementation in #354 introduces:

  • Meshflow/common/access.py — AccessLevel enum and get_access_level()
  • Meshflow/common/drf_permissions.py — custom DRF classes (AllowGuestReadOnly, IsFeederOrAdmin, etc.)
  • A single Django feeder group for trusted operators; is_staff for admin
  • Per-view permission class wiring and serializer redaction for guest reads

That delivery is intentional and shippable, but authorization logic is still mostly bespoke Python rather than declarative Django permissions.

Related work (not in scope here):

Goal (future)

Refactor toward first-class Django Permission and Group objects so that:

  1. Capabilities (e.g. trigger_traceroute, manage_api_keys, ingest_packets, manage_constellations, read_observed_node_positions) are defined as custom permissions on relevant models or a dedicated permissions app.
  2. Groups map cleanly to roles: at minimum feeder; consider whether user and admin should also be groups vs continuing to use is_staff / default authenticated user.
  3. DRF viewsets use DjangoModelPermissions, DjangoObjectPermissions, or thin wrappers that check user.has_perm(...) instead of ad-hoc user_is_feeder() scattered across views.
  4. Guest read remains explicit (unauthenticated + serializer redaction) — likely still needs custom permission classes or a documented exception list, since Django auth has no built-in “guest”.
  5. Admin surface (DX, constellation CRUD) aligns with is_staff or a dedicated meshflow_admin permission set.

Why

  • Auditability: permission matrix in docs maps to real auth_permission rows.
  • Operability: grant/revoke capabilities via Django admin or management commands without code changes.
  • Consistency: reduces drift between access.py, DRF classes, and view-level checks.
  • Extensibility: when constellation/regional ACLs return, object-level perms are already idiomatic.

Non-goals (this ticket)

  • Re-introducing ConstellationUserMembership or regional ACLs
  • Changing the four access levels product model (guest / user / feeder / admin)
  • UI route changes (stay in meshflow-ui #298)

Suggested approach (sketch)

  1. Inventory — derive permission codenames from docs/permissions/README.md matrix and current DRF permission_classes.
  2. Define permissions — migration to create Permission rows; assign defaults to feeder and staff groups.
  3. Replace helpers — migrate user_is_feeder(), user_can_manage_api_keys(), traceroute helpers to has_perm checks where possible; keep get_access_level() for serializer context / guest redaction.
  4. DRF — standardize on permission classes backed by Django perms; document guest exceptions.
  5. Tests — permission-matrix tests assert has_perm + HTTP status, not only AccessLevel.
  6. Docs — update docs/permissions/README.md with codename ↔ endpoint mapping.

Acceptance criteria

  • Custom permissions defined and listed in permissions docs
  • feeder (and admin) groups hold permissions via migrations/data migration, not only hard-coded group name checks
  • Representative viewsets use Django permission checks; no regression vs #346 matrix
  • Guest redaction behaviour unchanged (tests)
  • Management note for deploy (migrate + optional run_deploy_tasks if used)

Priority

Future / after #346 ships. Safe to schedule once #354 is merged and permissions docs are stable.

Lenguaje dominante
Python
Estrellas
1
Forks
0
Merge medio
1 d 20 h
PR fusionados (30 d)
5

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de pskillen/meshflow-api

Todos los issues de pskillen/meshflow-api

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.