Déverouillage automatique des tables

Réduire
X
 
  • Filtrer
  • Heure
  • Afficher
Tout effacer
nouveaux messages

  • [RÉGLÉ] Déverouillage automatique des tables

    Hello,

    J'ai certains clients qui verrouillent régulièrement des articles et étant donné qu'ils n'ont pas accès à la fonction de déverrouillage, ils sont obligés de me contacter.

    Est-ce que quelqu'un sait s'il est possible de scripter le déverrouillage des articles pour le lancer toutes les nuits en crontab par exemple? les tables impactées?
    Ou si une extension sait faire ça?

    Merci pour le coup de pouce
    Laurent
    woluweb aime ceci.
    Expert en conception et réalisation de sites Internet 100% Joomla
    www.toonetcreation.com

  • #2
    Bonjour,

    Si c'est le client lui-même qui a verrouillé, il doit pouvoir déverrouiller tout simplement ses propres articles ou modules (je prends pour principe qu'il a accès à l'administration et que c'est là qu'il verrouille).
    S'il s'agit d'utilisateurs multiples sur un même site, le problème est différent.
    Avec quel droits d'utilisateur se connectent-ils ?

    Pour savoir quelles tables sont concernées, il faudrait vérifier sur les sites des clients, mais a priori, ce ne doivent être que celles listées dans l'onglet de déverrouillage et oui, à mon avis un script en cron devrait faire l'affaire, ou encore un plugin.

    Pour les tables, il faudrait tester et voir par exemple si pour les articles une autre table est affectée par un verrouillage.
    "Patience et longueur de temps font plus que force ni que rage..." (La Fontaine : Le Lion et le Rat) - "Il n'y a pas de problèmes; il n'y a que des solutions" (André Gide).
    MoovJla et LazyDbBackup sur www.joomxtensions.com - FaQ sur www.fontanil.info - Site pro : www.robertg-conseil.fr chez PHPNET, sites perso chez PlanetHoster + sites gérés chez PHPNET, PlanetHoster, Ionos et OVH

    Commentaire


    • #3
      Je viens de faire un test : pour les tables "#__content" et "#__modules", on a deux champs, "checked_out" par défaut à "0" sinon avec le n° d'utilisateur qui a verrouillé, et "checked_out_time" qui enregistre l'heure de verrouillage et se remet à la valeur par défaut "0000-00-00 00:00:00" lors du déverrouillage.

      Ces mêmes champs se retrouvent dans d'autres tables, du core comme d'extensions. Il faudrait donc parcourir toutes les tables , vérifier la présence des champs et dans ce cas les remettre à zéro.
      "Patience et longueur de temps font plus que force ni que rage..." (La Fontaine : Le Lion et le Rat) - "Il n'y a pas de problèmes; il n'y a que des solutions" (André Gide).
      MoovJla et LazyDbBackup sur www.joomxtensions.com - FaQ sur www.fontanil.info - Site pro : www.robertg-conseil.fr chez PHPNET, sites perso chez PlanetHoster + sites gérés chez PHPNET, PlanetHoster, Ionos et OVH

      Commentaire


      • #4
        Envoyé par RobertG Voir le message
        Je viens de faire un test : pour les tables "#__content" et "#__modules", on a deux champs, "checked_out" par défaut à "0" sinon avec le n° d'utilisateur qui a verrouillé, et "checked_out_time" qui enregistre l'heure de verrouillage et se remet à la valeur par défaut "0000-00-00 00:00:00" lors du déverrouillage.

        Ces mêmes champs se retrouvent dans d'autres tables, du core comme d'extensions. Il faudrait donc parcourir toutes les tables , vérifier la présence des champs et dans ce cas les remettre à zéro.
        ok merci je vais faire une simulation sur un site de démo
        Expert en conception et réalisation de sites Internet 100% Joomla
        www.toonetcreation.com

        Commentaire


        • #5
          Envoyé par RobertG Voir le message
          Bonjour,

          Si c'est le client lui-même qui a verrouillé, il doit pouvoir déverrouiller tout simplement ses propres articles ou modules (je prends pour principe qu'il a accès à l'administration et que c'est là qu'il verrouille).
          S'il s'agit d'utilisateurs multiples sur un même site, le problème est différent.
          Avec quel droits d'utilisateur se connectent-ils ?

          Pour savoir quelles tables sont concernées, il faudrait vérifier sur les sites des clients, mais a priori, ce ne doivent être que celles listées dans l'onglet de déverrouillage et oui, à mon avis un script en cron devrait faire l'affaire, ou encore un plugin.

          Pour les tables, il faudrait tester et voir par exemple si pour les articles une autre table est affectée par un verrouillage.
          oui en effet le client lui même peut déverouiller les articles qu'il vérouille.
          Le soucis c'est que la il y a plusieurs personnes qui se connectent et desfois certains vont modifier les mêmes articles.
          donc dans l'idée, je voudrai aussi leur éviter de faire des actions manuelles et automatiser le tout la nuit via un crontab permet de ne demander aucune action à l'utilisateur et donc plus de confort pour lui
          Expert en conception et réalisation de sites Internet 100% Joomla
          www.toonetcreation.com

          Commentaire


          • #6
            hello,

            bon j'ai fais quelques tests en faisant des requêtes à la main et en effet il suffit de remettre le champ checked_out des tables en question à 0 pour déverrouiller la ressource. pour être propre, il faut aussi remettre le champ checked_out_time à la valeur 0000-00-00 00:00:00
            je vais le scripter via un script shell que je publierai sur ce post, si cela peut aider d'autres personnes.
            je pense que cela peut être très utile pour beaucoup de client de planifier ce type de script par crontab, au moins ils ne seront jamais bloqués sur leurs articles, menus etc...et cela leut évitera une manip manuelle de déblocage.

            bon we
            laurent
            woluweb aime ceci.
            Expert en conception et réalisation de sites Internet 100% Joomla
            www.toonetcreation.com

            Commentaire


            • #7
              Envoyé par Tortue Genial 69 Voir le message

              oui en effet le client lui même peut déverouiller les articles qu'il vérouille.
              Le soucis c'est que la il y a plusieurs personnes qui se connectent et desfois certains vont modifier les mêmes articles.
              donc dans l'idée, je voudrai aussi leur éviter de faire des actions manuelles et automatiser le tout la nuit via un crontab permet de ne demander aucune action à l'utilisateur et donc plus de confort pour lui
              J'aime beaucoup ton idée, j'ai plusieurs rédacteurs/éditeurs dans le site de mon client et je suis à la recherche d'une solution pareil, je souffre lol, Merci

              Commentaire


              • #8
                Envoyé par Clara2019 Voir le message

                J'aime beaucoup ton idée, j'ai plusieurs rédacteurs/éditeurs dans le site de mon client et je suis à la recherche d'une solution pareil, je souffre lol, Merci
                je pense que tu ne dois pas être la seule dans ce cas
                je publie le script dès que j'ai eu le temps de le faire et le tester sur plusieurs cas et plusieurs tables (en début de semaine je pense).
                woluweb aime ceci.
                Expert en conception et réalisation de sites Internet 100% Joomla
                www.toonetcreation.com

                Commentaire


                • #9
                  L'inconvénient d'une tâche cron est que sa mise en oeuvre est très variable d'un serveur à l'autre, entre ceux qui utilisent une URL ou pas, ceux qui ont leur paramétrage dans la gestion du compte d'hébergement, ce qui est à la portée de tous, et ceux qui nécessitent de passer par la console, et j'en oublie probablement.

                  C'est pourquoi j'ai pensé à un plugin système fonctionnant sur le même principe que LazyDbBackup, son paramétrage par l’utilisateur ou forcé à une heure précise et toutes les 24h par le codeur permettant de laisser le site lui-même s'occuper du déverrouillage.

                  Quant au script lui-même, pour qu'il puisse être universel, il faudrait qu'il déverrouille toutes les tables (en espérant qu'aucun utilisateur connecté n'est en train de faire des modifications), donc récupère les infos d'accès à la base dans le fichier de configuration, se connecte et balaie toutes les tables pour remettre ces deux champs, s'ils sont présents, à zéro.

                  L'inconvénient que je trouve à LazyDbBackup, mais le n'ai pas cherché à savoir s'il y avait une solution, parce que d'une part je n'ai fait qu'adapter le code de l’original et n'ai pas cherché à savoir si c'est le plugin qui est en cause, d'autre part son comportement m'arrange pour les tests, c'est qu'une sauvegarde est automatiquement lancée dès qu'on sauvegarde ou annule l'édition du plugin, ce qui est à exclure pour le déverrouillage des tables, qui serait dangereux en cours de journée.
                  woluweb aime ceci.
                  "Patience et longueur de temps font plus que force ni que rage..." (La Fontaine : Le Lion et le Rat) - "Il n'y a pas de problèmes; il n'y a que des solutions" (André Gide).
                  MoovJla et LazyDbBackup sur www.joomxtensions.com - FaQ sur www.fontanil.info - Site pro : www.robertg-conseil.fr chez PHPNET, sites perso chez PlanetHoster + sites gérés chez PHPNET, PlanetHoster, Ionos et OVH

                  Commentaire


                  • #10
                    Envoyé par RobertG Voir le message
                    L'inconvénient d'une tâche cron est que sa mise en oeuvre est très variable d'un serveur à l'autre, entre ceux qui utilisent une URL ou pas, ceux qui ont leur paramétrage dans la gestion du compte d'hébergement, ce qui est à la portée de tous, et ceux qui nécessitent de passer par la console, et j'en oublie probablement.
                    C'est pas faux, mais normalement via la commande crontab -e sur n'importe qu'elle distribution linux, on peut éditer le crontab facilement.
                    Et puis l'appel du script est généralement identique avec quelque chose de la forme suivante

                    Code:
                    00 03 * * * bash $HOME/scripts/mon_script.sh
                    Ici je lance mon script tous les jours à 3h du matin...cette syntaxe fonctionne sur n'importe quelle distribution linux.
                    Sachant que les hébergeurs sont soit sur du centos ou du debian, cela devrait le faire.

                    Maintenant, oui c'est sur que pour les débutants de chez débutants, sans quelques notions systèmes, même rudimentaires, je suis d'accord ce n'est pas du plug and play

                    Envoyé par RobertG Voir le message
                    C'est pourquoi j'ai pensé à un plugin système fonctionnant sur le même principe que LazyDbBackup, son paramétrage par l’utilisateur ou forcé à une heure précise et toutes les 24h par le codeur permettant de laisser le site lui-même s'occuper du déverrouillage.
                    La par contre, je trouve que rajouter (encore) un plugin pour une tâche système qui peut être effectuée à "bas niveau" par l'OS est dommage.
                    Le talon d’Achille des CMS (et aussi leur grande qualité) sont les extensions/plugin/composants.
                    Le soucis est que user et abuser de plugin pour tout et n'importe quoi rend plus vulnérable le CMS, plus lourd et plus complexe à maintenir.
                    Après ce n'est que ma vision, mais généralement j'essaye de réaliser ce type de tâches via des scripts shell, qui en plus peuvent être déployés à la chaine et en volume si on gère plusieurs site (perso je suis dans ce cas).
                    Un script banalisé peut être déployé à la volée et en terme de maintenance il n'y a pas d'adhérence à l'OS.
                    Maintenant, je comprends tout à fait que ce n'est pas nécessairement à la portée de tout le monde.

                    Envoyé par RobertG Voir le message
                    Quant au script lui-même, pour qu'il puisse être universel, il faudrait qu'il déverrouille toutes les tables (en espérant qu'aucun utilisateur connecté n'est en train de faire des modifications), donc récupère les infos d'accès à la base dans le fichier de configuration, se connecte et balaie toutes les tables pour remettre ces deux champs, s'ils sont présents, à zéro.
                    Personnellement j'ai choisi de me focaliser pour le moment sur les tables suivantes :

                    Code:
                    yh5ab_content
                    yh5ab_menu
                    yh5ab_extensions
                    Normalement, rien ne devrait être verrouillé à long terme dans ces tables.
                    En effet, le hic c'est que si quelqu'un modifié un article au moment ou le script passe, il perd tout.
                    C'est pourquoi il faut voir selon moi à qui peut s'appliquer ce script et le passer en pleine nuit vers 3/4h du matin ou normalement les probabilités qu'une personne modifie le site sont faibles...mais encore une fois, tout dépend du client en face.
                    Pour ma part je vais l'activer pour des mairies et la c'est du 100% certain que les agents du service plublic ne touchent pas au site en pleine nuit.
                    Pour le coté récupération des infos d'accès à la base etc...j'ai déjà des scripts qui fonctionnent comme ça.
                    - Le script est banalisé
                    - Il se connecte successivement sur chaque web client en ssh
                    - Il récupère les variables de connexion à la base et les mets dans des variables
                    - Il joue la ou les requêtes avec les bonnes infos de connexion
                    - il se déconnecte

                    Et le tour est joué.
                    Dernière édition par Tortue Genial 69 à 08/07/2019, 11h50
                    Expert en conception et réalisation de sites Internet 100% Joomla
                    www.toonetcreation.com

                    Commentaire


                    • #11
                      Hello.

                      C'est un petit plugin que je dois aussi faire depuis longtemps.

                      Moi je pensai checker la date de verrouillage (checked_out_time) et la dernière visite du user_id verrouillant l'élément (checked_out).

                      Donc mettre un paramètre dans le plugin du type "déverrouiller tout ce qui est verrouillé depuis + de x heures" et en vérifiant que l'id ayant verrouillé n'est pas connecté depuis moins de 1H (lastvisitDate) par exemple.

                      Si le lastvisitDate du userid est < au checked_out_time de ce même user ayant verouillé une ligne, ceci signifie qu'il est revenu sur le site après avoir posé ce verrou.
                      A partir de ce moment là et si on dépasse 2 ou 4H, je pense que le délais de réflexion est suffisamment long et que l'on peut déverrouiller.
                      De + il faudrait qu'il ait ouvert plusieurs onglets de navigateur et qu'il en ait oublié un d'ouvert.

                      Le script pouvant être lancé par cron (il existe aussi des services permettant cela), ou par un ou +ieurs évènement(s) (à voir lesquels, peut-être onContentPrepareData).

                      Par contre, le check je le ferais sur tous les composants du front bien sûr, car si un éditeur ferme la fenêtre en cours de maj d'un article, il le fait aussi pour un évènement, etc...
                      Dernière édition par roland_d_alsace à 08/07/2019, 11h56
                      A tous les utilisateurs de Joomla du très Grand Est de la France et du Jura suisse
                      Rejoignez le Joomla Users Groupe Alsace...
                      roland_d_alsace va-t-il devenir roland_du_grand_est ?

                      Commentaire


                      • #12
                        Envoyé par roland_d_alsace Voir le message
                        Hello.

                        C'est un petit plugin que je dois aussi faire depuis longtemps.
                        ah ? et du coté de la JED ?
                        If you have multiple users working in the backend of your Joomla based site , you know the problem: an item is checked out by another user, that user is not online anymore, because he has closed his browser window instead of logging out, his session has expired or the browser crashed. In Joomla 1.


                        ou de github :
                        Contribute to saimiri/joomla-plg-auto-checkin development by creating an account on GitHub.
                        Joomla User Group (JUG) Lille : https://www.facebook.com/groups/JUGLille/

                        Commentaire


                        • #13
                          Envoyé par daneel Voir le message

                          ah ? et du coté de la JED ?
                          If you have multiple users working in the backend of your Joomla based site , you know the problem: an item is checked out by another user, that user is not online anymore, because he has closed his browser window instead of logging out, his session has expired or the browser crashed. In Joomla 1.


                          ou de github :
                          https://github.com/saimiri/joomla-plg-auto-checkin
                          Oups merci Daneel.

                          Effectivement j'avais déjà regardé (mais oublié) ces plugins.
                          • Le 1er n'est prévu pour fonctionner qu'en admin.
                            Il fait le contrôle à chaque rendu (onAfterRender) et déverrouille tout ce qui verrouillé depuis + de x heure(s) (paramètre du plugin, implicitement 24H).
                            Il traite les articles, les modules, menus et extensions.
                          • Le 2ème fait le contrôle à chaque login (onUserAfterLogin) et déverrouille tout ce qui verrouillé depuis + de x minutes (paramètre du plugin, implicitement 60mn).
                            Il traite les articles, les catégories, les modules et menus.
                          Comme dit + haut, je pense que l'on peut faire un peu moins "radical" comme déverrouillage.
                          Dernière édition par roland_d_alsace à 08/07/2019, 13h18
                          A tous les utilisateurs de Joomla du très Grand Est de la France et du Jura suisse
                          Rejoignez le Joomla Users Groupe Alsace...
                          roland_d_alsace va-t-il devenir roland_du_grand_est ?

                          Commentaire


                          • #14
                            Comme convenu voici le script que j'ai créé et testé de mon coté pour les tables suivantes :
                            • yh5ab_content
                            • yh5ab_menu
                            • yh5ab_extensions
                            Il fonctionne parfaitement, mais est plus simple/basique que le plugin évoqué au dessus qui lui en effet aurait le mérite d'avoir plus d’intelligence dans la gestion de la purge.
                            Encore une fois, selon moi du moins, il ne faut pas faire pour faire, mais tout dépend du besoin réel.
                            Dans mon cas ce script suffit largement, et selon le type de client bien sur.
                            Mais le plugin évoqué plus haut est une excellente idée je trouve, pour des besoins avec un niveau de granularité plus fin.

                            Voici ci-dessous le script et les variables encore en dessous.

                            Le script

                            Code:
                            #!/bin/bash
                            # Script permettant de purger les éléments vérouillés des tables Joomla
                            
                            # Appel des fichiers de configuration contenant les variables (avec test d'existence au préalable)
                            VAR_CONF="$HOME/$SCRIPTS_PATH/var.conf"
                            
                            if [ -f $VAR_CONF ]; then
                                . $VAR_CONF
                            else
                                echo "Le fichier de configuration $VAR_CONF n'existe pas"
                                exit 1
                            fi
                            
                            # Purge des locks dans la table _content
                            mysql -D $BDD_NAME -e "UPDATE $TABLE_CONTENT SET $TABLE_FIELD_CHECKED_OUT = '$TABLE_FIELD_CHECKED_OUT_VALUE', $TABLE_FIELD_CHECKED_OUT_TIME = '$TABLE_FIELD_CHECKED_OUT_TIME_VALUE' WHERE $TABLE_FIELD_CHECKED_OUT != '$TABLE_FIELD_CHECKED_OUT_VALUE'"
                            
                            if [ $? -eq 0 ]; then
                                echo -e "Purge locks table $TABLE_CONTENT : $OUTPUT_OK"
                            else
                                echo -e "Purge locks table $TABLE_CONTENT : $OUTPUT_KO"
                            fi
                            
                            # Purge des locks dans la table _menu
                            mysql -D $BDD_NAME -e "UPDATE $TABLE_MENU SET $TABLE_FIELD_CHECKED_OUT = '$TABLE_FIELD_CHECKED_OUT_VALUE', $TABLE_FIELD_CHECKED_OUT_TIME = '$TABLE_FIELD_CHECKED_OUT_TIME_VALUE' WHERE $TABLE_FIELD_CHECKED_OUT != '$TABLE_FIELD_CHECKED_OUT_VALUE'"
                            
                            if [ $? -eq 0 ]; then
                                echo -e "Purge locks table $TABLE_MENU : $OUTPUT_OK"
                            else
                                echo -e "Purge locks table $TABLE_MENU : $OUTPUT_KO"
                            fi
                            
                            # Purge des locks dans la table _extensions
                            mysql -D $BDD_NAME -e "UPDATE $TABLE_EXTENSIONS SET $TABLE_FIELD_CHECKED_OUT = '$TABLE_FIELD_CHECKED_OUT_VALUE', $TABLE_FIELD_CHECKED_OUT_TIME = '$TABLE_FIELD_CHECKED_OUT_TIME_VALUE' WHERE $TABLE_FIELD_CHECKED_OUT != '$TABLE_FIELD_CHECKED_OUT_VALUE'"
                            
                            if [ $? -eq 0 ]; then
                                echo -e "Purge locks table $TABLE_EXTENSIONS : $OUTPUT_OK"
                            else
                                echo -e "Purge locks table $TABLE_EXTENSIONS : $OUTPUT_KO"
                            fi
                            
                            exit 0
                            Les variables

                            Code:
                            BDD_NAME=$(sed -rn "s/^\s*public .db\s*=\s*'(.*)'.*$/\1/p" $HOME/public_html/configuration.php)
                            TABLE_CONTENT="yh5ab_content"
                            TABLE_MENU="yh5ab_menu"
                            TABLE_EXTENSIONS="yh5ab_extensions"
                            TABLE_FIELD_CHECKED_OUT="checked_out"
                            TABLE_FIELD_CHECKED_OUT_VALUE="0"
                            TABLE_FIELD_CHECKED_OUT_TIME="checked_out_time"
                            TABLE_FIELD_CHECKED_OUT_TIME_VALUE="0000-00-00 00:00:00"
                            bruno28 aime ceci.
                            Expert en conception et réalisation de sites Internet 100% Joomla
                            www.toonetcreation.com

                            Commentaire


                            • #15
                              Merci Laurent pour le partage

                              Bonne journée
                              Cordialement, Bruno28

                              Joomla! 5.0.2 - php 8.2 - www.moneglisesurle.net - www.bp2i.fr

                              Adhérez à l'AFUJ : https://www.joomla.fr/association/adherer

                              Commentaire

                              Annonce

                              Réduire
                              Aucune annonce pour le moment.

                              Partenaire de l'association

                              Réduire

                              Hébergeur Web PlanetHoster
                              Travaille ...
                              X