[RÉGLÉ] Une extension utilisant le verrouillage ?

[RobertG]

Bonjour,

Depuis une modification récente de la gestion du verrouillage pour la version beta 6 de Joomla! 4 https://github.com/joomla/joomla-cms/pull/30747 le composant AppointmentBooking Pro voit ses éléments considérés comme verrouillés même si on les a correctement fermés. La valeur par défaut du champ checked_out est 0 pour différentes tables de cette extension.
Dans ces conditions, la page de liste des tables présentant des lignes à déverrouiller affiche ces tables et la fonction de déverrouillage est inactive parce que ces champs étant à 0, ils sont considérés comme verrouillés par un utilisateur à ID 0.
Les modifications des valeurs 0 pour checked_out et le champ de date de verrouillage pour "NULL" permettent de déverrouiller, mais si je modifie un élément susceptible d'être verrouillé pendant cette modification, sa fermeture ne le déverrouille pas.
Dans la table, alors que la fonction Joomla! est censée remettre à leur valeur par défaut ces champs, je les retrouve à 0, pas à NULL.
Rob Stevens, après avoir passé un peu de temps sur le sujet, préfère attendre une version ultérieure beta ou RC pour y travailler si besoin.

J'aimerais pouvoir tester une autre extension (tierce) utilisant ces champs. Pour le moment, je n'en ai pas trouvé. En connaissez-vous ?
Merci d'avance,
Robert

[roland_d_alsace]

Salut Robert.

C'est assez surprenant ton affaire là car si les tables du composant héritent de la classe JTable et qu'il y a un champ checked_out ET checked_out_time dans la table en question (ou un alias déclaré dans la classe de la table par la méthode setColumnAlias dans le constructeur),
le déverrouillage se fait automatiquement lors de l'enregistrement (méthode save de la classe mère).

Le développeur n'a rien à faire de spécifique dans son composant.

Donc si cela ne marche pas avec AppointmentBooking et qu'il respecte le fonctionnement normal du framework (classe de la table héritant de JTable, utilisation de la méthode "save" de la classe mère -attention pas de la méthode "store" qui n'appelle pas la méthode de déverrouillage "checkin", mais cela est déjà la cas actuellement-), cela ne devrait pas fonctionner non plus avec les composants natifs de Joomla.

L'essai peut être fait avec le mise à jour d'un article par exemple.

De mon côté je n'ai pas encore avancé avec le portage de mes extensions en J4, je ne peux donc pas te dire si je rencontre de problèmes avec cette fonctionnalité, mais vu que tout est géré par le framework, un problème signifierait qu'il y a un bug dans J4, et donc que les extensions natives (articles, menus, etc...) auraient le même problème.

[RobertG]

Merci Roland,

Si j'ai bien compris la modification citée sur Github, les lignes où checked_out et checked_out_time sont à 0, qui étaient précédemment considérées comme des lignes non verrouillées, puisqu'il n'y avait pas d'ID utilisateur les verrouillant, sont maintenant considérées comme verrouillées car il les faut à NULL. Il serait beaucoup plus logique de continuer à considérer 0 comme non verrouillé, d'autant que la fonction en version 3 écrivait 0 et pas un retour aux valeurs par défaut.

Pour cette extension, lorsqu'on l'installe sur une 4 beta 6 ou 7, ces champs sont, à l'ancienne donc, avec 0 comme valeur par défaut.
Joomla! considère comme verrouillées toutes les lignes ajoutées comme exemples.
Dans la page de déverrouillage global, elles sont donc listées. Le déverrouillage ne les supprime pas, puisqu'en remettant la valeur par défaut, il remet 0.

Je modifie la valeur par défaut dans la base pour NULL mais ne touche pas aux valeurs des données. Le déverrouillage fonctionne, la liste se vide, les champs en question sont bien remis à NULL.
Je mets en modification une des lignes, je sauvegarde ou j'annule, je la retrouve dans la liste des tables verrouillées, alors que la fonction qu'a trouvée Rob remet à défaut :

$query = $db->getQuery(true)
->update($db->quoteName($tn))
->set($db->quoteName('checked_out') . ' = DEFAULT');
(Joomla_4.0.0-beta7-Beta-Full_Package\administrator\components\com_checkin\ src\Model\CheckinModel.php)

Les valeurs devraient donc être NULL, elles sont de nouveau à 0. Si je déverrouille depuis Global Checkin, ce sont bien les valeurs NULL qui sont affectées à la ligne concernée.

