Evolution #185
Séparer VPN et ADSL
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 | |||
| model-offers.svg (8.84 KB) model-offers.svg | |||
| model-offers.png (59.9 KB) model-offers.png |
Updated by Baptiste Jonglez over 9 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.
Updated by Fabien Michel over 9 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
Updated by Baptiste Jonglez over 9 years ago
- File model-offers.dia model-offers.dia added
- File model-offers.svg model-offers.svg added
- File model-offers.png model-offers.png added
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 ?)
Updated by Baptiste Jonglez over 9 years ago
- Status changed from Nouveau to Fermé
Implémenté. Il reste à factoriser du code commun entre les technologies (VPN, ADSL, etc)
Updated by Baptiste Jonglez over 9 years ago
- % Done changed from 0 to 90
Updated by Baptiste Jonglez about 9 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`.
Updated by Baptiste Jonglez almost 9 years ago
- Status changed from En cours to Fermé
- % Done changed from 90 to 100
Passage à Django-polymorphic.