[spip-dev] =?iso-8859-1?Q?Pb_de_requ=EAte_SQL?=

Dev
1

A mon avis, il y en aura d'autres par la suite, une fois que j'aurai
tout épluché.

Pour le moment, je travaille sur l'ajout d'un nouveau type d'acteur de
l'espace privé, le relecteur.

J'ai une erreur dans inc_mots.php", corrigeable graâce à cette ligne
(ligne 106) modifiée :

        if ($query_groupes!=0) $nombre_groupes = mysql_num_rows(spip_query($query_groupes));

pour tenir compte du cas où le statut du rédacteur n'est pas conforme
avec la BDD. C'est imagineable, si un rédacteur a réussi à forcer la
porte, ou sur un problème de cookie... on peut tout imaginer.

Au passage, j'ai ajouté le statut de connection ($connect_status) "7relecteur", puisque le relecteur aura des pouvoir compris entre le rédacteur et l'admin (il aurta le droit de corriger les articles, tous, ou ceux de la rubrique qu'on lui aura confiée

2

Non, vraiment, ça n'est pas urgent. Introduire la souplesse dans la gestion des droits, c'est bien, mais ça tourne immédiatement à l'usine à gaz. Cette souplesse n'a de sens que si tous les éléments de SPIP sont reconfigurables (articles, brèves, fiches-cuisine...), et ça ne me semble pas pour tout de suite.

ARNO*

3

Non, vraiment, ça n'est pas urgent.

Je crois qu'on dit la même chose : avant de se lancer à programmer des
statuts en plus, il faut travailler le concept coco !

Introduire la souplesse dans la gestion des droits, c'est bien, mais ça
tourne immédiatement à l'usine à gaz. Cette souplesse n'a de sens que si
tous les éléments de SPIP sont reconfigurables (articles, brèves,
fiches-cuisine...)

Exactement. Et zapper cette histoire d'admins restreints

-- Fil

4

Je l'utilise sur plusieurs sites, et c'est un bonheur.

Il y a des fuites de toutes parts du fait que leur 'statut' est '0minirezo'.
La fonctionnalité est sans doute valable, mais l'implémentation merdique.

-- Fil

5

Il y a des fuites de toutes parts du fait que leur 'statut' est
'0minirezo'. La fonctionnalité est sans doute valable, mais
l'implémentation merdique.

Là nous sommes d'accord.

Je vais me replonger dans le doc de réflexions à ce sujet, moi ... :wink:

-Nicolas

6

salut à tous, excuser moi j'ai du mal comprendre ou zapper un morceau, vous allez supprimer les admins de rubriques pour la prochaine version ?

--Karim

7

salut à tous, excuser moi j'ai du mal comprendre ou zapper un morceau,
vous allez supprimer les admins de rubriques pour la prochaine version
?

Oui, Fil va écrire une fonction zap_admins() ;-))

8

