Historiquement cet id est un id_rubrique pour l’inscription d’admin restreints
Il ne sert effectivement que très peu, et possible que dans le refactoring de 
l’inscription il y ait eu de la perte au feu et des bugs introduits autour de 
cet id.
Possible aussi que j’avais essayé de le generaliser un peu considérant qu’il 
pouvait être utilisé pour autre chose dans les fonctions surchargées.
Il ne faut pas perdre de vue qu’il peut y avoir des fonctions surchargées 
(test_inscription notamment) dans la nature.

--
Cédric

On 11 févr. 2018 à 16:53 +0100, RastaPopoulos <rastapopou...@spip.org>, wrote:
>
> Le formulaire d'inscription est déclaré comme attendant
> - un mode (en fait un statut uniquement par défaut)
> - un id (un id quoi, on ne le sait pas)
> - un URL de retour
>
> Le deuxième argument est juste noté "id", nom peu judicieux qui
> n'indique rien en soi.
>
> Dans l'ordre d'utilisation :
>
> 1)
> Cet id est passé à la fonction d'autorisation "inscrireauteur", et dans
> les commentaires de cette fonction on apprend "Pour un statut et un
> éventuel id_rubrique donné" : "id" serait en fait un "id_rubrique" !
> Sauf que cette fonction dont on lit pourtant le commentaire n'utilise
> absolument pas cet "id".
>
> 2)
> Deuxième utilisation, dans l'étape verifier(), cet identifiant est passé
> *directement en 4ème argument* à la fonction test_inscription_dist().
> C'est évidemment censé être un entier positif ou nul.
> Sauf que le 4ème argument de test_inscription_dist() est censé être un
> tableau d'options !
> Et là non plus, le fait qu'il y aurait un identifiant d'objet
> (apparemment de rubrique) n'est jamais évoqué ni utilisé à cet endroit.
>
> 3)
> Continuons dans l'incohérence, maintenant dans l'étape traiter(), cet id
> est inséré *à l'intérieur d'un tableau* array('id'=>$id…), pour
> l'envoyer à la fonction action_inscrire_auteur_dist() qui attend
> effectivement un tableau d'options et qui va repasser celui-ci à la
> fonction test_inscription_dist() dont on a parlé au 2). Et donc cette
> fois ci en ayant balancé l'id à l'intérieur d'un bon tableau, et non
> plus directement en 4ème argument comme dans verifier().
>
> 4)
> Le troisième argument d'URL de retour est passé (en changeant son nom
> pour "redirect") dans le tableau d'options de traiter() à
> action_inscrire_auteur_dist(), mais celle-ci ne l'utilise jamais. Et
> elle n'est jamais placé dans le tableau de retour du traiter() et donc
> jamais utilisé par CVT.
>
> Dites, ce serait pas complètement le bordel ?
>
> Mention spéciale pour l'identifiant entier qui est parfois passé en
> entier, parfois passé dans un tableau, à une fonction qui attend
> toujours un tableau…
>
> Instant constructif : m'est-avis que vu que cet identifiant n'est
> apparemment utilisé nulle part, on pourrait d'ors et déjà dire que le
> deuxième argument du formulaire pourrait devenir *toujours* un tableau
> d'options. Et donc on passerait toujours un tableau à test_inscription.
> Et tant qu'à faire, si on utilisait l'arg de retour qu'on propose
> pourtant de fournir ?
>
> À faire au moins en 3.3. Moi je le ferais directement en 3.2 car je
> considère ça comme des bugs.
>
> Vos avis ?
>
> --
> RastaPopoulos
>
> _______________________________________________
> liste: http://listes.rezo.net/mailman/listinfo/spip-dev
> doc: http://www.spip.net/
> dev: http://trac.rezo.net/trac/spip/
> irc://irc.freenode.net/spip
_______________________________________________
liste: http://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip

Répondre à