Consumer feedback drop — production-Django pilot (2026-05-26)

[MartinCastroAlvarez]

A production Django + React integration team did a pilot of 0.1.0a1, mounting the SPA at a second admin path alongside their existing legacy admin. The library installs cleanly, the registry / list / detail / create / update / destroy endpoints behave as the docs promise, and the security posture (CSRF on, no @csrf_exempt, opaque 404 bodies, Cache-Control: no-store on every response, sensitive-name denylist, ModelAdmin as the single source of truth) held up to a full source audit. Nothing security-shaped is blocking adoption.

What is blocking adoption past the simplest leaf models is a set of standard django.contrib.admin features that aren't wired up yet. The team filed twelve generic, anonymized issues capturing each gap and a single requirements doc summarizing them.

Artifacts

• Requirements doc (lives in the repo): docs/consumer/requirements-pilot-2026-05-26.md — generic, anonymized requirements with per-issue acceptance signals.
• Tracker board: django-admin-react roadmap — all 12 issues with initial Priority / Area / Phase.

Issues filed (all labeled enhancement)

Theme	Issues
Read + Write	#54 inlines, #55 M2M, #57 files, #60 field-type vocabulary
List UX	#56 list_filter, #62 date_hierarchy
Write	#58 admin actions, #61 list_editable + bulk PATCH
Lookup ergonomics	#59 autocomplete / raw_id_fields
SPA UX	#63 session-expiry contract
DX	#64 OpenAPI / schema endpoint
Extensibility	#65 frontend extension points

Headlines

• No security findings. Audit was clean — staff+CSRF gate, no outbound network in source, no telemetry in the bundle, opaque 404 bodies, Cache-Control: no-store on every response. The only "watch this" notes are operational (security@ placeholder, source maps in the wheel) — already in the requirements doc §5.
• The library is safe to ship alongside the legacy admin today, on a second path, behind a settings flag — even at 0.1.0a1.
• It is not yet ready to replace the legacy admin for heavier models. Inlines, list_filter, admin actions, M2M, file uploads, and date_hierarchy are the big rocks. None of them are "research projects" — they're well-trodden Django primitives with clear acceptance signals in the issues.
• ModelAdmin as the single source of truth is the right call. The extension points asked for in Extend field type vocabulary: JSONField, ArrayField, range types, duration — plus a register_field_type hook #60 and Frontend extension points: per-model widgets, panels, and actions without forking #65 are scoped to plug into that contract, not work around it.

Suggested triage

From a real-adoption standpoint:

1. P0 / v0.1 — Support Django inlines (TabularInline / StackedInline) in detail view and writes #54 inlines + ManyToMany read + write support (currently "unsupported" in v1) #55 M2M (every non-trivial app has these) + Surface ModelAdmin.list_filter (boolean / choice / FK / date / SimpleListFilter) in list responses #56 list_filter
2. P1 / v0.1 — FileField / ImageField support — multipart upload, signed download, clearing #57 files, Surface ModelAdmin.actions in the SPA and add a bulk-action endpoint #58 actions, autocomplete_fields / raw_id_fields support for high-cardinality FKs #59 autocomplete, date_hierarchy drill-down + date-range list filtering #62 date_hierarchy
3. P1 / v0.2 — Extend field type vocabulary: JSONField, ArrayField, range types, duration — plus a register_field_type hook #60 field types, list_editable in-list editing + bulk PATCH endpoint #61 list_editable, Session expiry / 401 handling: document the SPA contract for "signed in → not anymore" #63 session expiry
4. P2 / v0.2 — Machine-readable schema endpoint (OpenAPI 3.1) for the envelope shapes #64 schema, Frontend extension points: per-model widgets, panels, and actions without forking #65 frontend extension points

Happy to pair with the maintainer on any of these once they're picked up.

— posted from a production Django integration pilot