Alors il faudrait se mettre d'accord sur la procédure. En incluant le
boulot de relecteur, puisque nous avons l'air d'accor dsur le
principe... (un relcteur étant en fait un correcteur, qui n'aurait pas
le pouvoir de l'admin, ni la possiblité de publier un article/brève).

Actuellement, dans le module d'authentification (inc_auth), on définit
si une personne loguée (allez, on dira un auteur) a des droits
particuliers. S'il est l'auteur d'un document, ou s'il est admin.

Il faudrait différencier les droits sur
- les articles (le texte), et les cas écheant sur les articles dépendant
  d'une (des) rubrique(s),
- les droits sur la rubrique (idem),
- sur les mots clés,
- sur la conf du site complêt.

Dans le reste du document, pour afficher les boutons et et valider les
actions, ils suffirait de vérifier ces droits.

OK jusque là ?

9

Alors il faudrait se mettre d'accord sur la procédure. En incluant le
boulot de relecteur, puisque nous avons l'air d'accor dsur le
principe... (un relcteur étant en fait un correcteur, qui n'aurait pas
le pouvoir de l'admin, ni la possiblité de publier un article/brève).

Ah non, justement, pas du tout d'accord. Pas de nouveau statut intermédiaire! Et pourquoi pas un administrateur qui ne pourrait que gérer les brèves, et des rédacteurs qui pourraient créer des auteurs, un statut de traducteur, un statut de "j'ai ajouté le deuxième paragraphe"...?

Dans les premières versions de SPIP, il y avait bien plusieurs statuts. D'où le fait qu'on passe de 0 (0minirezo pour les admins) à 1 (1comite pour les rédacteurs) puis directement à 5poubelle. Le "1comite" était pour un "comité de rédaction", y'avait je crois "2redacteur", et honnêtement je ne me souviens plus si avait fait les autres (3 et 4). Les statuts intermédiaires qui servent à 2 webmestres, c'est bien gentil, mais c'est immédiatement incompréhensible.

Le principe admin/rédacteur est simple et efficace. Il repose notamment sur le principe de la responsabilité éditoriale. Les admins (qui se connaissent) savent que le texte est d'un rédacteur identifié (adresse email valide). Ce qui sera publié est donc bien le texte du rédacteur. Si tu balances des intermédiaires qui peuvent modifier des textes sans apparaître dans les modifs, alors tu ne sais plus s'ils ont respecté le texte d'origine, donc la responsabilité éditorial est perdue. Les seuls qui peuvent intervenir sur les textes des autres, ce sont les admins, parce que par définition tu leur fais confiance. Si tu fais suffisamment confiance à tes correcteurs pour qu'ils interviennent sans contrôle sur les textes des rédacteurs, sans que ces modifs soient signalées ("Machin a modifié ça sur le texte de Truc"), alors tu peux tout aussi bien les passer en Admin.

Il faudrait différencier les droits sur
- les articles (le texte), et les cas écheant sur les articles dépendant
  d'une (des) rubrique(s),
- les droits sur la rubrique (idem),
- sur les mots clés,
- sur la conf du site complêt.

Dans le reste du document, pour afficher les boutons et et valider les
actions, ils suffirait de vérifier ces droits.

OK jusque là ?

Naon... pas du tout.

Le réglage des droits est une usine à gaz incompréhensible pour le commun des mortels. Ca n'a de sens qu'avec un système réellement souple. Et la première souplesse passerait par une définition totalement personnalisée du contenu du site (des articles, des fiches cuisine, des critiques de film, des fiches de produits informatiques, etc.). Là, oui, une gestion vachement poussée des droits aurait un sens (tel type de participant gère les fiches cuisine, tel type gère les critiques de film, etc.). Sur SPIP, ça reviendrait à mettre des enjoliveurs de Ferrari sur une Deuche.

ARNO*

10

Si vous en avez déjà discuté, je vous prie de bien vouloir me pardonner pour
ce mail intempestif.
Y a qu'un petit point qui me chifonne dans ces histoires de statuts, c'est
le fait que n'importe quel administrateur puisse effacer la base, si je ne
m'abuse.
Cela ne devrait-il pas être réservé à un seul et unique ""webmaster"" ?

Donatien

11

Ah non, justement, pas du tout d'accord. Pas de nouveau statut
intermédiaire!

Tu parles du "relecteur", là ? Si oui, je suis d'accord, ce statut ne
présente à mon avis aucun intérêt.

Le principe admin/rédacteur est simple et efficace. Il repose
notamment sur le principe de la responsabilité éditoriale.

Un peu trop limité tout de même.

Si tu balances des intermédiaires qui peuvent modifier des textes
sans apparaître dans les modifs, alors tu ne sais plus s'ils ont
respecté le texte d'origine, donc la responsabilité éditorial est
perdue.

Exact.

Si tu fais suffisamment confiance à tes correcteurs pour qu'ils
interviennent sans contrôle sur les textes des rédacteurs, sans que
ces modifs soient signalées ("Machin a modifié ça sur le texte de
Truc"), alors tu peux tout aussi bien les passer en Admin.

+1

Le réglage des droits est une usine à gaz incompréhensible pour le
commun des mortels.

C'est pour ça que seul l'admin peut le faire, mais que le comportement
par défaut est simple.

Et la première souplesse passerait par une définition totalement
personnalisée du contenu du site (des articles, des fiches cuisine,
des critiques de film, des fiches de produits informatiques, etc.).
Là, oui, une gestion vachement poussée des droits aurait un sens
(tel type de participant gère les fiches cuisine, tel type gère les
critiques de film, etc.).

Tout le monde utilise déjà SPIP pour gérer différents types de
contenus, d'où la principale utilité des admins restreints.

Sur SPIP, ça reviendrait à mettre des enjoliveurs de Ferrari sur une
Deuche.

Trop d'humilité, c'est pas bon ... :wink:

-Nicolas

12

Sauf que leur fixer un statut différent ne résoudra pas réellement les choses, puisque le test important reste celui de savoir sur quelles rubriques ils sont actifs.

Du coup, tu remplacerais un test:

si (statut=0minirezo) ET (acces_a_la_rubrique)

par un test:

si (statut=0minirezo) OU (statut=2adminrestreint ET acces_a_la_rubrique)

Je ne suis pas certain qu'on évite plus les fuites avec ça.

ARNO*

13

Sauf que leur fixer un statut différent ne résoudra pas réellement
les choses, puisque le test important reste celui de savoir sur
quelles rubriques ils sont actifs.

Il faut différencier l'administrateur (ou webmaster) et les
rédacteurs en chef.

Le premier installe, configure, sauvegarde et auditionne le site,
c'est un techos, alors que les seconds gèrent la vie des contenus, ce
sont plus des fonctionnels.

Du coup, tu remplacerais un test:
si (statut=0minirezo) ET (acces_a_la_rubrique)
par un test:
si (statut=0minirezo) OU (statut=2adminrestreint ET acces_a_la_rubrique)

En gros, oui.

Avec mes niveaux de droits, ce serait donc :

if ((statut == 4) or (statut == 3 and redacchef(rub)) {
  ...
}

-Nicolas

14

Salut,

Histoire de vous montrer à quel genre d'usine à gaz on aboutirait avec une gestion des droits et des statuts, ci-joint une copie d'écran d'un essai que j'avais fait sur le sujet (fichier "articles.gif" en attachement).

C'est la partie de l'interface où l'on règle les droits des ARTICLES.

-> Avant cela, il y a une interface où l'on définit les statuts des participants (ici, j'ai créé un statut d'administrateur du site, de responsable éditorial, de rédacteur, de correcteur), et les statuts des documents (ici, on peut mettre les documents "en cours de rédaction", "proposé à la publication", "publié en ligne" et "refusé"). J'aurais pu évidemment ajouter des statuts supplémentaires de participants (traducteur, vérificateur de travaux finis...) et des statuts des documents (en cours de correction, etc.).

Il faut ensuite, pour chaque objet du site (ici, les ARTICLES), faire correspondre les droits des participants selon le statut des documents. Notez qu'il y a deux tableaux!

Ah oui, il faut d'abord comprendre la logique des droits. Ils vont de 1 à 5, et sont définis par le système.
1. Accès interdit (ce type de participant ne peut même pas voir un article dans ce statut)
2. Voir (ce type de participant peut voir ce statut de document)
3. Modifier (ce type de participant peut modifier _et_ voir ce statut de document)
4. Changer de statut (ce type de participant peut changer de statut, modifier et voir ce statut de document)
5. Mettre à la poubelle (ce type de participant peut détruire, changer de statut, modifier et voir ce statut de document).

Il s'agit donc ici des articles.

A. Tableau du haut: tous les documents, dont on n'est pas l'auteur.

- les administrateurs peuvent tout faire (statut 5) avec les articles dans n'importe quel statut
- idem pour les responsables éditoriaux
- les rédacteurs ne peuvent pas voir les articles en cours de rédaction des auteurs participants, il peuvent voir les articles proposés à la publication ou publié en ligne, ils ne peuvent pas voir les articles refusés
- les correcteurs ne peuvent pas voir les articles en cours de rédaction, ils peuvent modifier les articles proposés (mais pas les changer de statut), ils peuvent voir mais pas modifier les articles publiés en ligne, ils ne peuvent pas voir les articles refusés.

B. Tableau du bas: les documents dont on est l'auteur (ben oui, c'est pas pareil)

- les administrateurs et les responsables peuvent tout faire avec leurs articles dans n'importe quel statut
- les rédacteurs peuvent tout faire avec leurs articles en cours de rédaction ou proposés à la publication; mais à partir du moment où leurs articles sont publiés en ligne ou refusés, ils ne peuvent plus que les voir
...

Evidemment, il faut procéder de même pour tous les types de documents gérés sur le site (les rubriques, les mots-clés, etc.). Notez que pour les rubriques, il n'y a pas de statut "proposé à la publication" (si on suit la logique SPIP), on place donc "1. Accès interdit" sur toute la colonne "Proposé à la publication".

Ah oui, il faut comprendre que quand on a le droit "4. Changer le statut", on ne peut changer que vers un autre statut où l'on a également le droit "4. Changer le statut".

A tout cela, évidemment, appliqué à SPIP, il faut encore se demander comment gérer des droits différenciés selon certains éléments (certaines rubriques, pour des admins à accès restreint). Et là, je n'imagine même pas à quoi pourrait ressembler l'interface.

articles.gif

15

C'est marrant, cette discussion : une seule réponse suffit à pas mal de
questions :

Le réglage des droits est une usine à gaz incompréhensible pour le
commun des mortels.

cf. zope

Ca n'a de sens qu'avec un système réellement souple.

cf .zope

Et la première souplesse passerait par une définition totalement
personnalisée du contenu du site (des articles, des fiches cuisine, des
critiques de film, des fiches de produits informatiques, etc.).

cf. zope

Là, oui, une gestion vachement poussée des droits aurait un sens (tel type
de participant gère les fiches cuisine, tel type gère les critiques de
film, etc.).

zope ?

Sur SPIP, ça reviendrait à mettre des enjoliveurs de Ferrari sur une
Deuche.

... Welcome to Zope. Zope is a leading open source application server,
specializing in content management, portals, and custom applications. ...
Description: Z Object Publishing Environment
Catégorie: Computers > Software > Internet > Servers > Application > Zope
http://www.zope.org/

-- Fil

16

Du coup, tu remplacerais un test:
si (statut=0minirezo) ET (acces_a_la_rubrique)

par un test:
si (statut=0minirezo) OU (statut=2adminrestreint ET acces_a_la_rubrique)

Je ne suis pas certain qu'on évite plus les fuites avec ça.

La fuite c'est "je programme tel truc réservé aux admins et je mets le test
(statut==0minirezo)" en oubliant le truc batard des admins restreints. Du
coup, en cas d'oubli on ouvre une porte aux admins restreints. Avec un
statut différent en cas d'oubli la porte et fermée (et quelqu'un voit
rapidement que ça cloche et signale le problème).

M'enfin, je dis ça mais je m'en fiche un peu : admin/rédacteur me parait
largement suffisant (pour ceux qui ont accès à l'espace privé ; il faudrait
aussi gérer les visiteurs...)

En parlant de visiteurs, et de mailing-listes, je me dis que l'idée de les
coller dans la table spip_auteurs est pas la meilleure. En effet, les
pétitions sont un truc génial de mailing-liste : inscription depuis l'espace
public, vérification de mail, mot de passe, pas d'accès privé, lien avec un
article (donc autant de listes que de pétitions)....

-- Fil

17

Il faut différencier l'administrateur (ou webmaster) et les
rédacteurs en chef.

Le premier installe, configure, sauvegarde et auditionne le site,
c'est un techos, alors que les seconds gèrent la vie des contenus, ce
sont plus des fonctionnels.

Euh, pour les fonctions sensibles il y a déjà deux trucs :
1) confirmation par fichier ftp
2) une adresse meta pour le webmaster (envoi de mails "panique")