La question est donc double : d'une part pourquoi considérer les valeurs 0 comme correspondant à des lignes verrouillées , et en quoi cela gênerait-il qu'on utilise 0 ou NULL ?
Dans la page Github, il est bien dit "It would also be good to test that check in still works with 3rd party components that don't use null values."

D'autre part pourquoi ces valeurs sont-elles remises à 0, sachant que dans le code du composant, on ne trouve aucune instruction pour le déverrouillage ? Comme tu le dis, il y a utilisation du déverrouillage par Joomla!, et je ne comprends pas (Rob non plus) la différence entre la fermeture en sauvegardant ou annulant et le déverrouillage global.

C'est pourquoi j'aimerais trouver une extension tierce compatible Joomla! 4 utilisant ces champs, pour comparer et essayer de comprendre

[RobertG]

Pour m'assurer qu'il n'y a rien dans le composant qui vienne entraver la fonction native de Joomla! pour le déverrouillage, j'ai pris du temps pour réviser tout le code, modifier tout ce qui pouvait définir checked_out et checked_out_time à 0 pour le passer à NULL, que ce soit dans le SQL d'installation ou le code. Plus aucune trace donc.
Lorsque j'accède à Global Checkin, rien n'est verrouillé. J'ouvre un "timeslot", par exemple, j'annule ou j'enregistre et quitte, les valeurs sont mises à 0 et la table réapparaît dans la liste de celles contenant des éléments verrouillés ! Le seul avantage de cette valeur 'null' par défaut est que le déverrouillage général fonctionne (il remet bien ces valeurs à null) alors qu'il ne fonctionne pas avec la version standard du composant (qui ne posait pas de problème en 4 beta 5, donc avant la modification de cette fonction de déverrouillage qui est apparue en beta6), puisque remettant les valeurs à 0, elles sont considérées comme verrouillant l'enregistrement, n'étant pas "null".

[roland_d_alsace]

Mais as-tu vérifié le comportement avec des composants natifs de Joomla ? (com_content par exemple)

[RobertG]

Avec ce qui est natif, pas de problème.
Je ne vois pas, puisque le composant ne déverrouille pas lui-même, pourquoi ce ne sont pas les valeurs par défaut dans la table qui sont utilisées lors du déverrouillage automatique, alors que le déverrouillage manuel fonctionne. C'est à croire que ce n'est pas la même fonction qui intervient dans les deux cas !
Et je n'ai toujours pas trouvé d'extension utilisant le verrouillage pour comparer.

[RobertG]

Pas de chance ! J'avais trouvé OS CCK light qui utilise bien ces champs, mais il n'est pas compatible avec J! 4 beta 7

[roland_d_alsace]

De mon côté je coince méchamment sur le passage des mes composants en J4 au niveau des champs de formulaires où pas mal de chose semblent changer.
Je n'ai donc pas pu tester directement le verrouillage sur mes composants.

Toutefois si je regarde la méthode checkin de la version beta actuelle de J4 (librairies/src/Table/Table.php) en ligne 1303 la classe mère JTable met bien null dans les champs checked_out et checked_out_time (à condition que le moteur de table gère le NULL).

// Get column names.
$checkedOutField = $this->getColumnAlias('checked_out');
$checkedOutTimeField = $this->getColumnAlias('checked_out_time');

$nullDate = $this->_supportNullValue ? 'NULL' : $this->_db->quote($this->_db->getNullDate());
$nullID = $this->_supportNullValue ? 'NULL' : '0';

// Check the row in by primary key.
$query = $this->_db->getQuery(true)
->update($this->_tbl)
->set($this->_db->quoteName($checkedOutField) . ' = ' . $nullID)
->set($this->_db->quoteName($checkedOutTimeField) . ' = ' . $nullDate);
$this->appendPrimaryKeys($query, $pk);
$this->_db->setQuery($query);

// Check for a database error.
$this->_db->execute(); 

Alors qu'en J3 même fichier mais en ligne 1133, effectivement on y place 0

// Check the row in by primary key.
$query = $this->_db->getQuery(true)
->update($this->_tbl)
->set($this->_db->quoteName($checkedOutField) . ' = 0')
->set($this->_db->quoteName($checkedOutTimeField) . ' = ' . $this->_db->quote($this->_db->getNullDate()));
$this->appendPrimaryKeys($query, $pk);
$this->_db->setQuery($query); 

