[SPAM] Proposition technique : AdminPages comme entités de première classe dans django-admin

[kaliguito]

Code of Conduct

• I agree to follow Django's Code of Conduct

Feature Description

SPAM

Proposition technique : AdminPages comme entités de première classe dans django-admin

Problème technique identifié

django.contrib.admin est architecturé autour du concept de ModelAdmin, ce qui rend l’enregistrement de fonctionnalités non liées à des modèles artificiel ou détourné (vues ad hoc, faux modèles, applications techniques).

Les solutions existantes (ex. AdminPlus) permettent d’ajouter des vues personnalisées, mais elles restent :

• rattachées à une application,
• non équivalentes à ModelAdmin,
• limitées pour la construction de véritables tableaux de bord.

---

Objectif

Introduire le concept d’AdminPage comme entité de première classe dans l’admin Django, indépendante de tout modèle.

---

Pseudo-API proposée

from django.contrib.admin import AdminPage, register_page
from django.http import HttpRequest
from django.template.response import TemplateResponse

class AnalyticsPage(AdminPage):
    title = "Analytics"
    section = "Pages"
    slug = "analytics"
    icon = "chart-line"
    permission_required = "reports.view_analytics"

    def has_permission(self, request: HttpRequest) -> bool:
        return request.user.has_perm(self.permission_required)

    def get_context_data(self, request):
        return {
            "total_users": 1240,
            "active_today": 87,
        }

    def view(self, request: HttpRequest):
        return TemplateResponse(
            request,
            "admin/analytics.html",
            self.get_context_data(request),
        )

register_page(AnalyticsPage)

---

Comportement attendu

• Enregistrement global via AdminSite, sans dépendance à une application
• Apparition dans l’index de l’admin sous une rubrique dédiée ou par défaut
• URLs internes de type /admin/pages/<slug>/
• Intégration native au système de permissions Django
• Aucune dépendance à un modèle ou à des permissions factices

---

Cas d’usage

• Dashboards métier
• Pages de monitoring
• Interfaces internes non orientées données
• Back-office applicatif pour petites équipes

---

Bénéfices

• Réduction du besoin de dashboards externes
• Réutilisation complète de l’authentification, des permissions et de l’UI admin
• Extension naturelle de django-admin sans rupture de compatibilité
• Alternative légère aux solutions de back-office parallèles

Problem

Proposition technique : AdminPages comme entités de première classe dans django-admin

Problème technique identifié

django.contrib.admin est architecturé autour du concept de ModelAdmin, ce qui rend l’enregistrement de fonctionnalités non liées à des modèles artificiel ou détourné (vues ad hoc, faux modèles, applications techniques).

Les solutions existantes (ex. AdminPlus) permettent d’ajouter des vues personnalisées, mais elles restent :

• rattachées à une application,
• non équivalentes à ModelAdmin,
• limitées pour la construction de véritables tableaux de bord.

---

Objectif

Introduire le concept d’AdminPage comme entité de première classe dans l’admin Django, indépendante de tout modèle.

---

Pseudo-API proposée

from django.contrib.admin import AdminPage, register_page
from django.http import HttpRequest
from django.template.response import TemplateResponse

class AnalyticsPage(AdminPage):
    title = "Analytics"
    section = "Pages"
    slug = "analytics"
    icon = "chart-line"
    permission_required = "reports.view_analytics"

    def has_permission(self, request: HttpRequest) -> bool:
        return request.user.has_perm(self.permission_required)

    def get_context_data(self, request):
        return {
            "total_users": 1240,
            "active_today": 87,
        }

    def view(self, request: HttpRequest):
        return TemplateResponse(
            request,
            "admin/analytics.html",
            self.get_context_data(request),
        )

register_page(AnalyticsPage)

---

Comportement attendu

• Enregistrement global via AdminSite, sans dépendance à une application
• Apparition dans l’index de l’admin sous une rubrique dédiée ou par défaut
• URLs internes de type /admin/pages/<slug>/
• Intégration native au système de permissions Django
• Aucune dépendance à un modèle ou à des permissions factices

---

Cas d’usage

• Dashboards métier
• Pages de monitoring
• Interfaces internes non orientées données
• Back-office applicatif pour petites équipes

---

Bénéfices

• Réduction du besoin de dashboards externes
• Réutilisation complète de l’authentification, des permissions et de l’UI admin
• Extension naturelle de django-admin sans rupture de compatibilité
• Alternative légère aux solutions de back-office parallèles

Request or proposal

request

Additional Details

No response

Implementation Suggestions

No response

[github-actions]

Thank you kaliguito for sharing your idea! We have a lot of them so please be patient. You can see the current queue here.

Community instructions

For commenters, please use the emoji reactions on the issue to express support, and/or concern easily. Please use the comments to ask questions or contribute knowledge about the idea. It is unhelpful to post comments of "I'd love this" or "What's the state of this?"

Reaction Guide

• 👍 This is something I would use
• 👎 This is something that would cause problems for me or Django
• 😕 I’m indifferent to this
• 🎉 This is an easy win

[nessita]

@kaliguito Please refrain from posting AI slop in this repo. Further posting without careful review will result in your account being blocked at the organization level.