16 Sep, 2021
2 commits
15 Sep, 2021
1 commit
05 May, 2021
1 commit
-
(alors qu'il ne peut pas y accéder...) Suppression message debug... v4.108.20-3.7.9
16 Feb, 2021
2 commits
-
v4.108.10-3.7.9
-
v4.108.8-3.7.9
15 Feb, 2021
2 commits
-
v4.108.7-3.7.9
-
- LOGOS => 2 logos par défaut (software et entity), remplacés par nouveaux logos du labo ssi existent - (e) LDAP activation ou désactivation => logout automatique pour obliger à se reconnecter avec un nouveau login - (b) bugfix Stats de connexion, mauvais format année : année 2021 et non pas 2121 !! (ça marchait pour 2020 forcément !!) - Cleanup des fonctions liées au ldap : ldapAuthentication() et _ldapSearch() - (b) bugfix fakeldap : champ 'uid' et non pas $this->authenticationType (qui était nul !!) - optimisation identification user ldap ou fakeldap : on le fait sur le login et non plus sur nom/pnom v4.108.6-3.7.9
05 Feb, 2021
1 commit
-
(FROM SCRATCH) - Documentation en ligne (install et technique) grandement mise à jour, pour une progression plus logique - Install from scratch OK ! - script d'installation plus simple, robuste, et cohérent : suppression des sudo création automatique de 4 utilisateurs de base (dont "superadmin"), qui vont permettre de démarrer confortablement avec l'application (en mode "sans ldap") BD créée et re-créée sans pb, avec accès root ou pas réorganisation dossier database/, ... - stats de connexion ok dès le début - stats sur les matériels (pages/stats) s'affiche correctement même quand aucun matériel dans la BD - script ADD_NEW_SUPERADMIN_USER_LDAP pour ajouter un utilisateur ldap en tant que superadmin, afin de préparer le passage en mode "avec ldap" - l'appli devrait normalement bien fonctionner dans les 2 modes "avec LDAP" ou "sans ldap" - Début de mise en conformité avec CakePhp 3.7 (fichier de configuration config/app.php notamment) - Bugfix plusieurs erreurs qui apparaissent quand il n'y a aucun matériel dans la BD... - Suppression du role ADMINPLUS (y-compris dans les tests) - Mise en conformité de certaines Fixtures (Users, Materiels) - LOGOs par défaut (mais encore IRAP donc à changer...) - TESTS auto ok - Tests manuels ok : - Génération PDF => OK (sauf QRcode...) - Génération QrCode => OK (sauf sur pdf...) - Envoi email => OK
04 Nov, 2020
1 commit
-
- (e) Par défaut, Utilisateur = Acheteur = celui qui crée la fiche (sans possibilité de changer si profil UTILISATEUR) - (e) Renommage et filtrage de quelques champs administratifs d'un matériel - (i) Requete sql pour ajouter types devis et facture dans type_documents - (b) Bugfix logout quand le user est déjà logout... - (i) Prix doit être strictement positif v4.107.2-3.7.9
27 Oct, 2020
2 commits
-
=> on utilise AppController.beforeFilter() au lieu de afterFilter() (ou encore config/bootstrap.php et src/Routing/Filter/SessionTimeoutFilter.php) => les actions login et logout sont traitées spécifiquement dans leurs fonctions respectives de UsersController (login() et logout()) v4.106.8-3.7.9
-
=> (on utilise AppController.afterFilter() au lieu de config/bootstrap.php et src/Routing/Filter/SessionTimeoutFilter.php) => le logout est géré spécifiquement car il n'est pas détecté par afterFilter()... v4.106.7-3.7.9
26 Oct, 2020
1 commit
-
=> (on utilise AppController.afterFilter() au lieu de config/bootstrap.php et src/Routing/Filter/SessionTimeoutFilter.php) => par contre, ça gère pas bien le logout, mais c'est pas grave car c'est rattrappé par le login suivant (qui fait memes stats que logout) v4.106.7-3.7.9
24 Oct, 2020
1 commit
-
(UsersController => StatsTable) v4.106.6-3.7.9
23 Oct, 2020
4 commits
-
=> maintenant c'est cohérent et clean => ca marche y-compris avec les stats de connexion ! v4.106.4-3.7.9
22 Oct, 2020
3 commits
-
v4.106.3-3.7.9
21 Oct, 2020
1 commit
-
=> maintient pour chaque utilisateur son nb de connexions et sa durée de connexion par année v4.106.0-3.7.9
10 Oct, 2020
2 commits
-
...et responsables => refactorisées en 1 seule action index() (index_recap() virée) et 1 seule vue index.ctp (index_recap.ctp virée) + bugfix tri colonnes de la liste des materiels v4.105.14-3.7.9
09 Oct, 2020
2 commits
-
- (b) bugfix requete sql db-update-2020-06-10.sql - (i) requete sql corrective - (b) bugfix tri colonnes des listes materiels et utilisateurs - (e) amélioration vue des responsables v4.105.13-3.7.9
-
v4.105.11-3.7.9
07 Oct, 2020
1 commit
-
(étape 3 sur 3, terminé) - Gestion automatique des entités "parentes" et "enfants" et de bcp d'autres choses encore... - Très générique (meta-programmation) => dans AppController:view_generic() => utilisation de mon helper src/View/Helper/MyHelperHelper/displayAssociatedEntitiesAsSectionShowHide() => un seul template unique utilisé /src/Template/Common/view.ctp, évite toutes ces trop nombreuses redondances, => plus efficace, on modifie tout en un seul endroit ! (au lieu d'une dizaine de pages web différentes avant !) v4.105.1-3.7.9
05 Oct, 2020
1 commit
-
=> dans AppController:view_generic()
01 Oct, 2020
1 commit
-
v4.103.22-3.7.9
30 Sep, 2020
2 commits
-
=> ajout des champs "est responsable du groupe métier/thématique" pour éviter ça v4.103.20-3.7.9
-
On était obligé de choisir un groupe métier et thématique et un domaine => désormais facultatif ('N/A') ! + divers petits bugfixes v4.103.19-3.7.9
25 Sep, 2020
2 commits
-
(VERSION FINALE) Aussi : - Bugfix action /materiels/mailDevis - Divers bugfixes v4.103.8-3.7.9
-
Les noms et verbes associés aux actions (pour les notifs) sont désormais aussi configurables, et par labo v4.103.7-3.7.9
24 Sep, 2020
1 commit
-
log et/ou email (étapes 4 et 5) Sauvegarde de l'entité courante dans $current_entity (dans AppTable), disponible pour tous les controleurs (sur save() et delete()) v4.103.6-3.7.9
23 Sep, 2020
1 commit
-
log et/ou email (étape 3) : - généralisaiton des types de notifications : log ou/et email - notification envoyée systématiquement pour toute action de toute entité, via afterFilter(), et ensuite invalidée éventuellement si pas autorisée v4.103.3-3.7.9
22 Jun, 2020
1 commit
-
- pour (presque) toutes les actions de (presque) tous les controleurs principaux (Materiels, Suivis, Emprunts, Users) mais aussi du controleur "quelconque" SurCategories (pour vérifier que ça marche aussi !!!) - (manque encore les tests de vues) - Dans ces tests génériques, on teste non seulement qu'une action s'exécute seulement quand elle y est autorisée, mais aussi qu'elle s'exécute correctement (au moins pour les actions CRUD : add,edit,delete...) - Le nombre total de tests (en ajoutant ces tests automatiques) monte à 220 !! - ...
17 Jun, 2020
1 commit
-
(Materiels, Suivis, Emprunts) - Dans ces tests génériques, on teste non seulement qu'une action s'exécute seulement quand elle y est autorisée, mais aussi qu'elle s'exécute correctement (au moins pour les actions CRUD : add,edit,delete...) - L'ajout d'un suivi, emprunt, ou document n'est plus autorisé SANS préciser l'id du matériel concerné, ce qui est logique - ajout champ 'nom' à la table emprunts - ...
05 Jun, 2020
1 commit
-
- bugfix : renommé groupe_thematique_id en groupes_thematique_id pour etre harmonisé partout et surtout avec "groupes_metier_id" !!! - bugfix : isSameGroup - tous les tests actuels ok - AUTORISATIONS DESORMAIS ADAPTABLES POUR CHAQUE LABO => pris en compte (testé) aussi dans les tests avec setAuthorizations_TEST() - Vues view (déjà fait avant) et index : les boutons d'action (éditer, valider, supprimer...) s'affichent désormais en fonction des autorisations centralisées
04 Jun, 2020
1 commit
-
(v 3.7.9.31) - SIMPLIFICATION DES AUTORISATIONS POUR LA PLUPART DES CONTROLEURS SIMPLES - AUTORISATIONS PAR DÉFAUT POUR TOUT NOUVEAU CONTROLEUR BASIQUE - AMELIORATIONS DE LA PAGE AFFICHANT LES AUTORISATIONS DYNAMIQUEMENT (/pages/acls ou /pages/acls/#nom_du_controleur) => On peut ainsi vérifier ce qui est appliqué à l'instant T (juste après la modif d'une règle par exemple)
11 May, 2020
1 commit
-
- Ajout d'un LOG applicatif dans le fichier /logs/debug.log pour toutes les actions importantes (add, edit, delete, ...) qui permet de savoir kiafekoi - Suppression des méthodes isAuthorizedAction() et isAuthorizedActionFor() car plus simple de ne garder QUE isAuthorizedAction() en la modifiant un peu... => du coup, c'est désormais cette SEULE méthode (dans CHAQUE controleur) qui décide de l'accès ou non à une action selon le profil utilisateur