[spip-dev] Amélioration du workflow ...

Bonsoir,

je rencontre de plus en plus souvent, chez des clients, le besoin
d'une étape supplémentaire dans le cycle de vie des articles
(workflow).

Le processus "classique" de gestion des contenus mis en oeuvre dans
pas mal d'entités (sociétés, administrations ou associations), de la
rédaction à l'effective mise en ligne, est d'avoir :

- rédaction d'un article par un auteur
- validation sur le fond par un rédacteur en chef
- validation technique par un webmestre et mise en ligne

Dans SPIP, il manque donc deux choses :

- cette séparation en deux étapes de la publication : on demande à une
  unique personne de valider à la fois le fond et la forme, pour
  mettre en ligne, alors qu'elle n'a pas toujours la double compétence
  (voir jamais dans une grande organisation).

- un statut de rédacteur en chef.

Est-ce qu'il vous semblerait donc pertinent d'ajouter à SPIP une étape
intermédiaire avant "publié en ligne", "validé" par exemple, qui soit
éventuellement optionnelle ?

L'idée pourrait être que les administrateurs restreints déjà gérés par
SPIP deviennent uniquement rédacteurs en chefs si l'option est
activée, comme ça, pas de nouveau statut d'utilisateur à gérer.

De toute façon, si cette fonctionnalité ne vous intéresse pas, nous
serons tout de même amenés à la développer tôt ou tard, donc autant
nous aider ... :wink:

Bonne cogitation !

-Nicolas

- cette séparation en deux étapes de la publication : on demande à une
  unique personne de valider à la fois le fond et la forme, pour
  mettre en ligne, alors qu'elle n'a pas toujours la double compétence
  (voir jamais dans une grande organisation).

On ne demande rien à personne : un "rédac chef" peut très bien être admin et
ne pas valider... et un webmaster être aussi admin, valider et ne pas
intervenir sur le contenu. Tu mélanges fonction éditoriale et droits
informatiques...

Est-ce qu'il vous semblerait donc pertinent d'ajouter à SPIP une étape
intermédiaire avant "publié en ligne", "validé" par exemple, qui soit
éventuellement optionnelle ?

Non.

De toute façon, si cette fonctionnalité ne vous intéresse pas, nous
serons tout de même amenés à la développer tôt ou tard, donc autant
nous aider ... :wink:

Il serait plus intelligent à mon avis d'expliquer à tes clients qu'un
workflow n'est pas une chaîne de montage. Le "rédac'chef" n'a qu'à poser un
message "bon à tirer" dans le forum, et le "webmaster technique" apprendre à
ne valider que des articles marqués "bon à tirer". Et dis-leur que, quand
viendra Noël et que le "réd'chef" sera avec ses enfants à ouvrir les
cadeaux, il sera bien content que le "webmaster" puisse valider des
articles.

-- Fil

Il serait plus intelligent à mon avis d'expliquer à tes clients qu'un

PS: si ton client veut que son "statut" (social) soit supérieur à celui de
son subordonné, dis-lui qu'il peut mettre son nom en majuscules dans sa
fiche auteur. Fais-lui des squelettes dans lesquels les articles
n'apparaissent pas tant qu'il ne les a pas "signés" avec son auteur, etc.

-- Fil

Hello,

On ne demande rien à personne : un "rédac chef" peut très bien être
admin et ne pas valider...

Dans un monde idéal, oui, mais dans le monde réel, pas trop.

Si c'est possible, il le fera tôt ou tard, et pas forcément
volontairement.

et un webmaster être aussi admin, valider et ne pas intervenir sur
le contenu.

Oui, là il n'y a pas de problème, c'est juste la fonction de rédac
chef qui me manque.

Tu mélanges fonction éditoriale et droits informatiques...

Non, non, je parle bien d'un besoin purement fonctionnel, et j'en
déduis une logique informatique ... :wink:

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.

Après, comment on appelle le gars qui fait ci ou ça, et comment on
fait ça techniquement, je m'en fous, c'est vraiment le fonctionnel qui
m'intéresse.

Il serait plus intelligent à mon avis d'expliquer à tes clients
qu'un workflow n'est pas une chaîne de montage.

Hum ... un peu quand même ... :wink:

Le "rédac'chef" n'a qu'à poser un message "bon à tirer" dans le
forum, et le "webmaster technique" apprendre à ne valider que des
articles marqués "bon à tirer".

