Le 26 déc. 2009 à 19:10, esj@rezo.net a écrit :
Author: esj@rezo.net
Date: 2009-12-26 19:10:52 +0100 (sam, 26 déc 2009)
New Revision: 14810
Log:
Correction de la fonction {{{formulaires_editer_objet_charger}}}: si la fonction {{{_select}}} correspondant à l'objet a retourné vide, c'est qu'on a fourni un id inexistant ou interdit d'accès au demandeur, il ne faut donc pas proposer un formulaire d'édition comme si on créait un nouvel objet. Cas typique: un rédacteur veut revenir sur un article déjà publié, il n'a donc plus les droits et il est contre-intuitif de lui donner un formulaire sans pré-remplissage, qui lui fait croire que son article a disparu.
Avec cette modif, on retourne un bloc vide à la place du formulaire, mais il serait plus éloquent de retourner un message d'erreur. Il faudrait le faire dans {{{balise_FORMULAIRE__dyn}}}, en changeant {{{''}}} dans son {{{if ($valeurs===false) return '';}}} mais je ne suis pas sûr que ça n'ait pas des conséquences ailleurs.
Hello
je ne suis pas vraiment d'accord : ce n'est pas un bug que tu corriges là, mais la spécification que tu modifies.
1.
le parti avait été pris de considérer que ce n'est pas au formulaire de gérer le droit d'éditer un objet, et que
#FORMULAIRE_EDITER_XXX
devait présenter le formulaire d'édition de l'objet indépendamment de cela.
C'est au squelette utilisant #FORMULAIRE_EDITER_XXX de donner accès ou non au dit formulaire en fonction des droits.
2.
Avec cette modification, il n'est plus possible de demander l'édition d'un article 23 inexistant sans d'abord le créer en base.
Ce type de choix ne doit pas relever du formulaire mais uniquement de l'interface.
Dans SPIP, l'interface actuelle ne permet pas de choisir un id numérique a priori lors de la création de l'article, mais ça n'est qu'un choix d'interface.
Il est très embêtant que l'on mélange des choix d'interface et du fonctionnel pur, alors que c'était un des but de la refonte.
Par ailleurs, je ne reproduis pas le cas que tu évoques dans ecrire/ : le rédacteur qui essaye d'accéder en modification à un article pour lequel il n'est pas autorisé reçoit un message "Il n'y a pas d'article à cette adresse".
Enfin, en relisant la fonction inc_article_select, je vois que celle-ci fais effectivement un appel initial à autoriser('modifier','article'), et je pense que c'est là qu'est l'incohérence, car cette fonction de sélection n'a pas a s'occuper des droits qui doivent être vérifiés en amont de l'affichage même du formulaire. Dans les autres cas, pour lesquel aucune fonction select n'existe, c'est comme cela que cela se passe.
Ce n'est donc pas effectivement pas cohérent en l'état actuel, mais pas de la manière que tu sous entend.
Cédric