Système de Gestion des Cartes : Différence entre versions
(→Changement de code unité) |
(→Personne non trouvée dans unicampus) |
||
| (31 révisions intermédiaires par 2 utilisateurs non affichées) | |||
| Ligne 32 : | Ligne 32 : | ||
==== Changement de code unité ==== | ==== Changement de code unité ==== | ||
| − | Lors d'une re-codification d' | + | Lors d'une re-codification d'un code unité, on peut faire un traitement en masse pour que les cartes d'accès restent valides. |
Pour cela, il faut vérifier dans la base de données Reseda sur le serveur NewMysql que les champs sigleUnite et sigleUnite de la unites_fixes sont bien renseignés. | Pour cela, il faut vérifier dans la base de données Reseda sur le serveur NewMysql que les champs sigleUnite et sigleUnite de la unites_fixes sont bien renseignés. | ||
| − | + | * lancer la commande requête sql sur le serveur sécurité (via phpmyadmin), là où se trouve la table personnel qui contient les cartes, cela mettra à jour les informations de la carte actives. | |
| − | UPDATE ` | + | UPDATE `personnel` p1 |
| − | JOIN ` | + | JOIN `personnel` p2 ON p1.`idResedaPersonne`= p2.`idResedaPersonne` |
| − | SET p1.`etatPersonnel`=p2.`etatPersonnel`, p1.`presenceUnite`= p2.`presenceUnite`, p1.`codeUnite`=p2.`codeUnite`, p1.`fonction_libelle`=p2.`fonction_libelle`, | + | SET p1.`etatPersonnel`=p2.`etatPersonnel`, p1.`presenceUnite`= p2.`presenceUnite`, p1.`codeUnite`=p2.`codeUnite`, p1.`fonction_libelle`=p2.`fonction_libelle`, p1.`fonction_code`=p2.`fonction_code`, p1.`dateFinImplantation`=p2.`dateFinImplantation` |
| − | + | WHERE p1.`codeUnite`='UPS3035' AND p2.`codeUnite`='UAR3035' AND p2.`UUIDPersonne` IS NULL AND p1.`UUIDPersonne` IS NOT NULL | |
| − | WHERE p1.`codeUnite`=' | + | |
| + | p1.`codeUnite`='AncienCode' | ||
| + | p2.`codeUnite`='NouveauCode' | ||
| + | |||
| + | * Il faut ensuite supprimer les doublons par la requête : | ||
| + | DELETE t1 | ||
| + | FROM `personnel` AS t1, `personnel` AS t2 | ||
| + | WHERE t1.id > t2.id | ||
| + | AND t1.`idResedaPersonne` = t2.`idResedaPersonne` | ||
| + | AND t1.`codeUnite` = t2.`codeUnite` | ||
| + | AND t1.`codeUnite` = 'UAR3035' | ||
| + | AND t1.`categorie_code` != 'CARTE_V' | ||
| + | |||
| + | t1.`codeUnite`='NouveauCode' | ||
| + | la requête supprime le doublon qui a l'id le plus élévé. | ||
| + | |||
| + | * Si l'unité a des cartes de catégorie CARTE_V, il faut lancer la requête suivante : | ||
| + | UPDATE `personnel` SET `codeUnite`='UAR3725' WHERE `codeUnite`='UMS3725' AND `categorie_code`= 'CARTE_V' | ||
| + | |||
| + | UAR3725 -> nouveau Code | ||
| + | UMR3725 -> ancien code | ||
==== Changement de site pour une unité ==== | ==== Changement de site pour une unité ==== | ||
| Ligne 50 : | Ligne 70 : | ||
table site de la base Campus, ex: site=1 pour le site RDM. Si la colonne uniteFixe n'est pas renseignée, mettre le codeUnite de l'unité. | table site de la base Campus, ex: site=1 pour le site RDM. Si la colonne uniteFixe n'est pas renseignée, mettre le codeUnite de l'unité. | ||
* dans la table unite_fixes, changer le champ siteUnite par le sigle du site, ex: siteUnite=RDM . | * dans la table unite_fixes, changer le champ siteUnite par le sigle du site, ex: siteUnite=RDM . | ||
| + | |||
| + | |||
| + | === Résolutions problèmes === | ||
| + | |||
| + | ==== Personne non trouvée dans unicampus ==== | ||
| + | |||
| + | Unicampus s'appuie sur les données de la table Personnel. Si la personne n'est pas trouvée dans unicampus, il faut d'abord vérifier qu'elle est bien dans la table Personnel du serveur secu-cab. | ||
| + | * elle est présente, il faut alors vérifier la communication entre le serveur sécu et unicampus | ||
| + | * elle n'est pas présente, il faut alors vérifier les données de Reseda sur le serveur newMysql de la délégation. | ||
| + | |||
| + | Sur la base de données Reseda : | ||
| + | * vérifier les données de la personne et ses implantations. Si la personne a un statut CCD ou autre à durée déterminée, il faut que la date de fin soit renseignée, sinon l'info sera filtrée par les scripts et ne passera pas dans la table Personnel du serveur Secu-CAB. | ||
| + | * Il arrive que pour certaines populations l’information passe mal entre Sirhus et reseda. IL faut alors aller voir le RH pour faire corriger la donnée. | ||
| + | |||
| + | ==== Problème d'accès à HNO ==== | ||
| + | |||
| + | Pour avoir accès à l'interface HNO sur DUO, il faut avoir une carteCMS valide. | ||
| + | |||
| + | Il se peut qu'une personne possède deux entrées dans la base de données Reseda dont une à une date de suppression logique (suite à du nettoyage DSI). | ||
| + | |||
| + | Cela se traduit par deux entrées dans la table Personnel sur le serveur Secu-CAB-DB. En général l'entrée qui renseigne le numéro de la carte correspond à l'idResedaPersonne de l'enregistrement possédant la date de suppression. | ||
| + | |||
| + | Avant d'engager toute modification, vérifier que la personne est toujours dans l'unité à laquelle correspond la carteCMS. Pour cela : | ||
| + | |||
| + | * Aller sur la base de données reseda sur NewMySql (si possible par un phpmyadmin). | ||
| + | * Vérifier les deux entrées dans la table "personnes" (repérer l'idReseda valide et celui qui possède la date de suppression logique) | ||
| + | * Comparer les idResedaPersonne avec ceux de la table "personnel", on doit retrouver les deux idResedaPersonne. | ||
| + | * Vérifier les implantations de la personne à l'aide de la requête req_personnes_implantations. | ||
| + | * Repérer l'unité, l'idResedaPersonne de l’enregistrement dont la date de fin est NULL ou supérieure à la date du jour, avec une présence unité à 1. | ||
| + | * S'il y a correspondance au niveau des idResedaPersonne sur la table "personnel" du serveur Sécu et "personnes" de reseda et que la personne est toujours dans la même unité, alors il faut modifier l'enregistrement dans la personnel qui possède la carteCMS. | ||
| + | * Sur l'enregistrement de la table "personnel" dont la carteCMS est renseignée, remplacer l'idResedaPersonne, mettre etatPersonnel à present, presenceUnite à 1, et remplacer la dateFinImplantation. | ||
| + | * Supprimer l’enregistrement doublon de la table "personnel" qui ne possède pas de carte. | ||
| + | * Aller ensuite sur l'interface "cartes multi-services" de DUO, dans l'onglet "carte Personnels", cliquer sur la petite fiche à gauche de la civilité du nom, cela aurait pour effet d'activer le webservice vers unicampus afin d'actualiser le statut de la carte. | ||
=== Contacts === | === Contacts === | ||
| − | |||
| Ligne 153 : | Ligne 205 : | ||
sur secu-CAB-DB (10.13.102.8) : | sur secu-CAB-DB (10.13.102.8) : | ||
| − | 00 6 * * 0-6 / | + | 00 6 * * 0-6 /opt/scripts/scriptResedaCarte.sh >> /opt/scripts/logCarte |
| − | 20 13 * * 1-5 / | + | 20 13 * * 1-5 /opt/scripts/scriptResedaCarte.sh >> /opt/scripts/logCarteMidi |
| + | * le script appelle une commande symfony dont les sources sont dans le répertoire /opt/scripts/carteSecu (On met à jour le code grâce à un dépôt git venant de gitLab). | ||
| + | * la commande s'appelle cartecms:importReseda2Carte . | ||
| + | * Ce script permet de copier les infos utiles de la base de données Reseda qui se trouve sur le serveur 10.13.102.9 et va importer les données dans la table carteCMS.Personnel du serveur secu-CAB-DB. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Le SGC utilise la base carteCMS comme sources de données | Le SGC utilise la base carteCMS comme sources de données | ||
| − | + | // a supprimer | |
Il existe aussi le script /etc/scripts/importReseda2Carte_manuel.php qui permet d'importer une catégorie de personnel. Il faut éditer le fichier et commenter et décommenter ce que l'on veut. | Il existe aussi le script /etc/scripts/importReseda2Carte_manuel.php qui permet d'importer une catégorie de personnel. Il faut éditer le fichier et commenter et décommenter ce que l'on veut. | ||
| − | ==== | + | ==== Génération cartes pour gardien ==== |
| − | + | C'est l'application carte Multiservice de Duo qui va créer les enregistrements pour la base carteCMS | |
| − | https://duo.dr13.cnrs.fr/cartecms/index | + | |
| − | + | * https://duo.dr13.cnrs.fr/cartecms/index | |
| − | + | * -> menu administration -> générer... | |
| − | L'application va aller enregistrer directement les infos dans la base carteCMS avec comme tag | + | * cela permet de générer un lot de carte, il faut avoir des droits spécifiques pour accéder à ce menu, généralement réservé au SSI. |
| + | * L'application va aller enregistrer directement les infos dans la base carteCMS avec comme tag | ||
provenanceDonneesIndividuelles = LOCAL | provenanceDonneesIndividuelles = LOCAL | ||
| Ligne 257 : | Ligne 305 : | ||
Pas encore en service ! | Pas encore en service ! | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Version actuelle datée du 5 mars 2024 à 16:14
Divers[modifier]
Administration local des cartes visiteurs[modifier]
https://duo.dr13.cnrs.fr/cartecms/index
Les PC d’édition doivent être sur le réseau src-cab-gestion
Nouvelle unité Reseda[modifier]
Lorsqu'une nouvelle unité Reseda est créée, le script quotidien Reseda va la créer dans la table reseda.unites, reseda.implantations_unites et la table unites_fixes. Il faut renseigner le champ site dans la table reseda.implantations_unites (mettre l'id du site qui se trouve dans la table campus.site), vérifier que le champ uniteFixe contient bien le même id que le champ idResedaUnite. Et dans la table reseda.unites_fixes mettre le codeSite de la table campus.site dans le champ siteUnite
Ajout unité spécifique[modifier]
Il se peut que le STL demande de rajouter un sigle unité, souvent parce qu'une nouvelle société doit entrer sur le campus. Et on veut leur donner un badge.
* Faire préciser pour quel campus si ce n'est pas fait. * Aller sur la base de données reseda sur le serveur MySQL de la délégation, actuellement IP 10.13.102.9 * Sur la table unites_fixes, rechercher les unités dont l'idResedaUnite commence par 999999% (on doit avoir la liste des unités fictives que l'on a créé pour la gestion des cartes) * SELECT * FROM `unites_fixes` WHERE `idResedaUnite` LIKE '999999%' * Rajouter l'unité en décrémentant de 1 l'idResedaUnite du plus petit. * Champ à renseigner : idResedaUnite, codeUnite (pas d'espace), intituleUnite, sigleUnite, siteUnite (ADV/RDM/BAILLARGUET) delegationRegionale_code = 13, date_insert = date du jour
Changement de code unité[modifier]
Lors d'une re-codification d'un code unité, on peut faire un traitement en masse pour que les cartes d'accès restent valides. Pour cela, il faut vérifier dans la base de données Reseda sur le serveur NewMysql que les champs sigleUnite et sigleUnite de la unites_fixes sont bien renseignés.
* lancer la commande requête sql sur le serveur sécurité (via phpmyadmin), là où se trouve la table personnel qui contient les cartes, cela mettra à jour les informations de la carte actives. UPDATE `personnel` p1 JOIN `personnel` p2 ON p1.`idResedaPersonne`= p2.`idResedaPersonne` SET p1.`etatPersonnel`=p2.`etatPersonnel`, p1.`presenceUnite`= p2.`presenceUnite`, p1.`codeUnite`=p2.`codeUnite`, p1.`fonction_libelle`=p2.`fonction_libelle`, p1.`fonction_code`=p2.`fonction_code`, p1.`dateFinImplantation`=p2.`dateFinImplantation` WHERE p1.`codeUnite`='UPS3035' AND p2.`codeUnite`='UAR3035' AND p2.`UUIDPersonne` IS NULL AND p1.`UUIDPersonne` IS NOT NULL
p1.`codeUnite`='AncienCode' p2.`codeUnite`='NouveauCode'
* Il faut ensuite supprimer les doublons par la requête : DELETE t1 FROM `personnel` AS t1, `personnel` AS t2 WHERE t1.id > t2.id AND t1.`idResedaPersonne` = t2.`idResedaPersonne` AND t1.`codeUnite` = t2.`codeUnite` AND t1.`codeUnite` = 'UAR3035' AND t1.`categorie_code` != 'CARTE_V'
t1.`codeUnite`='NouveauCode' la requête supprime le doublon qui a l'id le plus élévé.
* Si l'unité a des cartes de catégorie CARTE_V, il faut lancer la requête suivante : UPDATE `personnel` SET `codeUnite`='UAR3725' WHERE `codeUnite`='UMS3725' AND `categorie_code`= 'CARTE_V'
UAR3725 -> nouveau Code UMR3725 -> ancien code
Changement de site pour une unité[modifier]
Lorsqu'une unité change de site (typiquement unité Balard), il faut changer l'affectation de site dans la base de données Reseda (serveur Mysql)
* dans la table Reseda implantations_unites, changer le champ site par l'id du site qui se trouve dans la table site de la base Campus, ex: site=1 pour le site RDM. Si la colonne uniteFixe n'est pas renseignée, mettre le codeUnite de l'unité. * dans la table unite_fixes, changer le champ siteUnite par le sigle du site, ex: siteUnite=RDM .
Résolutions problèmes[modifier]
Personne non trouvée dans unicampus[modifier]
Unicampus s'appuie sur les données de la table Personnel. Si la personne n'est pas trouvée dans unicampus, il faut d'abord vérifier qu'elle est bien dans la table Personnel du serveur secu-cab.
* elle est présente, il faut alors vérifier la communication entre le serveur sécu et unicampus * elle n'est pas présente, il faut alors vérifier les données de Reseda sur le serveur newMysql de la délégation.
Sur la base de données Reseda :
* vérifier les données de la personne et ses implantations. Si la personne a un statut CCD ou autre à durée déterminée, il faut que la date de fin soit renseignée, sinon l'info sera filtrée par les scripts et ne passera pas dans la table Personnel du serveur Secu-CAB. * Il arrive que pour certaines populations l’information passe mal entre Sirhus et reseda. IL faut alors aller voir le RH pour faire corriger la donnée.
Problème d'accès à HNO[modifier]
Pour avoir accès à l'interface HNO sur DUO, il faut avoir une carteCMS valide.
Il se peut qu'une personne possède deux entrées dans la base de données Reseda dont une à une date de suppression logique (suite à du nettoyage DSI).
Cela se traduit par deux entrées dans la table Personnel sur le serveur Secu-CAB-DB. En général l'entrée qui renseigne le numéro de la carte correspond à l'idResedaPersonne de l'enregistrement possédant la date de suppression.
Avant d'engager toute modification, vérifier que la personne est toujours dans l'unité à laquelle correspond la carteCMS. Pour cela :
- Aller sur la base de données reseda sur NewMySql (si possible par un phpmyadmin).
- Vérifier les deux entrées dans la table "personnes" (repérer l'idReseda valide et celui qui possède la date de suppression logique)
- Comparer les idResedaPersonne avec ceux de la table "personnel", on doit retrouver les deux idResedaPersonne.
- Vérifier les implantations de la personne à l'aide de la requête req_personnes_implantations.
- Repérer l'unité, l'idResedaPersonne de l’enregistrement dont la date de fin est NULL ou supérieure à la date du jour, avec une présence unité à 1.
- S'il y a correspondance au niveau des idResedaPersonne sur la table "personnel" du serveur Sécu et "personnes" de reseda et que la personne est toujours dans la même unité, alors il faut modifier l'enregistrement dans la personnel qui possède la carteCMS.
- Sur l'enregistrement de la table "personnel" dont la carteCMS est renseignée, remplacer l'idResedaPersonne, mettre etatPersonnel à present, presenceUnite à 1, et remplacer la dateFinImplantation.
- Supprimer l’enregistrement doublon de la table "personnel" qui ne possède pas de carte.
- Aller ensuite sur l'interface "cartes multi-services" de DUO, dans l'onglet "carte Personnels", cliquer sur la petite fiche à gauche de la civilité du nom, cela aurait pour effet d'activer le webservice vers unicampus afin d'actualiser le statut de la carte.
Contacts[modifier]
HOTLINE : 02.47.92.90.32
et demander l’ouverture d’un incident « Monécarte ».
Gestionnaire de tickets :
Log : 34032 Mot de passe : XY1JO3
Technicien SAV, passer par les tickets, uniquement en cas de problèmes :
Clément Wigy Technicien Support 4 avenue Jean Monnet - 37160 Descartes Tel: +33 (0)2 47 92 90 32 clement.wigy@capmonetique.com - www.capmonetique.com
Installateur : CAP MONETIQUE
Technicien : Sébastien Arnault Chargé de projet 4 avenue Jean Monnet - 37160 Descartes Tel: +33 (0)2 47 91 85 87 - Mob : +33 6 (0)11 29 97 68 sebastien.arnault@capmonetique.com - www.capmonetique.com
Commercial : Sylvain Févrilliez Responsable secteur Grand Est – Enseignement Supérieur 4 avenue Jean Monnet - 37160 Descartes Tel: (+33) 2 47 91 47 50 - Mob : (+33) 6 99 06 48 43 sylvain.fevrilliez@capmonetique.com - www.capmonetique.com
Consommables :
A utiliser de préférence :
Sylvie Méreau <sylvie.mereau@capmonetique.com>
Ruban Primacy YMCKO, 5 panneaux. Kit de nettoyage Primacy
Urgence rubans livré le lendemain mais il vaut mieux passer par monecarte si pas urgent :
http://www.cardalis.fr/evolis-primacy-simplex-et-primacy-duplex/1561-ruban-evolis-primacy-couleur-ymcko-300-cartes.html
Protèges cartes :
http://www.cardalis.fr/porte-badges-souples/1444-porte-badge-souple-transparent-bandeau-transp-double-perforation.html
CROUS :
Emmanuelle Ricard Chargée de mission inter-universitaire-Crous Carte étudiant électronique Languedoc-Roussillon Crous de Montpellier 2 rue Monteil CS 85053 34 093 Montpellier cedex 5 04 67 41 50 66 / 06 78 44 19 05
CNOUS (gestion des numéros IZLY):
Sylvain Cammas Responsable du département Monétique Cnous 15, rue Guillaume VII le Troubadour – 86022 Poitiers 05 49 60 88 05 / 06 80 90 62 32
IZLY[modifier]
- Nous gérons la numérotation nationale des numéros de carte IZLY : voir SSI/CMS/CNOUS
- Nous avons 3 SAM CNOUS
- Le fichier de lecture de la SAM est aussi dans SSI/CMS/CNOUS
Nous ne faisons qu’envoyer les nom prénom et numéro de carte au CNOUS, les indices sont ensuite synchronisés par le SSI de la DR11.
En cas de soucis, voir dans cet ordre :
- Monecarte
- DR11
- CNOUS
Connecteurs[modifier]
Import RESEDA vers base carteCMS[modifier]
sur secu-CAB-DB (10.13.102.8) :
00 6 * * 0-6 /opt/scripts/scriptResedaCarte.sh >> /opt/scripts/logCarte
20 13 * * 1-5 /opt/scripts/scriptResedaCarte.sh >> /opt/scripts/logCarteMidi
* le script appelle une commande symfony dont les sources sont dans le répertoire /opt/scripts/carteSecu (On met à jour le code grâce à un dépôt git venant de gitLab). * la commande s'appelle cartecms:importReseda2Carte . * Ce script permet de copier les infos utiles de la base de données Reseda qui se trouve sur le serveur 10.13.102.9 et va importer les données dans la table carteCMS.Personnel du serveur secu-CAB-DB.
Le SGC utilise la base carteCMS comme sources de données
// a supprimer Il existe aussi le script /etc/scripts/importReseda2Carte_manuel.php qui permet d'importer une catégorie de personnel. Il faut éditer le fichier et commenter et décommenter ce que l'on veut.
Génération cartes pour gardien[modifier]
C'est l'application carte Multiservice de Duo qui va créer les enregistrements pour la base carteCMS
* https://duo.dr13.cnrs.fr/cartecms/index * -> menu administration -> générer... * cela permet de générer un lot de carte, il faut avoir des droits spécifiques pour accéder à ce menu, généralement réservé au SSI. * L'application va aller enregistrer directement les infos dans la base carteCMS avec comme tag provenanceDonneesIndividuelles = LOCAL
Export vers le contrôle d'accès[modifier]
Il y à 3 connecteurs d'exports vers le controle d'accès :
C:\Program Files (x86)\Monecarte\ConnecteurAEOSP\AEOSProcess.exe
Connecteur d'export des personnels (permanents / non premanents / retraités)
Il est lancé automatiquement toutes les 30 minutes
C:\Program Files (x86)\Monecarte\ConnecteurAEOSV\AEOSProcess.exe
Connecteur d'export des visiteurs
Il est lancé automatiquement toutes les 30 minutes
C:\Program Files (x86)\Monecarte\ConnecteurAEOS_Cartes_Visteurs\AEOSProcess.exe
Connecteur d'export des carte visiteurs sans nom.
Il faut le lancer manuellement.
Les logs des connecteurs sont dans E:\Logs
Pour les 3 connecteurs, ils vont aller vérifier sir il faut exporter les carte dans la table AEOS. Si le flag export est a 0, le script va pousser la carte et rebasculer le flag à 1.
Les connecteurs insèrent ensuite les données sur le serveur AEOS dans la table import. Il faut vérifier le champ status en cas de soucis, il doit être à OK. SI pas OK, voir le champ errorcode. Attention, il n'y a pas de contrôle automatique !
Erreurs connues :
- -1 : ne doit plus se produire, erreur de longueur de champ dans la base ou problème d'ecriture. Voir le champs status pour plus de détail (c'est assez explicite)
- 33 : mise en opposition d'une carte pas encore insérée dans le système : RAS ne pas en tenir compte
Export vers la base de données carteCMS[modifier]
C:\Program Files (x86)\Monecarte\ConnecteurDatabaseProcess\DatabaseProcess.exe
Lancé automatiquement 2 fois par jour.
Permet de récupérer les infos de numéro Nedap + numéro de carte + Id de la base CMS et de les ajouter a notre base de données (10.13.102.8)
Mise à jour depuis la base carteCMS[modifier]
C:\Program Files (x86)\Monecarte\SynchroPersonProcess\SynchroPersonProcess.exe
Lancé automatiquement 2 fois par jours
Le script va aller verifier si la base carteCMS a été mise a jour. En cas de MAJ, elles sont répercutées vers le SGC puis vers AEOS avec les scripts précédents.
Les carte visiteurs et les retraités ne sont pas mis a jour car nous n'avons pas d'infos sur leur départ.
Export CNOUS[modifier]
C:\Program Files (x86)\Monecarte\Connecteur CNOUS\CnousProcess.exe
Pas encore en service !
Opposition CNOUS[modifier]
C:\Program Files (x86)\Monecarte\CnousOppositionProcess\CnousOppositionProcess.exe
Pas encore en service !