Si ce n'est pas le cas, il faut donc supposer que les tables du composant que tu testes (AppointmentBooking) n'héritent par de la classe JTable et n'utilisent pas cette méthode du Framework.

Le verrouillage et déverrouillage d'un ligne est donc gérée par le composant et il faut chercher ailleur.

Dans le doute mets un petit :

Factory::getApplication()->enqueueMessage('passage en '.__FILE__.' ligne:'.__LINE__); 

en lligne 1313 de librairies/src/Table/Table.php.

Tu verras alors lors d'un test si ton composant passe par la méthode checkIn de JTable pour déverrouiller correctement l'enregistrement.

[RobertG]

J'ai pourtant bien dans les fichier du dossier "Tables" du composant (ici pour les périodes à réserver) :

class Tabletimeslots_detail extends JTable

Je viens d'essayer cette utilisation du message standard, et on passe bien dans Table.php.

Dans mes modifications, j'ai bien remplacé les valeurs par défaut des deux champs à NULL, ainsi que dans tous les fichiers où leur valeur par défaut était définie à 0.
Est-ce que je comprends bien cette ligne ?

$nullID = $this->_supportNullValue ? 'NULL' : '0';

Cela ne veut-il pas dire que si le champ ne supporte pas d'être null, on y met 0 ?

La table de ces timeslots est bien définie ainsi

[roland_d_alsace]

Je viens d'essayer, de façon indifférente Null ou 0 dans checked_out, signifie déverrouillé (Ceci que checked_out_time soit Null ou avec un datetime valide).

Essaye dans la table #__content, il faut que checked_out contienne 1 ou + pour que le cadenas apparaisse.

J'ai pourtant bien dans les fichier du dossier "Tables" du composant (ici pour les périodes à réserver) :

Je viens d'essayer cette utilisation du message standard, et on passe bien dans Table.php.

Dans mes modifications, j'ai bien remplacé les valeurs par défaut des deux champs à NULL, ainsi que dans tous les fichiers où leur valeur par défaut était définie à 0.
Est-ce que je comprends bien cette ligne ?

Cela ne veut-il pas dire que si le champ ne supporte pas d'être null, on y met 0 ?

La table de ces timeslots est bien définie ainsi

Ce n'est pas le champ, mais la table (son moteur) qui doit supporter Null, mais que ce soit myisam ou innodb, ce sera le cas.
Franchement, ce test n'apporte rien avec mysql ou mariaDb.

Si Null n'est pas autorisé dans le champ, ce n'est pas testé, le framework essaiera de mette Null de force et mysql retournera alors un erreur :
1048 Le champ 'checked_out' ne peut être vide (null)

Concernant la valeur par défaut du champ checked_out, elle n'est pas utilisée.
La méthode checkin de la classe Table, met Null ou 0.

Si tu passes bien en ligne 1313, tu devrais avoir Null dans checked_out de la table en question.
Il faudrait vérifier que l''on est dans la bonne table.

Modifie ma ligne de trace par celle-ci qui affichera la table déverrouillée et l'id de la ligne:

Factory::getApplication()->enqueueMessage('passage en '.__FILE__.' ligne:'.__LINE__.' table:'.$this->_tbl. ' ID:'.$this->id); 

Ceci toujours en ligne 1313 de librairies/src/Table/Table.php.

[RobertG]

Je passe bien sur cette ligne puisque le message s'affiche, il s'agit bien de la bonne table et je me retrouve bien avec checked_out à 0 et checked_ou_time à 0000-00-00 00:00:00
Quand une ligne est avec l'un ou l'autre de ces champs à 0, c'est systématique, Joomla! considère que l'élément est verrouillé.
La table timeslots est de type MyISAM utf8_general_ci, la table content est en InnoDB utf8mb4 et la seule différence que je vois et que dans cette table content checked_out est "unsigned" (et en plus en index)

[RobertG]

Bien, après vérification, ces deux lignes citées plus haut (dans Table.php) me renvoient bien 0

$nullDate = $this->_supportNullValue ? 'NULL' : $this->_db->quote($this->_db->getNullDate());
$nullID = $this->_supportNullValue ? 'NULL' : '0';

Ce qui voudrait dire que la table est en cause ?

[roland_d_alsace]

