Version 6 — Octobre 2013 — YannX
Deux champs spécifiques à SPIP sont gérés dans presque tous les objets éditoriaux : statut et maj :
- maj enregistre automatiquement la dernière date de modification
- statut est utilisé implicitement dans toutes les boucles de publication de l’espace public
Attention les auteurs ont une gestion de statut spécifique (qui ne sera pas étudiée ici ) !
Par défaut, tous les objets editoriaux de SPIP disposent d’un champ texte statut, d’origine historique, qui sert à contrôler la publication des éléments sur le site public, mais également à piloter le work-flow interne de SPIP.
Les valeurs par défaut [1] sont successivement :
- prepa
- prop
- publie
- refuse
- poubelle (ou poub ? ! )
Elles sont enregistrées dans la déclaration de tables SQL des objets connus de SPIP, avec la déclaration des libellés et images correspondantes.
Mais comment faire pour ajouter de nouveaux statuts : vous pensez évidemment à http://marcimat.magraine.net/Statut..., mais c’était pour SPIP 2 !
En SPIP 3, cela devient d’une simplicité..... et c’est documenté dans l’API editer_objet
Il suffit de rajouter une ligne à la définition de votre objet éditorial, dans le sous-tableau de declarer_tables_objets_sql
, tel que créé dans le sous-dossier ./base/
qui contient la définition de votre nouvelle table ;
par exemple :
'statut_textes_instituer' => array(
'prepa' => 'texte_statut_en_cours_redaction',
'prop' => 'texte_statut_propose_evaluation',
'publie' => 'texte_statut_publie',
'refuse' => 'texte_statut_refuse',
'poubelle' => 'texte_statut_poubelle',
'pourvu' => 'texte_statut_pourvue',
),
Et votre nouveau statut est automatiquement disponible dans le bloc de modification des status (le bloc « info » dans la page d’affichage en espace privé de l’objet).
Encore plus fort, si vous pensez à créer une mini-image-icone pour ce nouveau statut (dans ./prive/themes/spip/images/
, de nom puce-
nouveau_statut
-8.png
), votre image est automatiquement récupérée et disponible.... [2].
Il ne vous restera plus qu’a utiliser ce statut supplémentaire dans vos boucles de sélection dans vos squelettes....
A tester : Pour mieux intégrer les affichages implicites de SPIP, il est même possible de redéfinir quelques utilisations prédéfinies, de la même façon :
'statut'=> array(
array(
'champ' => 'statut',
'publie' => 'publie,pourvu',
'previsu' => 'publie,prop,prepa,pourvu',
'post_date' => 'date',
'exception' => array('statut','tout')
),
La modification de statut doit être traitée par action/editer_objet.php [ ] objet_instituer()
; mais elle peut être suppléée par action/editer_xxx.php [] xxx_instituer()
...
Pour personnaliser les traitements aux changements d’etats , il Il vous faut donc aussi créer un ./action/editer_xxx.php
dans lequel vous créerez les fonctions :
- xxx_modifier($objet, $id, $set)
- xxxx_instituer($objet, $id, $set)
Dans lesquelles vous définissez les étapes et traitements complémentaires voulus (avant d’appeler éventuellement directement la fonction d’origine : objet_modifier($objet, $id, $set)
standard !
----
Pour gérer un modèle de work-flow plus complet, mais qui s’intègre bien dans l’espace privé de SPIP, j’avais autrefois [3] pensé à utiliser un changement de rubriques à chaque validation ; mais cela implique aussi de changer les auteurs, et/ou d’utiliser les administrateurs restreints [4].
Les découvertes exposées dans cet article m’orientent, pour une meme problématique, vers un traitement post-fixé d’après la gestion des statuts, avec peut-etre une utilisation des options dans les autorisations (à suivre)...