Cela signifie :

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

2- que l'auteur peut encore modifier les contenus, alors qu'ils ont
   été "validés", et par exemple y introduire des erreurs qui auraient
   conduit normalement au blocage total

Une autre solution de nous avons mis en place chez un client est un
mot clef "publié" sans lequel un article n'apparait pas sur le site,
mais ce n'est pas satisfaisant.
   

Et dis-leur que, quand viendra Noël et que le "réd'chef" sera avec
ses enfants à ouvrir les cadeaux, il sera bien content que le
"webmaster" puisse valider des articles.

Les droits du webmaster peuvent inclure ceux du rédac chef, là n'est
pas le problème ...

PS: si ton client veut que son "statut" (social) soit supérieur à
celui de son subordonné, dis-lui qu'il peut mettre son nom en
majuscules dans sa fiche auteur. Fais-lui des squelettes dans
lesquels les articles n'apparaissent pas tant qu'il ne les a pas
"signés" avec son auteur, etc.

Le problème est bien fonctionnel, et non social ... :wink:

-Nicolas

> On ne demande rien à personne : un "rédac chef" peut très bien être
> admin et ne pas valider...
Dans un monde idéal, oui, mais dans le monde réel, pas trop.

Ah bon. 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.

Si c'est possible, il le fera tôt ou tard, et pas forcément
volontairement.

Il y a les mails de confirmation de validation pour surveiller la chose.

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

> qu'un workflow n'est pas une chaîne de montage.
Hum ... un peu quand même ... :wink:

Beurk

> Le "rédac'chef" n'a qu'à poser un message "bon à tirer" dans le
> forum, et le "webmaster technique" apprendre à ne valider que des
> articles marqués "bon à tirer".

Cela signifie :

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

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

Le problème est bien fonctionnel, et non social ... :wink:

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.

PS: Si ça ne tenait qu'à moi, d'ailleurs, on supprimerait aussi dans la
version 1.5 la notion d'admin restreint. Car un admin à qui on affecte une
rubrique et qui publie en dehors, c'est une question sociale, et pas
fonctionnelle... 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.

-- Fil

Bonjour à tous,

J'interviens juste pour ça :

PS: Si ça ne tenait qu'à moi, d'ailleurs, on supprimerait aussi dans la
version 1.5 la notion d'admin restreint. Car un admin à qui on affecte une

Oh, non, s'il te plaît, non.

rubrique et qui publie en dehors, c'est une question sociale, et pas
fonctionnelle... 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.

Mais est-ce que le statut de l'article (proposé/publié) n'est pas social ? :slight_smile:

Je comprends tes réticences sur l'admin restreint mais je vois plutôt ça comme un moyen d'empêcher une connerie technique...

Certes, et je connais déjà la réponse, on peut faire plusieurs Spip que l'on syndique entre eux. Mais ce n'est pas pareil. Le site va évoluer, un admin restreint va peut-être amener à gérer plusieurs rubriques, etc.

Alors le rédac chef n'est pas admin, mais simp^le relecteur :wink:

Au CLX on fonctionne comme ça depuis le début, et pas de souci... Il y a
une dixaine de relecteurs réguliers, un rédac chef qui décide de
l'aspect éditorial et 2 backups, 1 webmestre qui décide au final dans
quelle rubrique l'insérer (en cas de doute), les mots clef etc. si ça
n'a pas été ajouté, avec 2 backups.

