Carnet Wiki

Gestion des Statuts

Gestion des Statuts

La Gestion des Statuts des Objets editoriaux est devenue simplifiée en SPIP 3 :
-  declaration autonome pour chaque objet editorial
-  gestion des libellés et images associés automatisée

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

Statuts de Publication

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

Si cette methode ne fonctionne pas, vous pouvez forcer la definition des puces comme ceci :

               'statut_images' => array(
                        'prepa'    => '../prive/themes/spip/images/puce-preparer-8.png',
                        'prop'     => '../prive/themes/spip/images/puce-proposer-8.png',
                        'publie'   => '../prive/themes/spip/images/puce-publier-8.png',
                        'refuse'   => '../prive/themes/spip/images/puce-refuser-8.png',
                        'poubelle' => '../prive/themes/spip/images/puce-supprimer-8.png',
                        'pourvu' => '../prive/themes/spip/images/puce-pourvu-8.png',
                )

Il est recommandé, dans le cadre d’un plugin, d’avoir votre nouvelle puce dans le repertoire du plugin et de pointer vers ce fichier, ce qui evite la perte de la puce lors d’une mise a jour de SPIP.

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')
                        ),

Le champs post_date sert à gérer la post-publication (doit-on afficher l’objet dans le futur), penser donc à que le champs indiqué existe bien (« date », ou « date_publication », ...)

Et pour gérer le work-flow !

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 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 un modèle de Work-Flow ?

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

[1Voir dans ./ecrire/inc/puce_statut.php..

[2Enfin, à l’exception d’un bug à mon premier essai.... à confirmer !!

[3SPIP 2 !

[4les autorisations n’étaient pas très documentées à cette époque, à part http://www.spip.net/fr_article3896.html, d’où la rédaction de Autorisations Dans Spip... voir maintenant http://www.spip.net/fr_article5528.html et http://programmer.spip.net/autoriser ...