v0.13.0

Changé — compatibilité NetBox élargie à la 4.5

Le plancher passe de 4.7.0 à 4.5.0, et ce n'est pas une déclaration : les 91 tests
s'exécutent désormais sur NetBox 4.5.10 et 4.7.0 à chaque poussée.

• min_version = "4.5.0". L'ancienne valeur était une prudence posée à la conception, jamais
  éprouvée. Aucune API propre à la 4.7 n'est employée — pas même les panneaux déclaratifs, qui
  existent déjà en 4.5.
• Trois migrations épinglaient des nœuds propres à la 4.7 : extras 0144, ipam 0097,
  tenancy 0026… là où la 4.5 s'arrête respectivement à 0134, 0086 et 0023. Le graphe de
  migration refusait de se résoudre, et le plugin était donc ININSTALLABLE sur toute version
  antérieure. Les dépendances pointent maintenant vers des migrations squashed, présentes de la
  4.5 à la 4.7.
• La matrice d'intégration continue couvre les deux versions. Sans cela, la compatibilité se
  perdrait à la première migration générée : makemigrations réépingle la dernière migration de
  l'hôte sur lequel il tourne.

Aucun effet sur les installations existantes. Django n'utilise les dépendances que pour
ordonner le graphe ; l'état appliqué est enregistré par nom de migration.

Corrigé — dans la documentation

• Le README affirmait qu'une version hors bornes « fait échouer le démarrage explicitement ».
  C'est faux : NetBox émet un avertissement dans ses journaux et charge le reste. Le menu
  n'apparaît pas, et rien dans l'interface ne dit pourquoi. Le tableau de dépannage porte
  désormais la commande qui le révèle.

Changé — l'installation passe par PyPI

• Le Dockerfile n'a plus besoin de git. Trois lignes remplacent l'installation depuis un
  dépôt, son apt-get install git et le purge qui suivait :
  uv pip install "netbox-plugin-applications==X.Y.Z". Moins de couches, moins de surface.
• L'installation classique devient pip install netbox-plugin-applications==X.Y.Z.
• La voie hors ligne se simplifie : pip download … --no-deps remplace le clone suivi d'une
  construction. Les deux autres sources restent documentées — la roue attachée à chaque release,
  ou une construction depuis les sources.
• Procédure hors ligne rejouée telle qu'elle est écrite, en partant de pip download :
  construction --network none, plugin en 0.12.0, gabarits et migrations présents,
  manage.py check sans anomalie.

v0.12.0

Sécurité — élévation de privilège corrigée

Un compte dépourvu de TOUTE permission pouvait créer une application et son déploiement par
l'assistant de déclaration, et lire le nom des applications du catalogue sur la page
« Démarrer » — alors que l'API et les listes lui répondaient 403.

• Cause : les vues génériques de NetBox portent une garde de permission ; django.views.View
  n'en porte aucune. Les deux vues écrites à la main — DemarrerView et AssistantView — n'en
  héritaient donc rien.
• Correction : ObjectPermissionRequiredMixin. La page « Démarrer » exige
  view_application ; l'assistant exige add_application ET add_deployment, puisqu'il
  crée les deux dans la même transaction — n'en vérifier qu'une laisserait créer l'autre sans
  droit.
• Portée : toute version de 0.9.0 à 0.11.3, pour quiconque a des comptes NetBox en lecture
  seule. Aucune donnée n'est exposée à un visiteur non authentifié : LOGIN_REQUIRED de NetBox
  s'applique.

Mettre à jour si des comptes non administrateurs ont accès à NetBox.

Ajouté

• 8 tests de permission, dont un qui parcourt toutes les routes du plugin et échoue si
  l'une d'elles ne déclare aucune garde — il attrapera la prochaine vue écrite à la main, pas
  seulement les deux corrigées.

Le piège qui a failli me tromper en corrigeant : NetBox n'évalue pas
user.user_permissions mais ses propres objets ObjectPermission. Un test qui accorde une
permission Django accorde en réalité zéro droit, et conclut à tort que la vue est trop stricte.

v0.11.3

Corrigé

• Le garde-fou de publication PyPI ne voyait pas une variable d'environnement. Il était posé
  sur le job, dont la condition est évaluée avant le chargement de l'environnement pypi :
  une variable définie là y était donc invisible, et la tâche restait sautée sans qu'on
  comprenne pourquoi. Le garde-fou est descendu au niveau de l'étape, où la variable est lue
  qu'elle soit posée sur le dépôt ou sur l'environnement.
• La tâche dit désormais à voix haute pourquoi elle publie ou non, et quelle valeur elle a
  lue. Une étape sautée sans explication se lit comme une panne.

v0.11.2

Changé

• La description du paquet est désormais identique, au mot près, à celle du dépôt. Deux
  descriptions du même paquet finissent par diverger, et on ne sait plus laquelle fait foi. Le
  pare-feu applicatif, ajouté en 0.11.0, y figure enfin.
• La description affichée dans NetBox — autre public, autre formulation — était restée à
  l'état de la 0.1.0 : ni criticité, ni engagements de continuité, ni WAF.
• Mot-clé waf ajouté pour la recherche sur PyPI.

v0.11.1

Ajouté

• Procédure d'installation sans accès à un dépôt distant. Sur un réseau fermé, la
  construction habituelle échoue deux fois : apt-get ne joint pas les dépôts Debian et
  uv pip ne joint pas GitHub. On apporte désormais la roue déjà construite — possible sans
  contorsion parce que le plugin ne déclare aucune dépendance d'exécution.
• L'intégration continue conserve la roue en artefact (paquet, 90 jours). Sans cela, il
  fallait une machine disposant à la fois de Python et du réseau pour la reconstruire.
• Chaque tag produit désormais une release GitHub, avec les notes tirées du CHANGELOG et
  la roue attachée. Un artefact de CI expire et exige un compte ; une release est publique et
  durable — c'est elle qu'on emporte pour une installation hors ligne.
• La publication sur PyPI est câblée par trusted publishing : PyPI reconnaît le dépôt, le
  workflow et l'environnement, et délivre un jeton éphémère. Aucun secret n'est stocké. La
  tâche reste sautée tant que la variable PUBLIER_SUR_PYPI n'est pas posée.

Éprouvée, pas seulement écrite : image construite avec --network none, plugin chargé,
gabarits et migrations présents, manage.py check sans anomalie.