Si le redac chef ou le webmestre n'est pas là, d'autres prennent sa
place (s'il a averti de son absence, ou en cas de maladie ou autre).

Pas de problème avec cette organisation...

Si ton problème c'est d'avoir les nouveaux messages dans le forum,
j'avais déjà soulevé le point, plusieurs solutions sont possibles.
1/ afficher le nombre de messages à côté de chaque article
2/ Avoir le bouton gérer les forum, mais sans possibilité de
   modérer/voir les messages supprimé&s si ce n'est pas un admin qui
   regarde.

Je suis d'accord sur le fond.
Certaines associations ont de nombreux membres et ne peuvent pas au vu
de la quantité de mails et d'articles qui peuvent être proposés utiliser
des mailing list ou des forums. Dans le cas également ou les
responsables ont peu de temps, plus ils peuvent aller vite et mieux
c'est.
Sur la forme, à SPIP il ne manque rien pour réaliser cela comme l'a
spécifié Fil. Néanmoins, si vous vous sentez de penser et développer une
méthode supplémentaire pour gérer cela, SPIP en serait enrichi.
Comment proposeriez-vous un workflow paramétrable en conservant la
compatibilité avec celui actuel?
Sam

Les informaticiens aiment le progrès, pas le changement.

-----Message d'origine-----

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 ... :wink:

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

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

C'est vrai que, certaines antennes nous disent que pas mal de grosses boîtes
ou SSII fourguent du SPIP à leurs clients, sans jamais venir causer sur la
liste ni apporter un seul patch. Vous au moins vous renvoyez du code (comme
le prévoit la GPL, soit dit en passant).

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.

Disons alors qu'il faudrait faire la chose suivante : un mode "par défaut"
où tu as trois niveaux de responsabilité (admin, rédacteur, visiteur), et un
mode ultrahiérarchique où tu as des tas de niveaux intermédiaires, chaque
niveau ayant des droits vachement spécifiques (admins restreints qui ont le
droit de publier, censeurs qui ont droit de modérer les forums, etc.)

Dans ce cas, je pense qu'on peut défendre l'idée d'une API qui ferait : if
(autoriser("modif", "id_element")) { gnagna ; }
la fonction autoriser($modif, $id) étant modifiable à volonté.

Actuellement, on a des trucs du genre if($connect_statut=='0minirezo' AND
$connect_toutes_rubriques) { gnagn; } ; et déjà c'est la pagaille.

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.

Dans un cas comme celui-ci, il faut à mon avis monter plusieurs spip, et les
faire communiquer entre eux via des backends et autres blagues à développer
éventuellement. Si tu as 1500 personnes connectées à spip en même temps,
5000 rubriques et 1 million d'articles, je ne suis pas certain que l'espace
privé tienne le choc -- et que se passe-t-il en cas de bug ? Tu plantes
tes 1500 utilisateurs ?

Si cela n'est pas ajouté à SPIP, nous ferons un fork à partir d'une
version stabilisée, tant pis pour tout le monde.

Des menaces ? :wink:

-- Fil

C'est faux. La GPL n'oblige absolument pas à renvoyer du code. Elle n'oblige,
dans ce contexte, qu'à transmettre les modifications à ceux à qui on donne
la version modifiée, et ce sous la même licence. Elle n'oblige jamais à
renvoyer quoi que ce soit à l'auteur ou à qui que ce soit d'autre.

  Sam

La GPL n'oblige absolument pas à renvoyer du code. Elle n'oblige, dans ce
contexte, qu'à transmettre les modifications à ceux à qui on donne la
version modifiée, et ce sous la même licence.

OK. Pas d'argumentation légale, donc. Je reformule : "vous au moins jouez le
jeu du logiciel libre".

-- Fil

La GPL n'oblige absolument pas à renvoyer du code.

En effet.

Mais bon, ce modèle a des limites, ne serait-ce que techniquement, si
on ne veut pas se lancer dans un discours moralisateur ou idéologique.

-Nicolas

Mais bon, ce modèle a des limites, ne serait-ce que techniquement

Il faut reconnaître que la structure de spip ne se prête pas à l'explosion
en modules qui rendraient les contributions extérieures faciles à intégrer.
C'est sans doute aussi cette relative maîtrise/centralisation autour d'un
projet cohérent (* y compris dans ses limitations ! *) qui fait sa qualité.

D'où les discussions acharnées sur les extensions tous azimuts des statuts
auteurs/articles etc.

-- Fil

C'est vrai que, certaines antennes nous disent que pas mal de
grosses boîtes ou SSII fourguent du SPIP à leurs clients, sans
jamais venir causer sur la liste ni apporter un seul patch.

Oui, j'en ai aussi entendu parler.

Vous au moins vous renvoyez du code (comme le prévoit la GPL, soit
dit en passant).

Nous renvoyons tout ce que nous pouvons d'une part bien sûr parce que
nous sommes plus que sensibles au fonctionnement général des logiciels
libres, mais aussi parce que professionnellement cela nous apporte une
aide considérable.

Pour tout ce qui est effectivement adopté dans SPIP, nous assurons
ainsi une compatibilité avec les versions ultérieures, et surtout un
débugage grandement facilité par peer-review.

Lorsque nous recommandons SPIP ou un autre logiciel libre à un client
(mais nous bossons aussi avec des softs propriétaires, bien sûr), nous
recommandons vivement (et obtenons en général) de reverser dans la
communauté les développements effectués s'ils ne sont pas spécifiques
et compétitifs.

Disons alors qu'il faudrait faire la chose suivante : un mode "par
défaut" où tu as trois niveaux de responsabilité (admin, rédacteur,
visiteur), et un mode ultrahiérarchique où tu as des tas de niveaux
intermédiaires, chaque niveau ayant des droits vachement spécifiques
(admins restreints qui ont le droit de publier, censeurs qui ont
droit de modérer les forums, etc.)

