Workflows évolués pour Joomla! avec Seblod 1/4

Définition d'un workflow

Lors des formations sur le CCK SEBLOD nous apprenons comment le cck permet de réaliser des workflows complexes pour Joomla.

Dans une gestion électronique de contenus, un contenu subit des évolutions que traduit généralement une notion d’état général. On parle souvent de soumission /correction /validation /publication /archivage /suppression par exemple.

Mais l'état d'un contenu n'est qu'une partie du workflow. On doit en fait croiser plusieurs notions ensemble comme: 

* des états (qui doivent être configurables par projet et par type de contenu)
* des groupes d'utilisateurs (publics, auteurs, relecteur, gestionnaires, administrateurs etc...)
* des droits d'accès et des permissions par profil d'utilisateurs qui peuvent interagir plus ou moins sur le contenu
* des notifications emails selon les actions effectuées
* une notion de version de contenu peut compléter le workflow pour permettre notamment de revenir vers une version précédente du contenu.

Ces notions ne sont pas si importantes dans des petits sites gérés par un petit groupe d'administrateurs. mais dans des sites plus conséquents et
surtout dans des outils web (intranet, extranets, gestion électronique de documents (GED)) un workflow dédié devient absolument indispensable.

Manque de workflow dans Joomla!

Malheureusement Joomla ne gère pas de workflow nativement. On trouve bien une notion de champ 'état' qui est cependant limité à une petite liste de
valeurs (publié, dépublié, archivé, supprimé) et non modifiable.
Joomla propose bien une notification email automatique à la création de contenus mais là encore on ne peut contrôler le contenu ni le destinataire
du mail.
Bien sûr le niveau de granularité de joomla (l'article) ne permet pas non plus de définir des types de contenus spécialisés avec des règles de
workflow propres à chaque type de contenu.
On compte quelques extensions qui apportent des solutions partielles. Faut il en déduire que Joomla! est inadapté pour des applications web nécessitant
des workflows évolués ?
C'est sans compter avec le CCK Seblod qui, tout en restant dans l'écosystème Joomla! (un contenu Seblod est un article Joomla! étendu), permet
la programmation de workflows complexes.
Avec Seblod Joomla! voit son niveau de granularité passé de l'article monolithique aux champs qui constituent l'article. On dispose aussi d'une
interface graphique pour définir les comportements sur l'activation de conditions qui vont déclencher des actions comme les notifications emails

Workflows évolués avec Seblod pour Joomla

Quels sont les éléments que nous avons à notre disposition pour réaliser des workflows évolués sous Joomla! avec Seblod? Nous pouvons lister ces éléments suivants:

les états

L'état d'un contenu Seblod (= un article Joomla avec plus ou moins de champs) de base est le champ ARTICLE STATE qui reprend les valeurs des états possibles d'un article Joomla. La seule différence (et de taille) est que ce champ est modifiable et donc vous pouvez changer et ajouter ou supprimer des valeurs.
D'un point de vue technique il s'agit d'un champ de type SELECT SIMPLE qui est stocké en base de données exactement à l'endroit ou Joomla! stocke l'état d'un article c'est à dire dans la colonne STATE de la table #__content:

Vous l'aurez compris, avec Seblod vous avez découpé Joomla! en champs et vous pouvez venir modifier chaque champs vous donnant un contrôle inégalé sur le CMS tout en restant DANS le CMS.

Evidemment la modification du champ ARTICLE STATE a un impact sur tout le projet Joomla. On ne viendra donc le modifier QUE si on est sûr de vouloir modifier les valeurs possibles des états de tout Joomla.

Une méthode plus conseillée est de créer, pour chaque type de contenu un nouveau champ d'états, stocké au même endroit dans la base mais avec d'autres valeurs possibles. Ainsi tout en respectant les valeurs standards (1= publié, 0= dépublié par exemple) on peut personnaliser pour chaque type de contenu les états du workflow.

les champs emails

Un élément essentiel d'un workflow est l'ensemble des emails de notification qui sont envoyés à certaines personnes selon certains événements (généralement des changements d'état).

Seblod propose des champs email qui ne se contentent pas de stocker la valeur d'un email destinataire, mais qui sont de véritables gestionnaire d'envoi de mails dont les destinataires, corps et objets sont paramétrables dynamiquement.

On fera autant de champs emails que de type de notifications nécessaires dans le workflow. Chaque champ sera activé ou non par des filtrages ACLs (selon les types d'internautes) et des plugins de restriction ou des états conditionnels selon des événements et des valeurs d'autres champs.

les ACLs

Un autre élément essentiel d'un workflow évolué est de jouer avec les ACLs de Joomla, eux même basés sur les groupes de Joomla!

Ici Seblod ne modifie rien sauf que la granularité du projet Seblod se situe maintenant au niveau des champs et non plus sur l'article complet.

On pourra donc affecter une ACL par champ

Ainsi on pourra activer ou désactiver des champs selon l'internaute qui consulte la contenu. Attention cependant qu'un filtrage par ACL n'est pas équivalent à un masquage. Un champ filtré par les ACLs n'est pas seulement invisible, il n'est tout simplement pas sur la page.

les restrictions

On peut aussi activer ou désactiver un champ dynamiquement selon un filtrage autre que les ACLs mais (par exemple):

* si on est en création ou modification

* selon le groupe d'utilisateurs auquel appartient l'internaute

* selon la valeur d'un champ quelconque sur la page

A noter que le filtrage par ACL comme par un plugin de restriction s'effectue à l'affichage de la page. C'est tout différent avec la méthode suivante qui est dynamique!

les champs conditionnels

Une façon plus dynamique en effet de filtrer ou de modifier un champ est d'utiliser les états conditionnels de Seblod.

Ceux-ci permettent de définir d'une part des conditions et d'autre part des actions qui seront déclenchées sur l'activation de ces conditions.

Le grand intérêt des états conditionnels dans un workflow est qu'ils fonctionnent en dynamique selon les actions de l'internaute avant même qu'il valide ses changements.

Ainsi on pourra faire apparaître ou masquer des champs dynamiquement selon les valeurs choisies de certains champs. Dans un processus de workflow on s'en servira pour activer ou désactiver des champs emails qui seront des notifications lors d'un changement d'état.

Dans l'exemple ci-contre on voit le détail d'un état conditionnel sur un champ email qu'il est nécessaire d'expliquer un peu plus.

La partie gauche définit les actions qui seront effectuées, ici:

* le champ email sera activé (sinon il restera comme inexistant sur la page et le mail ne sera pas envoyé)

* le champ email sera rempli (c'est à dire l'email destinataire sera fourni et stocké)

La partie droite définit les déclencheurs des actions, ici:

* quand deux champs valent respectivement 02 et 14

* quand le champ email lui-même est vide

Cette dernière règle mérite qu'on s'y attarde car elle permet de ne déclencher l'envoi du mail qu'une seule fois. En effet, puisque le 3eme test porte sur la complétude du champ email (la valeur du destinataire) et que l'action consiste justement à remplir le champ, on a bien ici une méthode pour déclencher une notification email dans le workflow au PASSAGE de valeur (ici 02 et 14) et non seulement lorsque certains champs valent une certaine valeur.

Enfin il est important, pour que cette mécanique fonctionne, que le champ email possède bien un stockage sans quoi la valeur de l'email destinataire ne peut être stockée et donc ne peut servir de test au prochain passage.

les champs code

Pour les actions de workflow encore plus spécifiques Seblod nous propose des champs code dans lesquels on écrira du code en JavaScript ou PHP de façon complètement libre. On pourra aussi faire des requêtes SQL complexes dans les champs code PHP.

A noter qu'il y a trois sortes de champs code PHP:
* le champ code avant le rendu: il est exécuté à l'affichage de la page. On l'utilise donc pour masquer ou faire apparaitre des champs selon le contexte
* le champ code avant la sauvegarde: il est utilisé pour venir dynamiquement modifier des valeurs selon des règles qu'on aurait du mal à écrire avec les états conditionnels. Il est exécuté juste après avoir appuyé sur le bouton submit du formulaire mais avant le stockage en base de données (justement pour nous laisser le temps de venir modifier des choses)
* le champ code après la sauvegarde: identique au précédent mais qui est exécuté après la sauvegarde en base de données.

Ici dans notre problématique de workflow de validation, on peut être amené à utiliser un champ code 'avant la sauvegarde' pour venir placer un flag à une valeur pour que la prochaine fois que le contenu ou le formulaire d'édition du contenu est affiché, on puisse vérifier qu'on est déjà passé par là et donc ne pas déclencher tel ou tel événement.

EXEMPLE:
if ($fields['champ_test']->value)
if ($fields['champ_test']->value !=11)
$config['storages']['#__cck_store_form_montype']["mon_flag"]=1;

A noter ici qu'on ne s'est pas contenté d'écrire $fields["mon_flag"]=1 qui n'aurait eu aucun effet en base de données. En effet pour qu'un champs soit modifié manuellement en base il faut s'assurer que le tableau $config contienne bien les champs à stocker avec leur table associée.

Dans un prochain billet je vous montrerais un exemple simple de workflow qu'on peut réaliser avec ces notions!