Déverouillage automatique des tables

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

  • 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 likes this.
    Expertise 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 hébergés chez PHPNET - sites perso chez PlanetHoster + sites gérés chez 1and1 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 hébergés chez PHPNET - sites perso chez PlanetHoster + sites gérés chez 1and1 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
        Expertise 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
          Expertise 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 likes this.
            Expertise 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 likes this.
                Expertise 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 likes this.
                  "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 hébergés chez PHPNET - sites perso chez PlanetHoster + sites gérés chez 1and1 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
                    Expertise 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 ?
                        https://extensions.joomla.org/extension/autocheckin/

                        ou de github :
                        https://github.com/saimiri/joomla-plg-auto-checkin
                        Joomla User Group (JUG) Lille : https://www.facebook.com/groups/JUGLille/

                        Commentaire


                        • #13
                          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"
                            Expertise en conception et réalisation de sites Internet 100% Joomla
                            www.toonetcreation.com

                            Commentaire

                            Annonce

                            Réduire
                            1 sur 2 < >

                            C'est [Réglé] et on n'en parle plus ?

                            A quoi ça sert ?
                            La mention [Réglé] permet aux visiteurs d'identifier rapidement les messages qui ont trouvé une solution.

                            Merci donc d'utiliser cette fonctionnalité afin de faciliter la navigation et la recherche d'informations de tous sur le forum.

                            Si vous deviez oublier de porter cette mention, nous nous permettrons de le faire à votre place... mais seulement une fois
                            Comment ajouter la mention [Réglé] à votre discussion ?
                            1 - Aller sur votre discussion et éditer votre premier message :


                            2 - Cliquer sur la liste déroulante Préfixe.

                            3 - Choisir le préfixe [Réglé].


                            4 - Et voilà… votre discussion est désormais identifiée comme réglée.

                            2 sur 2 < >

                            Assistance au forum - Outil de publication d'infos de votre site

                            Compatibilité: PHP 4.1,PHP4, 5, 6DEV MySQL 3.2 - 5.5 MySQLi from 4.1 ( @ >=PHP 4.4.9)

                            Support Version de Joomla! : | J!3.0 | J!2.5.xx | J!1.7.xx | J!1.6.xx | J1.5.xx | J!1.0.xx |

                            Version française (FR) D'autres versions sont disponibles depuis la version originale de FPA

                            UTILISER À VOS PROPRES RISQUES :
                            L'exactitude et l'exhaustivité de ce script ainsi que la documentation ne sont pas garanties et aucune responsabilité ne sera acceptée pour tout dommage, questions ou confusion provoquée par l'utilisation de ce script.

                            Problèmes connus :
                            FPA n'est actuellement pas compatible avec des sites Joomla qui ont eu leur fichier configuration.php déplacé en dehors du répertoire public_html.

                            Installation :

                            1. Téléchargez l'archive souhaitée : http://afuj.github.io/FPA/

                            Archive zip : https://github.com/AFUJ/FPA/zipball/master

                            2. Décompressez le fichier de package téléchargé sur votre propre ordinateur (à l'aide de WinZip ou d'un outil de décompression natif).

                            3. Lisez le fichier LISEZMOI inclus pour toutes les notes de versions spécifiques.

                            4. LIRE le fichier de documentation inclus pour obtenir des instructions d'utilisation détaillées.

                            5. Téléchargez le script fpa-fr.php à la racine de votre site Joomla!. C'est l'endroit que vous avez installé Joomla et ce n'est pas la racine principale de votre serveur. Voir les exemples ci-dessous.

                            6. Exécutez le script via votre navigateur en tapant: http:// www. votresite .com/ fpa-fr.php
                            et remplacer www. votresite .com par votre nom de domaine


                            Exemples:
                            Joomla! est installé dans votre répertoire web et vous avez installé la version française du fichier FPA:
                            Télécharger le script fpa-fr.php dans: /public_html/
                            Pour executer le script: http://www..com/fpa-fr.php

                            Joomla! est installé dans un sous-répertoire nommé "cms" et vous avez installé la version française du fichier FPA:
                            Télécharger le script fpa-fr.php dans: /public_html/cms/
                            Pour executer le script: http://www..com/cms/fpa-fr.php

                            En raison de la nature très sensible de l'information affichée par le script FPA, il doit être retiré immédiatement du serveur après son utilisation.

                            Pour supprimer le script de votre site, utilisez le lien de script de suppression fourni en haut de la page du script. Si le lien de suppression échoue pour supprimer le script, utilisez votre programme FTP pour le supprimer manuellement ou changer le nom une fois que le script a généré les données du site et le message publié sur le forum. Si le script est toujours présent sur le site, il peut être utilisé pour recueillir suffisamment d'informations pour pirater votre site. Le retrait du script empêche des étrangers de l'utiliser pour jeter un oeil à la façon dont votre site est structuré et de détecter les défauts qui peuvent être utilisé à vos dépends.
                            Voir plus
                            Voir moins

                            Partenaire de l'association

                            Réduire

                            Hébergeur Web PlanetHoster
                            Travaille ...
                            X