-- Fil

18

C'est marrant, cette discussion : une seule réponse suffit à pas mal de
questions :

Tant mieux, je n'ai qu'une seule réponse à faire alors :slight_smile:

Zope est une usine à gaz incompréhensible. Même moi j'y gobe que dalle,
et c'est pas peu dire. Bon, je n'y ai pas passé beaucoup de temps non
plus, mais Zope est un très très mauvais exemple. Zope est destiné à
être paramétré et configuré en profondeur par un spécialiste Zope avant
d'être éventuellement utilisable par le webmestre et ses potes. Tout
ce qu'on ne veut pas pour SPIP :wink:

19

Hello,

Il faut différencier l'administrateur (ou webmaster) et les
rédacteurs en chef.

Euh, pour les fonctions sensibles il y a déjà deux trucs :
1) confirmation par fichier ftp
2) une adresse meta pour le webmaster (envoi de mails "panique")

Oui, mais il ne suffit pas de protéger, il faut aussi masquer les
fonctions non nécessaires.

-Nicolas

20

Hello,

sans vouloir troller le forum:

j'ai entendu parler de Zope
j'ai installé Zope
j'ai achete le bouquin de pjg
j'ai testé (trés peu), ce qui prouve que l'ergonomie de Spip est de loin
plus abordable de Zope Oui il faut un spécialiste pour la mise en oeuvre !

Conclusion : je continu sur SPIP ou "yapafoto" :o)

Sans dec, c'est bien plus abordable pour mes personnes(asso,....) à qui je
montre SPIP
Voila, @+

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