Je passe bien sur cette ligne puisque le message s'affiche, il s'agit bien de la bonne table et je me retrouve bien avec checked_out à 0 et checked_ou_time à 0000-00-00 00:00:00
Quand une ligne est avec l'un ou l'autre de ces champs à 0, c'est systématique, Joomla! considère que l'élément est verrouillé.
La table timeslots est de type MyISAM utf8_general_ci, la table content est en InnoDB utf8mb4 et la seule différence que je vois et que dans cette table content checked_out est "unsigned" (et en plus en index)

C'est étrange que tu n’ai pas Null, mais cela ne devrait pas gêner.

Pour la gestion d'une ligne verrouillée, ce n'est pas que Joomla, mais aussi le composant qui doit gérer (Joomla ne sais pas forcement ce que tu veux faire, par exemple l'affichage doit être autorisé).

C'est donc en général dans la vue du composant que cela se passe en 1er.

Si tu regarde dans /administrator/components/com_content/tmpl/articles/default.php en ligne 258 :

<?php if ($item->checked_out) : ?>
<?php echo HTMLHelper::_('jgrid.checkedout', $i, $item->editor, $item->checked_out_time, 'articles.', $canCheckin); ?>
<?php endif; ?>

La condition du IF est vrai quand checked_out est différent de Null ET différent de 0.

quand on essaie de mettre à jour un élément verrouillé et que l'on est pas le membre ayant posé le verrou, ceci est contrôlé dans le controlleur général en librairies/src/MVC/Controller/FormController.php methode edit ligne 389-407 :

$checkin = $table->hasField('checked_out');
.
.
if ($checkin && !$model->checkout($recordId))
{
// Check-out failed, display a notice but allow the user to see the record.
$this->setMessage(Text::sprintf('JLIB_APPLICATION_ERROR_ CHECKOUT_FAILED', $model->getError()), 'error');

$this->setRedirect(
Route::_(
'index.php?option=' . $this->option . '&view=' . $this->view_item
. $this->getRedirectToItemAppend($recordId, $urlVar), false
)
);

return false;
}
else
{
// Check-out succeeded, push the new record id into the session.
$this->holdEditId($context, $recordId);
Factory::getApplication()->setUserState($context . '.data', null);

$this->setRedirect(
Route::_(
'index.php?option=' . $this->option . '&view=' . $this->view_item
. $this->getRedirectToItemAppend($recordId, $urlVar), false
)
);

return true;
} 

Mais if faut bien sûr que le contrôleur utilisé (s'il y en a un) hériter de JFormControler (à la sauce J3 et <) et que sa méthode edit soit utilisée et qu'il lance la méthode edit de la classe parente.
Idem tu peux vérifier que l'on passe bien par là dnas le composant testé.

et bien sûr aussi que l'on utilise aussi la méthode checkout du model général, appelée par le contrôleur, model qui trouve en en librairies/src/MVC/Model/FormModel.php et sa methode checkeout en lignes 132 à 173 :

$user = Factory::getUser();
$checkedOutField = $table->getColumnAlias('checked_out');

// Check if this is the user having previously checked out the row.
if ($table->$checkedOutField > 0 && $table->$checkedOutField != $user->get('id'))
{
$this->setError(Text::_('JLIB_APPLICATION_ERROR_CHECKOUT _USER_MISMATCH'));

return false;
} 

Le Null et le 0 sont bien considéré comme déverrouillés.

Donc au niveau de Joomla tout me semble correct.

[roland_d_alsace]

Petit rajout à ma réponse ci-dessus, concernant le support du Null.

Après vérification, c'est une nouveauté de J4, il faut l'indiquer dans le classe de chaque table héritant de Table (JTable), car de base dans la classe mère il est à false (voir /librairies/src/Table/Table.php ligne 132)

Donc à définir pour chaque du composant, par exmeple pour la rable #__content, voir /librairies/src/Table/Content.php ligne 40 :

/**
* Indicates that columns fully support the NULL value in the database
*
* @var boolean
* @since 4.0.0
*/
protected $_supportNullValue = true; 

[RobertG]

Merci Roland !

Je viens de tester sur la version originale du composant pour J!4 mais cette modification ne suffit pas.
Mais sur ma version de tests où j'ai remplacé dans la structure des tables et les exemples tous les 0 par null pour checked_out et checked_out_time, idem dans les valeurs définies par défaut dans les fichiers du dossier "tables", ça fonctionne.

Je l'ai signalé à Rob qui m'a dit prévoir une nouvelle version. J'en ai profité aussi pour lui rappeler que JFactory est maintenant remplacé par Factory. Beaucoup de modifications à prévoir encore ! (2428 fois utilisé dans 482 fichiers)