En gros, oui, mais je ne suis même pas sûr qu'il soit souhaitable
d'avoir un système trop riche et totalement libre, quelques niveaux
facultatifs de plus suffiraient sans doute.

Dans ce cas, je pense qu'on peut défendre l'idée d'une API qui
ferait : if (autoriser("modif", "id_element")) { gnagna ; }
la fonction autoriser($modif, $id) étant modifiable à volonté.

Sans aller aussi loin que phpGACL ( http://phpgacl.sourceforge.net/ ),
on pourrait en effet avoir un système configurable ou programmable
pour configurer de façon très atomique les droits.

Actuellement, on a des trucs du genre
if($connect_statut=='0minirezo' AND $connect_toutes_rubriques) {
gnagn; } ; et déjà c'est la pagaille.

C'est la pagaille parce qu'on mélange un statut et un droit, alors que
le statut "0minirezo" devrait systématiquement donner tous les droits.

Je vais essayer de formaliser les différents cas concrets qu'on peut
rencontrer, qu'on ait une base saine de travail.

Prends par exemple (concret et réel) un ministère [...]

Dans un cas comme celui-ci, il faut à mon avis monter plusieurs
spip, et les faire communiquer entre eux via des backends et autres
blagues à développer éventuellement.

Astucieux, mais pas top pour les webmasters qui sont globaux.

Si tu as 1500 personnes connectées à spip en même temps, 5000
rubriques et 1 million d'articles, je ne suis pas certain que
l'espace privé tienne le choc

Cela ne risque pas d'arriver, de toute façon. Avec les chiffres que je
donnais, on arrivait à 10 entités de 4 personnes et 2 webmasters, soit
42 (damn !) personnes. SPIP ne risque pas grand chose, et de toute
façon la publication se fait sur un serveur, et la consultation sur un
autre.

et que se passe-t-il en cas de bug ? Tu plantes tes 1500
utilisateurs ?

Oui, mais c'est de toute façon pareil avec 10 SPIP identiques qui
tournent côte à côte.

Si cela n'est pas ajouté à SPIP, nous ferons un fork à partir d'une
version stabilisée, tant pis pour tout le monde.

Des menaces ? :wink:

Non, certainement pas, plutôt une déception. Nous avons déjà quelques
trucs qui n'ont pas été repris à mon regret, mais ils étaient moins
demandés que cela.

-Nicolas

Il faut reconnaître que la structure de spip ne se prête pas à
l'explosion en modules qui rendraient les contributions extérieures
faciles à intégrer.

Certes, mais contribuer à un projet, ce n'est pas seulement lui
ajouter de nouvelles fonctionnalités, le découpage en "modules" n'est
pas toujours possible ni souhaitable.

C'est sans doute aussi cette relative maîtrise/centralisation autour
d'un projet cohérent (* y compris dans ses limitations ! *) qui fait
sa qualité.

Oui, c'est clair !

Il faut abstraire et modulariser ce qui est possible, et il y en a
dans SPIP, mais pas tout.

-Nicolas

Cela ne risque pas d'arriver, de toute façon. Avec les chiffres que je
donnais, on arrivait à 10 entités de 4 personnes et 2 webmasters, soit
42 (damn !) personnes.

Arf ! Si à 42 ils n'arrivent pas à savoir qui fait quoi...

façon la publication se fait sur un serveur, et la consultation sur un
autre.

technique intéressante. Comment est géré le cache ("voir en ligne") ?

Oui, mais c'est de toute façon pareil avec 10 SPIP identiques qui
tournent côte à côte.

Sauf si c'est la base que tu plantes :slight_smile:

Non, certainement pas, plutôt une déception. Nous avons déjà quelques
trucs qui n'ont pas été repris à mon regret

Tu penses à quoi ? Le jajascript pour faire les gras ? lourd, mais on aurait
pu le mettre en option, il fallait finaliser l'interface et insister :wink:
La galerie de tous les docs joints ? L'interface n'était pas finalisée.
Autre chose que j'aurais oublié ?

A ce propos ,il nous manque un site de contrib/ fonctionnel, car le
répertoire qu'on a actuellement n'est pas gérable. Mais vu les capacités
dont on dispose en ce moment, je ne vois pas comment on pourrait répondre
correctement à la demande.

-- Fil

Arf ! Si à 42 ils n'arrivent pas à savoir qui fait quoi...

Ils gèrent des secteurs qui n'ont rien à voir, seuls les webmasters
doivent tout savoir de l'intégralité des contenus, ils ont cette
responsabilité.

façon la publication se fait sur un serveur, et la consultation sur
un autre.

Comment est géré le cache ("voir en ligne") ?

Les contenus sont répliqués d'une base vers une autre, manuellement ou
automatiquement à intervale régulier, donc il n'y a pas de
problématique de cache. Ce qui est vu sur le serveur de publication
est forcément plus à jour que ce qui est sur celui de production,
c'est tout.

Cela règle plusieurs problèmes :

- sécurité : l'interface de publication n'est accessible que depuis le
  réseau interne

- performance : les visites côté public ne font pas écrouler le
  serveur de publication

- contrôle : il est possible de vérifier le rendu avant de
  synchroniser

Nous faisons aussi pour d'autres client un mécanisme de copie en
version statique d'un site géré par SPIP en interne et hébergé sur une
plate-forme sans PHP ailleurs. Très intéressant, et pas toujours
simple ... :wink:
  

Oui, mais c'est de toute façon pareil avec 10 SPIP identiques qui
tournent côte à côte.

Sauf si c'est la base que tu plantes :slight_smile:

Si ce sont plusieurs serveurs qui tournent, oui ... :stuck_out_tongue:

Nous avons déjà quelques trucs qui n'ont pas été repris à mon
regret

Tu penses à quoi ? Le jajascript pour faire les gras ? lourd, mais
on aurait pu le mettre en option, il fallait finaliser l'interface
et insister :wink:

OK, on va insister lourdement alors, si c'est adopté dans SPIP ça nous
permettra sans doute de refuser plus facilement à nos clients de
rajouter une interface WYSIWYG de #$£%§&.

La galerie de tous les docs joints ? L'interface n'était pas
finalisée.

Abdoulaye doit justement la retravailler, et remplacer l'usage de
PEAR::DB par des requêtes spécifiques SPIP, mais il est parti
continuer ses études (et renforcer sa connaissance de la bière) à
Edinburgh, le pauvre ... :wink:

Autre chose que j'aurais oublié ?

Des trucs dont nous n'avons pas forcément beaucoup parlé pour
l'instant :

- une étape de plus dans le workflow ... :wink:
- la gestion de plusieurs versions d'un article
- des restrictions d'accès par rubrique côté public
- la gestion de newsletters
- une interface de consultation en flash à partir de squelettes XML
- ...

A ce propos ,il nous manque un site de contrib/ fonctionnel

En effet, mais sans logique de modules, il est de toute façon plus
difficile de proposer des contributions utilisables simplement, ça
reste technique.

-Nicolas

Je vote complétement pour. Si en plus elle pourrait être utilisable dans
les squelettes par une sorte d'appel à autoriser(lecture,la-ou-je-suis)
alors je pourrais virer toutes mes bidouilles (que je n'ose même pas
proposer en contrib tellement c'est moche).

Avez-vous une roadmap ou une todolist pour 1.5 ?

Salut,

Nicolas Hoizey wrote:
  > Des trucs dont nous n'avons pas forcément beaucoup parlé pour

l'instant :

- la gestion de plusieurs versions d'un article

Cette proposition est passé sans vraiment provoqué une véritable adhésion.

En fait, ça me semble important. Pour avoir testé SPIP en simple auteur sur le site (http://www.glums.com/allfreetemplatespip/), j'ai découvert qu'une fois mon article validé, je n'ai aucun moyen de rentrer en mode édition dans cet article. Pour l'histoire, c'était pour récupérer un texte déjà mis en forme. Sur le principe, si un article doit être mis à jour, seul un Admin. à la possibilité de faire les modifs...

Mon avis n'est pas technique, mais sur un constat simple : sur un site SPIP j'prefere être ADMIN !!! :wink: :wink:

a+
^Fabrice^^