Project

General

Profile

Evolution #185

Séparer VPN et ADSL

Added by Baptiste Jonglez over 7 years ago. Updated about 7 years ago.

Status:
Fermé
Priority:
Normal
Assignee:
-
Target version:
Start date:
04/08/2014
Due date:
% Done:

100%

Estimated time:
Spent time:

Description

On semble parti sur une séparation assez claire du VPN et de l'ADSL dans le backend LDAP (différents attributs, différentes possibilités, stockage des mots de passe en clair ou pas, etc).

Notamment, certaines choses sont possibles pour le VPN et pas pour l'ADSL : choisir les IP endpoint (cf. #184).

Il faut donc voir, dans la partie qui gère les offres, quels morceaux sont à spécialiser (écriture dans le backend LDAP, ...) et quels morceaux sont à garder générique (dates de début et de fin, mensualité, etc).


Files

model-offers.dia (2.54 KB) model-offers.dia Baptiste Jonglez, 05/08/2014 02:28 AM
model-offers.svg (8.84 KB) model-offers.svg Baptiste Jonglez, 05/08/2014 02:28 AM
model-offers.png (59.9 KB) model-offers.png Baptiste Jonglez, 05/08/2014 02:28 AM
#1

Updated by Baptiste Jonglez over 7 years ago

Plus spécifiquement, la distinction entre ADSL et VPN se fait actuellement dans les données (classe "Service" dans "coin/offers/models.py") et non dans le code.

Il me semble nécessaire d'introduire la distinction dans le code lui-même : les informations associées à un abonnement ADSL et VPN sont différentes, et le format du backend est différent. C'est un peu dommage, parce que ça fait du code spécifique pour chaque type d'abonnement, mais ça me paraît nécessaire.

#2

Updated by Fabien Michel over 7 years ago

En effet, la classe service ne sert plus à grand chose depuis que les pages IP n'y sont plus rattachées. Mais elle n'a jamais été destinée à stocker les données spécifiques aux différents types de services.

Pour les abonnements aux services on peut spécifier de deux manières:
- Soit en faisant un héritage (VPNSubscription hérite de Offersubscriptions par exemple) : https://docs.djangoproject.com/en/dev/topics/db/models/#model-inheritance
- Soit un indiquant un champ OneToOne dans VPNSubscription vers l'abonnement associé. : https://docs.djangoproject.com/en/dev/topics/db/examples/one_to_one/

Django gère les héritages, par contre il créé autant de tables que de classe hérités contenant chacune toutes les colonnes "communes" de la classe parente.
Il faudra peut-être passé Offersubscription en class abstraite, mais je ne suis pas sûr.

Comme ça je ne sais pas laquelle des deux méthode serai la plus appropriée

#3

Updated by Baptiste Jonglez over 7 years ago

Voici une proposition de modèles (voir schéma attaché).

Notes sur le schéma :

  • on sépare clairement tout ce qui est administratif (rien dans le LDAP) de ce qui est technique et spécifique à chaque techno (en partie poussé dans le LDAP). Je pense que c'est indispensable (d'ailleurs, la spec SI sur le wiki FFDN insiste là-dessus)
  • les IPSubnet sont liés à l'abonnement administratif et non à l'abonnement techno-spécifique (pas de généricité possible en Django). Cependant, ce n'est pas super : la façon d'insérer un IPSubnet dans le LDAP change selon la techno. Il faut faire attention à bien garder le LDAP à jour quand on change/ajoute/supprime un IPSubnet.
  • suppression d'un abonnement (administratif) : suppression aussi de l'abonnement techno-spécifique, des IPSubnet, et des enregistrements DNS inverse associés aux IPSubnet.
  • le champ "type" d'une offre est indicative, mais on peut aussi s'en servir pour vérifier que l'abonnement techno-spécifique (par exemple VPNSubscription) est bien associé au bon type d'offre.

Il y a possibilité de créer une classe UpstreamProvider pour les fournisseurs de collecte de différentes technos (mais a-t-on vraiment des informations spécifiques à stocker pour chaque fournisseur ?)

#4

Updated by Baptiste Jonglez over 7 years ago

  • Status changed from Nouveau to Fermé

Implémenté. Il reste à factoriser du code commun entre les technologies (VPN, ADSL, etc)

#5

Updated by Baptiste Jonglez over 7 years ago

  • Target version set to 0.1
#6

Updated by Baptiste Jonglez over 7 years ago

  • % Done changed from 0 to 90
#7

Updated by Baptiste Jonglez over 7 years ago

  • Status changed from Fermé to En cours

Nouveau problème de généricité : dans les templates, c'est difficile de mettre des URL qui pointent vers une page de configuration spécifique à une technologie. Par exemple, dans la liste des abonnements, on peut avoir des abonnements de plusieurs type (ADSL, VPN, etc), mais on aimerait quand même avoir un lien qui pointe sur la bonne page de configuration pour une technologie donnée.

J'ai implémenté ça avec une redirection (cf. ConfigurationRedirectView dans `offers/views.py`).

Basiquement, quand on demande l'URL `/subscription/configuration/42`, ça va prendre l'abonnement n°42, regarder quel backend de configuration est utilisé, et rediriger vers une URL du type `/vpn/18`.

#8

Updated by Baptiste Jonglez about 7 years ago

  • Status changed from En cours to Fermé
  • % Done changed from 90 to 100

Passage à Django-polymorphic.

Also available in: Atom PDF