Roadmap
-
Version 1.4.2 stable livrée.
Dépot : https://www.bazzanella.org:888/com_asradius/svn/tags/LIV-1.4.2.0Tags : LIV-1.4.2.0
Framework : Joomla 1.0.15
Type : Composant logiciel pour Joomla.
Fonctionnalités requises des NAS:
Les NAS n'autorisent qu'une seul session connectée à la fois sur le réseau. Cela veut dire qu'un abonné ne peut pas se connecter sur le réseau plus d'une fois en même temps.Fonctionnalités :
Pour les opérateurs :
- Création de nouvelles demandes d'abonnement.
- Chaque opérateur ajoute et visualise ses propres demandes d'abonnement dont il a la charge.
Pour les gestionnaires et administrateurs :
- Approuver(statut approuvé) ou refuser(statut refusé), réinitialiser(statut en cours) l'ensemble des abonnés par un gestionnaire.
- Modifier, supprimer, les informations d'un abonné.
- L'identifiant et le mot de passe, le prénom et le nom ne sont plus modifiables après création de la demande d'abonnement sauf pour les autres informations tel que, email, adresse, ville, téléphone, etc.
- Configuration de l'adresse email de notification d'un gestionnaire quand un opérateur saisie une nouvelle demande d'abonnement.
- Mode date à date ou bien mode date et un nombre de jours donnés pour la saisie de la période d'abonnement.
- Autorisation ou non pour les opérateurs de saisir de nouvelles demandes d'abonnement.
Pour les superadministrateurs :
- Paramétrer les informations d'accès à la base de données de RADIUS.
- Passer en mode simulation ou non.
- En mode simulation ce composant est déconnecté de la base de données de RADIUS.
- Les changements de statut (En cours, refusé, approuvé) sont inopérants en mode simulation.
- Une resynchronisation de l'ensemble des abonnés est nécessaire lorsque du mode simulation on passe en mode production.
- Ceci préserve les contraintes d'intégrités entre la liste des abonnés de ce composant et la base de données de RADIUS.
- Egalement, les suppressions sont interdites en mode simulation. Il faut passer en mode production pour pouvoir supprimer un abonné.
- Choix du groupe Joomla des opérateurs autorisés à saisir de nouvelles demandes d'abonnement.
- Organisation 1 pour petites structures: En règle générale, on fixe ce groupe à Manager, juste le premier niveau de privilèges du backend. Ceci permet d'avoir une utilisation souple dans la manière d'organiser le site Intranet. Opérateurs et gestionnaires ne font qu'un. Les nouveaux identifiés (groupe Registered) ne peuvent pas faire des demandes d'abonnement. Un opérateur est également un gestionnaire.
- Organisation 2 pour grandes structures: En fixant ce groupe à Author et avec un opérateur quelconque appartenant à ce groupe et identifié sur l'Intranet; Celui-ci n'a plus accès au backend de l'Intranet. Les nouveaux identifiés (groupe Registered) ne peuvent pas faire des demandes d'abonnement. Les opérateurs sont seuls autorisés (à part les gestionnaires, administrateurs, et superviseurs) à faire des demandes d'abonnement et n'ont pas accès au backend. On sous-traite les demandes d'abonnement à des opérateurs et on gère les abonnés par des gestionnaires. Cela permet de partager la somme de travail et de cloisonner les responsabilités de chacun. On différencie les opérateurs des gestionnaires. Cette organisation est plus restrictive et n'est pas choisie par défaut sur les Intranets (Pour l'instant).
- Organisation 3 pour structures spéciales: En fixant à Registered et avec un utilisateur quelconque identifié sur l'Intranet; Celui-ci n'a pas accès au backend de l'Intranet. Les nouveaux identifiés (groupe Registered) peuvent donc faire des demandes d'abonnement. Cette organisation convient quand on veut que les utilisateurs identifiés sur l'Intranet fassent leur propres demandes d'abonnement. Chaque utilisateur peut effectuer plusieurs demandes d'abonnements. Les opérateurs sont n'importe quel utilisateur identifié sur l'Intranet. Cette organisation n'est pas choisie par défaut sur les Intranets (Pour l'instant).
Fonctionnalités supplémentaires ajoutées (Améliorations):
- Les utilisateurs connectés sont sur fond vert dans la liste du backend et du frontend avec l'information du nom du hotspot.
- Gestion efficace des sessions RADIUS (Temps réel sur refus pour un abonné).
- Le composant est multi-nas pour les requêtes d'accounting (Fonctionnalité Temps réel pour la déconnexion de ses sessions actives).
Choix du type de demande d'abonnement :
Pour les opérateurs (groupe défini dans la configuration avancée):
- 1 type d'abonnés par défaut :
- Type-Automatique : Le système génère le login et le mot de passe. Le champ MAC n'est pas demandé.
Les futurs nomades (paiement sécurisé) seront des opérateurs dans les versions futures.
Pour les gestionnaires (groupe Manager ou Administrator):
- 2 types d'abonnés :
- Type-Automatique : Le système génère le login et le mot de passe. Le champ MAC n'est pas demandé.
- Type-Manuel : le login et le mot de passe sont saisis manuellement. Le champ MAC est obligatoire.
Pour les superviseurs (groupe super Administrator):
- 3 types d'abonnés :
- Type-Automatique : Le système génère le login et le mot de passe. Le champ MAC n'est pas demandé.
- Type-Manuel : le login et le mot de passe sont saisis manuellement. Le champ MAC est obligatoire.
- Type-Superviseur : le login et le mot de passe sont saisis manuellement. Le champ MAC n'est pas demandé.
- Pour les superviseurs, possibilité de se rajouter de manière cachée dans la liste des abonnés. Le superviseur identifié sur le backend ne verra pas les identifiants des autres superviseurs mais saura que ceux ci sont présents dans le système d'abonnement du composant com_asradius. Un superviseur ne pourra se supprimer ou se refuser que si au moins 2 autres superviseurs sont présents et approuvés dans le système. Un superviseur ne peut changer aucun champ d'un autre superviseur. Un superviseur ne peut changer aucun statut d'abonnement d'un autre superviseur. Pour faire une demande d'abonnement de type Type-Superviseur il suffit simplement de s'identifié sur le frontend en super administrateur et d'effectuer une nouvelle demande d'abonnement pour soi-même. L'identifiant seul saisi manuellement lors de la demande doit correspondre exactement avec celui de Joomla. Le mot de passe peut-être différent de celui de Joomla. Un super-administrateur est réduit à une seule demande d'abonnement et ne peut pas faire de demande de type Type-Superviseur pour un autre super administrateur.
- Création de nouvelles demandes d'abonnement.
-
Version alpha en cours de développement, compatible avec les versions 1.4.x.x (Pour les mises à jour du composant).
Dépot : https://www.bazzanella.org:888/com_asradius/svn/trunkVersion béta livrée : https://www.bazzanella.org:888/com_asradius/svn/branches/BL-1.5.4.0
Fonctionnalités supplémentaires ajoutées :
- Activation/Désactivation de la vérification de la MAC en plus du login/password, pour les superadministrateurs.
- La MAC est automatiquement activé lors d'une nouvelle demande d'abonnement en mode manuel (Saisie du login/password).
- Nettoyage des informations d'accounting, pour les superadministrateurs.
Fonctionnalités supplémentaires en cours de développement :
- Renouvellement manuelle d'un ensemble d'abonnés.
- Activation/Désactivation de la vérification de la MAC en plus du login/password, pour les superadministrateurs.
-
Milestone: 2.0
No date set
Fonctionnalité envisagée :
- Renouvellement automatique via paiement sécurisé Paypal ou Crédit mutuel, au choix.
-
Milestone: 3.x
No date set
Fonctionnalités supplémentaires envisagées :
- Compatibilité du composant com_asradius avec Joomla 1.5.x
Note: See TracRoadmap for help on using the roadmap.
