Statuts sur les objets....

, par Matthieu Marcillaud

Définir des statuts permet - par exemple - de garder un objet en édition dans la partie privée de SPIP et de choisir de ne le publier sur l’espace public que lorsqu’il est prêt, par quelqu’un qui en a l’autorisation.

Indiquons d’abord que cela s’adresse à des SPIP 2.1, certainement 2.0 également. Pour les versions actuellement en développement, cela fonctionnera avec la 2.2 s’il cette version existe un jour, mais à partir de 2.3, ce code a été en partie simplifié (et heureusement !).

Nous allons supposer qu’un objet éditorial quelconque existe (ça peut être un Chat ou autre). Pour l’exemple, ce sera un objet « Formations », se composant d’une table spip_fh_formations et ayant la clé primaire id_formation (oui, déjà, il y a quelques incohérences entre le nom de la table et celui de la clé primaire, mais on fait avec ce qu’on a sous la main !).

Nous supposerons aussi que les pages de vue et d’édition de l’objet sont réalisées. Ce qui nous intéresse est exclusivement le statut.

Préambule

Il serait simple de penser qu’il suffit de mettre un champ « statut » dans le formulaire même d’édition pour changer le statut d’un objet... Mais que neni ! SPIP empêche cela ! Tout champ « statut » soumis dans les fonctions standards modifier_contenu() sera tout bonnement ignoré, car ce n’est pas la même autorisation qui entre en jeu. Le statut se change via un autre formulaire, ou une autre action (ou possiblement en bidouillant le formulaire d’édition, ce que nous n’oserons pas faire ici !)

Le statut dans la table

Il faut posséder un champ « statut » dans la table SQL de notre objet. Par exemple avec cette définition :

S’il n’y était pas, il faudra éventuellement forcer une mise à jour en incrémentant le numéro de version de la base du plugin (<version_base> dans plugin.xml) et en ajoutant au fichier d’installation (base/formations_upgrade.php) quelque chose comme le code ci-dessous dans la fonction formations_upgrade() :

Filtrer les boucles automatiquement sur les statuts

Nous pouvons créer un fichier de fonction et le déclarer (<fonctions>formations_fonctions.php</fonctions> dans plugin.xml) en disposant le code de boucle ci-dessous. On regarde 2 choses dans la boucle :

  • si un critère {statut} est présent : on n’opère pas de restriction, c’est le critère qui le définit. Par exemple {statut?} ou {statut IN prepa,publie}
  • si on est en « prévisualisation », on autorise en plus des articles publiés, les articles en préparation. (je n’ai pas testé cette partie).

Dans les autres cas donc, on force la présence dans les critères de requête d’une selection (WHERE) correspondant au statut « publie ».

Donner le droit de modifier le statut de l’objet

Dans le même fichier de fonctions (ou mieux, via le pipeline autoriser), on peut ajouter la fonction d’autorisation permettant (ici) aux administrateurs de modifier le statut de l’objet :

Afficher certaines des boucles dans le privé avec {statut?}

Notez que le critère {statut?} devra être ajouté à vos boucles sur l’espace privé dans certains fichiers (prive/contenu/formation.html, prive/exec/formation.html et d’autres) pour que la boucle s’affiche même si l’objet n’a pas le statut publié. Il faudra peut être dans certains cas, tester avant si l’utilisateur peut voir ou modifier l’objet avec une autorisation, par exemple, pour prive/exec/formation.html :

  • avec le plugin SPIP-Bonux :
  • ou avec le plugin Itérateurs (le critère si s’applique à n’importe quelle boucle)

On a donc conditionné l’affichage de la boucle à la vérification d’une autorisation.

Ajouter le bloc de changement de statut sur la vue de l’objet

Ceci fait, nous pouvons ajouter un élément dans le bloc d’information de l’objet, listant les différents statuts utilisables (que l’administrateur pourra changer).

Statuts des formations

Pour cela, nous créons les fichiers prive/infos/fh_formations.html (si ce n’est pas déjà fait) et prive/infos/fh_formations_fonctions.php.

Commençons par le code HTML :

Nous bouclons sur la boucle FH_FORMATIONS pour l’identifiant en cours de lecture ({id_formation=#ENV{id}}), indépendamment du statut de la formation ({statut?}).

Ce qui va afficher la liste des statuts est l’appel suivant :

(En dessous, l’appel au bouton « voir en ligne » n’est pas très standard. Je n’avais pas testé plus loin, comme déjà dit)

Donc, la ligne appelle une fonction nommée « instituer_fh_formation » que nous allons décrire dans le fichier php mitoyen. Cette fonction prend 2 arguments : l’identifiant de l’objet et son statut actuel :

Cette fonction ne fait que charger une autre fonction ! Dans un autre dossier (cela pour harmoniser avec les noms des fichiers de SPIP). Créons donc ce fichier inc/instituer_fh_formation.php et incorporons le code ci-dessous, copie presque identique aux fonctions d’autres objets simples (brèves) utilisées dans SPIP :

Cette fonction liste les statuts disponibles (avec le texte correspondant), génère une liste pour les afficher en surlignant le statut en cours de lecture. Il ajoute un lien d’action sur chaque lien pour permettre de changer le statut. Ce lien d’action (dans $href) pointe sur action/editer_fh_formation qu’il faudra modifier pour qu’il comprenne le message envoyé.

Dans notre exemple, il faudrait conditionner le lien de changement de statut à l’autorisation de modifier le statut de l’objet (instituer), ce qui n’est pas réalisé ici (pas bien !).

Que l’action s’effectue réellement !

Il faut maintenant éditer action/editer_fh_formation.php pour qu’il comprenne le message de notre action. On teste dans l’argument d’action $arg reçu, la présence de statut dans la chaine. Si c’est le cas, on traite notre statut comme provenant d’un formulaire (set_request()), sinon, on fait ce qu’on avait l’habitude.

Notre code de la fonction revisions_fh_formations() se trouve lui aussi complété pour tenir compte de la possibilité de la présence d’un changement de statut. On force dans ce cas le changement via la fonction sql_updateq(), mais uniquement si le statut à changé.

À ce moment là, notre changement de statut via le bloc gauche fonctionne. Oui, je l’accorde, il en faut du code !

Et les petites puces de changement rapide de statut ?

Ah quelle idée !
Vous souhaitez cela ?

Puces de changement rapide

C’est encore un rien complexe aussi !!!
Il faut, comme sur la page prive/exec/formations.html appeler le code qui va générer ces petites puces dans la boucle, qui est ici dans une cellule de tableau :

C’est la fonction puce_changement_statut() qui appelle inc_puce_statut_dist() qui va appeller une fonction puce_statut_${type}_dist(), soit pour notre exemple puce_statut_fh_formation_dist() qu’il nous faut créer. Je l’ai mis dans formation_options.php (pas adapté, mais ce sera bien mieux dans les futures versions !) :

En gros, la fonction liste les cases possibles et génère le code HTML de ces cases. La case active va se placer au bon endroit sur la souris lors du survol. La fonction afficher_script_statut() génère une action vers instituer_$type, soit ici instituer_fh_formation. Il nous faut créer ce fichier (action/instituer_fh_formation.php) qui redirige vers la fonction de révision de l’objet :

Voilà... Ouf !

Épilogue

Vous dites ? mais c’est horrible ce code pour une si petite chose ?
Je dirai : oui ! Il faut vraiment qu’on trouve quelque chose de plus simple et plus joli tel que :

A suivre !