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

[Tortue Genial 69]

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

[RobertG]

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.

[RobertG]

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.

[Tortue Genial 69]

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

[Tortue Genial 69]

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

[Tortue Genial 69]

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

[Clara2019]

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

[Tortue Genial 69]

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).

[RobertG]

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.

[Tortue Genial 69]

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

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

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.

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 :

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é.

[roland_d_alsace]

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...

[daneel]

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

[roland_d_alsace]

ah ? et du coté de la JED ?

https://extensions.joomla.org/extension/autocheckin/

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.

[Tortue Genial 69]

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

#!/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

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]

Merci Laurent pour le partage

Bonne journée