Hello,
Dans le monde réel, un type fait une connerie, il se fait engueuler,
et il ne recommence plus. C'est un problème social, pas technique.
C'est plus à mon avis un problème technique, puisque la nature humaine
fait malheureusement que l'on est tenté de tout essayer, surtout s'il
y a un panneau "interdit" dessus ...
S'il y a un panneau mais pas de serrure, autant virer le panneau.
Il y a les mails de confirmation de validation pour surveiller la
chose.
En effet, mais ce n'est que du paliatif, pas du préventif.
En fait, le besoin est de bloquer l'article pour qu'il ne soit plus
modifié, parce qu'il a été validé sur le contenu, mais qu'il ne
soit quand même pas tout de suite mis en ligne, parce qu'il n'a pas
été validé sur la forme.
Publier dans le futur, ça fait ça. Et ça met l'article en vue dans
"à suivre".
Mouais. Ca veut dire qu'il faut tricher sur la date de publication,
qui n'est modifiable qu'une fois publié.
Donc si la page est demandée entre le moment où tu valides et celui où
tu modifies la date, ton cache est pourri.
Et surtout c'est une manip beaucoup plus complexe que juste cliquer
sur un bouton "OK, c'est valide sur le fond".
un workflow n'est pas une chaîne de montage.
Hum ... un peu quand même ... 
Beurk
Bin quoi ? On a bien un enchainement (donc une chaîne) d'opérations
bien différentes, de la rédaction à la mise en ligne.
Je ne propose surtout pas de sortir du mode linéaire, et je suis
d'accord qu'il faut avoir la possibilité pour le webmestre de "sauter"
la validation du fond si nécessaire !
1- qu'il faut qu'il parcours tous les articles pour voir ceux qui
ont un message de ce type dans le forum, ce qui n'est pas génial
par rapport à une liste qu'on lui proposerait dès l'accueil
Un mot-clé "BAT" peut servir à ça, et tu bidouilles une liste des
articles en attente de validation et qui ont le mot-clé "BAT" dès la
page d'accueil (c'est une ligne de code dans ecrire/index.php3 : si
tu insistes je te l'envoie !)
Nous avons déjà fait ça, ne t'inquiète pas, et je ne vois aucune
difficulté technique dans ce que je voudrais que SPIP fasse.
C'est juste que je souhaiterais tant qu'à faire que tout ce que nous
développons pour enrichir SPIP y soit repris, pour que :
1- SPIP en profite, si c'est souhaitable, ce qui n'est pas
négligeable, trop de gens exploitent les logiciels libres sans
comprendre qu'ils ont tout intérêt à y contribuer
2- nous puissions bénéficier des retours de la communauté sur la
fonctionnalité en question, et des éventuels
correctifs/enrichissements ultérieurs sans se creuser la tête avec
la maintenance d'une branche parallèle trop différente
Les droits du webmaster peuvent inclure ceux du rédac chef, là
n'est pas le problème ...
Si le webmaster est à l'hosto, que fait le redac'chef ? Il l'appelle
pour avoir son mot de passe ? (arf!)
Non, justement, si on a besoin d'un statut supplémentaire, c'est pour
que le rédac chef n'ait pas le droit de mettre en ligne, donc il faut
prévoir un backup de webmestre bien sûr.
Attention, je parle bien d'un système dans lequel il y a un nombre non
négligeable d'intervenants, pas d'une équipe de trois personnes.
On ne va pas s'emm... à gérer un statut de plus pour un besoin aussi
infime *et* qu'il est facile de structurer autrement.
Le besoin est pour l'instant infime parce qu'il concerne peu de sites
gérés actuellement par SPIP, certes, mais c'est un besoin très courant
chez pas mal de gens qui cherchent un outil de gestion de contenu et
ne prendront pas SPIP pour cette raison entre autres ...
Je précise une fois de plus que ce ne serait pas le fonctionnement par
défaut, ce serait activable dans la config.
PS: Si ça ne tenait qu'à moi, d'ailleurs, on supprimerait aussi dans
la version 1.5 la notion d'admin restreint.
Argh !
Car un admin à qui on affecte une rubrique et qui publie en dehors,
c'est une question sociale, et pas fonctionnelle...
???
Socialement, tu peux très bien être responsable d'une entité, mais
dépendre d'une autre, donc il faut que cela soit mis en oeuvre
techniquement, et les admins restreints sont parfaits pour ça.
si avec tous les outils qu'il y a dans spip + la voix + le téléphone
+ le mail les gens ne réussissent pas à communiquer, je ne vois pas
comment ils peuvent faire un site ensemble.
Prends par exemple (concret et réel) un ministère dont une dizaine
d'entitées publient en parallèle différents contenus dans des secteurs
différents d'un site. Disons que chaque entité représente 3 auteurs et
1 rédacteur en chef, et qu'il y a au niveau global 2 webmasters.
Il est impossible de tout gérer par des moyens de communication quels
qu'ils soient, il faut fournir à ces (nombreuses) personnes un outil
qui automatise et simplifie au maximum les tâches pour lesquelles
c'est possible.
Je parle ici d'un unique cas, mais j'en rencontre de nouveaux toutes
les semaines. Attention, je suis bien d'accord que SPIP n'a pas pour
vocation à répondre à tous les besoins qui peuvent se présenter, et
qu'il ne doit pas devenir une grosse usine à gaz, mais je pense qu'un
peu plus de souplesse dans la gestion du cycle de vie des contenus
pourrait être pas mal.
Si cela n'est pas ajouté à SPIP, nous ferons un fork à partir d'une
version stabilisée, tant pis pour tout le monde.
-Nicolas
