Retour à la liste des fichiers d'aide
La gestion des utilisateurs est très importante pour définir qui peut faire quoi sur la base de données publiée grâce à ExpoActes. Le module de gestion des utilisateurs n'est accessible qu'à l'administrateur qui peut y effectuer les opérations suivantes :
La possibilité peut être ouverte aux visiteurs pour créer eux-même leur compte d'utilisateur avec vérification de la validité de l'adresse e-mail, protection anti-spam par captcha et approbation éventuelle par l'administrateur.
Un dispositif a également été ajouté permettant de gérer un "compte" de points pour chaque utilisateur enregistré. Ce compte, qui peut être réapprovisionné de manière automatisée, permet ainsi de limiter le nombre d'actes détaillés visionnés par un utilisateur au cours d'une période donnée.
Ces différentes possiblités sont activables grâce à plusieurs paramètres globaux "Utilisateurs".
Toutes les opérations sur les comptes des utilisateurs sont accessibles via l'item Administrer les utilisateurs du menu d'administration. Ces actions nécessitent le niveau d'accès 9.
A partir de la version 3.1, prenant en compte le fait que plusieurs associations utilisatrices du logiciel organisent les actes dans deux bases ou plus, il est apparu nécessaire de faciliter la gestion des comptes utilisateurs en centralisant la gestion de ceux-ci dans une seule des bases et de faire obéir les autres bases à la première base. La titre ci-dessous Centraliser la gestion des utilisateurs pour plusieurs bases donne la procédure à employer et les contraintes de cette solution.
* A partir de la version 3.2, les anciens niveaux 5 et 6 ont été fusionnés en 6, libérant ainsi le niveau 5 pour les accès privilégiés sans limitation par adresse IP.
Le paramètre général (PUBLIC_LEVEL) permet d'ouvrir l'accès public jusqu'à un niveau déterminé à partir duquel la fenêtre de login apparaît. Par défaut, il est réglé au niveau 4 qui laisse l'accès libre en consultation des tables et des actes mais les protège de toute modification.
Dans une fiche d'utilisateur, le nom et prénom de la personnes sont évidemment obligatoires. Le code de login compte au minimum 3 caractères tandis que le mot de passe doit en compter au moins 6. Le symbole apostrophe est cependant interdit.
Le compte doit aussi préciser une adresse email valide et, en principe, unique. Cette unicité peut en effet être un problème lorsque plusieurs utilisateurs partagent une même adresse mail. Un paramètre a donc été ajouté pour lever cette contrainte là ou c'est nécessaire.
Mot de passe automatique : Si cette case est cochée, ExpoActes génère un mot de passe aléatoire comprenant des lettres et des chiffres. Sauf configuration contraire (voir paramètre CHANGE_PW), l'utilisateur pourra changer lui-même ce mot de passe par un code plus facile à mémoriser pour lui.
Chaque compte précise le niveau d'accès de l'utilisateur ainsi que le statut du compte. Pour qu'un compte soit opérationnel, le statut doit être "N" (Normal), valeur par défaut lors de la création individuelle du compte ou de la création par importation d'une liste. Il est aussi possible d'interdir l'accès du site à un compte en basculant le statut sur "B" pour Bloqué. Les deux autres statuts possibles ne sont utiles que lors de l'auto-enregistrement des utilisateurs.
Enfin, à partir de la version 3, un compte est aussi associé à une date d'échance. Cela veut dire que lorsque cette date est dépassée, le compte est bloqué et l'utilisateur ne peut se connecter. Il est par contre possible à l'adminsitrateur de préciser une nouvelle date d'échéance. Par défaut, la date d'échance des comptes est fixée à la fin de l'année 2033 ce qui équivaut à dire que ces comptes sont illimités dans le temps. Un paramètre permet de spécifier une autre date par défaut ou un délai qui est alors compté à partir du jour de création du compte.
Notons aussi qu'à partir de la version 3, les mots de passe ne sont plus stockés que sous forme "hashée" dans la base de données. Cela signifie que cette valeur codée sur 40 caractères (quel que soit la longueur du mot de passe original) permet de VERIFIER que le mot de passe introduit pas l'utilisateur est valide mais ne permet pas de RECONSTITUER le mot de passe et donc il est devenu impossible de renvoyer le mot de passe oublié à un utilisateur. A la place, le système génère un nouveau mot de passe et l'envoie à l'utilisateur qui peut éventuellement le modifier à sà guise. Cette façon de faire permet de protéger les mots de passe de tous les utilisateurs contre toute utilisation malveillante et augmente donc le niveau de sécurisation du logiciel.
Colonne | Contenu | Remarque |
---|---|---|
1 A | Nom de l'utilisateur | Obligatoire |
2 B | Prénom | Obligatoire |
3 C | Adresse e-mail | Obligatoire |
4 D | Login demandé | "auto" si création automatique |
5 E | Mot de passe proposé | "auto" si création automatique |
6 F | Niveau d'accès | 1 à 8, voir ci-dessus |
7 G | Régime | 0 à 2 (si gestion des points) |
8 H | Solde initial de points | |
9 I | Commentaire | Commentaire facultatif |
10 J | Date d'expiration | |
11 K | Libre | Information libre |
12 L | Identifiant | (uniquement pour backup/restauration) |
13 M | Statut du compte | N=Normal / B=Bloqué |
14 N | Date d'inscription | Automatique sauf si restauration |
15 O | Points consommés | (en principe 0 si import) |
16 P | Date de recharge | Automatique sauf si restauration |
Exemples :
"Lambert";"Pascale";"lambertp@free.net";"pascale";"auto";6;1;120;"2006"
Martin;Jean;mjean@gmail.com
Si la zone 4 (login) est vide ou marquée "auto", le logiciel génère un login automatiquement en prenant les 3 premiers caractères du prénom suivi des 3 premiers du nom puis, si nécessaire, d'un code en deux chiffres lorsque le login est déjà utilisé (exemple avec le 2ème cas ci-dessus : "jeamar" puis si nécessaire "jeamar01", "jeamar02", ...)
Si la zone 5 (mot de passe) est vide ou marquée "auto", le logiciel génère un mot de passe aléatoire composé de lettres et de chiffres. Notons que chaque utilisateur peut changer son mot de passe après s'être connecté au moins une fois avec le mot de passe qui lui a été attribué.
Si les zones 6 et 7 (niveau d'accès et régime de gestion des points) n'ont pas été spécifiées, alors le système attribue le niveau et le régime par défaut qui auront été spécifié dans le formulaire de chargement.
La zone 8 (solde initial) permet d'affecter un nombre de point de départ. Cette option n'est utile que pour l'affectation manuelle des points (régime = 1).
Les zones 10 et 11 sont nouvelles à la version 3. Elles sont facultatives.
La zone 12 (Identifiant) permet de forcer un n° identifiant. C'est particulièrement important lors de l'usage de l'importation pour restaurer des données sauvegardées. Idem pour les zones 13 à 16 qui permettent de restaurer des données. Ces zones 12 à 16 ne doivent pas être complétées lors des imports de nouveaux utilisateurs.
En complément à l'importation, il peut être utile, surtout pour les associations, de supprimer un lot de comptes utilisteurs ou de les exporter pour mettre à jour les données via un outil externe (Excel, Access,...).
Par précaution, il n'est pas possible de supprimer un lot de comptes sans exporter les valeurs qui seront supprimées. Il est ainsi toujours possible de réimporter ces comptes par la suite.
La procédure impose de préciser le niveau d'accès des comptes à supprimer. Par sécurité, il n'est toutefois pas possible de supprimer les comptes des administrateurs. Il est aussi possible de compléter la sélection en précisant le "régime" lorsque la gestion de points est activées. Enfin, il est aussi possible de spécifier un morceau de texte qui sera recherché dans le commentaire associé aux utilisateurs. Il est aussi possible de sélectionner un statut particulier. c'est utilenotamment pour supprimer des comptes qui ont expirés depuis un nombre de jours fixé dans le paramètre DUREE_EXPIR. Cela évite de laisser subsister des comptes dormants et de toute façon inutilisables. Le paramètre peut être modifié dans la section "Uitlisateurs" des paramètres.
Pour réaliser un backup de l'ensemble des comptes utilisateurs, il suffit de sélectionner "*** Tous >>> Backup ***" dans la zone niveau.
Cette fonction permet d'envoyer un courrier à tout ou partie des utilisateurs.
Elle dépend cependant des possibilités d'envoi offertes par l'hébergeur. En effet, certains hébergeurs limitent le nombre de mails pouvant être expédiés par unité de temps et dans ce cas, il est fort possible qu'une partie des utilisateurs ne reçoivent jamais la mail envoyé.
Avant l'envoi, il faut préciser un niveau d'accès (ou A = Tous) et éventuellement le régime de gestion de points et/ou une condition sur le commentaire associé à l'utilisateur. Ceci permet par exemple de noter des codes dans le commentaire et de s'en servir pour sélectionner les destinataires.
Pour l'envoi du mail, il suffit de compléter le sujet et le texte, puis d'envoyer.
Quelques modifications sur les comptes des utilisateurs sont succeptibles de devoir être faite sur des groupes important de comptes. Il s'agit notamment de l'affectation d'une nouvelle date d'expiration ou l'ajout de points aux soldes des comptes.
Comme pour l'envoi des mails circulaires, il faut préciser un niveau d'accès et éventuellement le régime de gestion de points et/ou une condition sur le commentaire associé à l'utilisateur. Ceci permet par exemple de noter des codes dans le commentaire et de s'en servir pour sélectionner les destinataires. On peut aussi ajouter une condition sur la date actuelle d'expiration du compte.
Pour la gestion des dates d'expiration, il faut préciser la nouvelle date qui sera affectée. Pour la gestion des soldes, on a le choix entre "ajouter" un nombre de points à tous les utilisateurs concernés ou d'affecter d'office un nombre de point quelque soit le solde précédent.
Précaution importante : Avant toute modification groupée, il est prudent de réaliser un export backup des comptes utilisateurs. De cette façon, en cas d'erreur, il sera possible de supprimer puis de restaurer les comptes incorrectement modifiés.
Dans les associations, il arrive souvent que le chargement des actes soit effectué par un seul administrateur bien que les dépouillements soient assurés par de nombreuses personnes. Pour garder trace des dépouillements effectués par les différents membres, il est possible - pour les administrateurs seulement - de désigner le déposant "titulaire" bien que le travail soit effectivement réalisé par l'administrateur.
A cette fin, les administrateurs (ayant le niveau 8 ou 9) trouvent une boîte de sélection supplémentaire dans les écrans de chargement des actes CSV ou NIMEGUES. Cette boîte de sélection propose la liste des utilisateurs ayant un niveau d'accès spécifié par le paramètre DEPOSANT_LEVEL ou supérieur. Il suffit d'y sélectionner le nom de la personne ayant effectivement réalisé le dépouillement.
De cette façon, cette personne aura aussi le possibilité de corriger les actes qu'elle a (ou est sensée avoir) déposé et ceux-là seulement.
Si pour une raison quelconque, on souhaite répartir les actes dans deux bases ou plus (avec donc des adresses web distinctes), il est possible de faciliter la gestion des comptes utilisateurs en centralisant la gestion de ceux-ci dans une seule des bases (dite base Principale) et de faire obéir les autres bases (bases secondaires) à la base principale. En fait, il n'existe plus qu'une seule table d'utilisateurs (active*) pour toutes les bases.
Cette disposition a les conséquences suivantes :
En pratique, sur la base principale on ne note aucun changement et il est même impossible de savoir que cette base fournit le service d'authentification à d'autres bases. Si l'on souhaite faire un backup des utilisateurs ou toute autre manipulation importante (suppression de plusieurs comptes, export, modification groupée, c'est sur cette base qu'il faut le faire car ces fonctions ne sont pas accessibles dans les bases secondaires.
Dans chacune des bases secondaire, il faut ajouter au fichier connect.inc.php les codes d'accès vers la base principale afin que celle-ci soit consultée en lieu et place de la table des utilisateurs de la base courante. Pour ce faire il faut ajouter les variables suivantes (toujours) et éventuellement la définition de la constante EA_DBU :
$udbaddr = "wwwwwww"; // Adresse du serveur pour la base des utilisateurs
$udbname = "xxxxxxx"; // Nom de la base
$udbuser = "yyyyyyy"; // Login MySQL-EasyPHP
$udbpass = "zzzzzzz"; // Mot de passe
define("EA_UDB","act"); //préfixe des tables
Il convient bien évidemment de remplacer les valeurs par les codes d'accès fournis par l'hébergeur. En pratique, il suffit de copier les valeurs déjà présentes dans la base principale : faire un copier coller du bloc puis ajouter un "u" juste après le $ dans le nom des 4 variables.
Dans le cas où il n'existe qu'une seule base MySQL et que les deux "bases" sont distinguées via un préfixe, il faut malgré tout spécifier ces 4 variables mais en plus, il faut préciser le préfixe des tables de la base principale.
Il est judicieux de régler les paramètres "Utilisateurs" des bases secondaires de façon identique ou en tous cas compatible avec les paramètres de la base principale. Un rappel est affiché en tête de ces paramètres pour inviter à la prudence dans la gestion de ces valeurs. De même, la gestion des utilisateurs est limitée dans les bases secondaires au listage des utilisateur et à la modification individuelle des fiches.
(*) En pratique, la tables des utilisateurs des bases secondaire n'est jamais supprimée mais elle n'est pas consultée. Il ne faut cependant pas la supprimer car elle est utilisée lors des mise à jour du logiciel et peut facilement être réactivée en cas de besoin.