Dotclear

Ticket #926 (closed defect: wontfix)

Opened 14 years ago

Last modified 7 years ago

post_status et comment_status sont bloqués

Reported by: JcDenis Owned by: bruno
Priority: normal Milestone:
Component: module:blog Version: 2.1
Severity: normal Keywords:
Cc:

Description

La liste des post_status et comment_status est impossible à modifier dans core->blog cela est très dommageable.

En effet les variables post_status et comment_status sont privées dans la class dcBlog alors que le behavior coreBlogConstruct permettrait d'en ajouter d'autres et de plus les listes sont limitées aux status d'origine dans inc/admin/lib.pager.php, admin/post.php, admin/comment.php (et surement ailleurs)

Je ne connais pas la portée de tels modifications (il y a pas mal de modifications à faire dans toute l'admin) mais il serait bien d'ouvrir ces status. Et je me doute bien qu'il y a une bonne raison que j'ignore.

Une solution de remplacement est un tour de passe-passe avec le post_type sur les billets mais aucune solution viable n'est possible sur les commnentaires.

Change History

comment:1 Changed 14 years ago by JcDenis

Il y a une discussion à ce sujet sur le forum:  http://forum.dotclear.net/viewtopic.php?id=42290

comment:2 Changed 14 years ago by xave

Notes : Il faudrait peut-être prévoir un mécanisme pour ajouter/supprimer des statuts plutôt que de rendre les tableaux publics, ceci afin de protéger les statuts "officiels"

Par ailleurs, il faudrait alors réfléchir aux codes des statuts et à une manière de les rendre uniques, pour que plusieurs plugins ne se marchent pas dessus.

comment:3 Changed 14 years ago by Tomtom33

Protéger les statuts officiels ne pose pas de problème.

Je pencherais pour un type de comportement "premier arrivé, premier servi" au niveau des codes. Si un code est déjà prit, on rejette. (je peux m'en occuper si tu veux Xave)

comment:4 Changed 14 years ago by xave

Donc, mécanisme à prévoir aussi pour que chaque plugin puisse retrouver son propre statut, puisqu'il sera différent d'une installation à l'autre. Ça veut dire que ça doit être intégré dans les procédures d'import-export aussi.

Et "premier arrivé, premier servi", il ne faudrait pas qu'un plugin nouvelle installé soit initialisé avant un plus ancien sous peine de voler le code de statut de son petit camarade... Tu vois ces questions là, avant de te lancer ?

comment:5 Changed 14 years ago by JcDenis

Ben non, je dirais que c'est le plugin qui définie son status: un premier plugin dit qu'il veut un status "100" et un autre plugin un status "500" après premier arrivé = premier servi, si deux plugin veulent un status "100" ben les developpeur se tapent dessus jusqu'a qu'un des deux change... Si on se refaire au post_type (qui est différent je sais) le plugin dit bien je veux le type "pages"...

comment:6 follow-up: ↓ 8 Changed 14 years ago by franck

Ça serait pas plus simple de maintenir une liste à jour, sur une page de la doc officielle par exemple, des "statuts occupés" par le core et par les différents plugins ?

comment:7 Changed 14 years ago by Tomtom33

  • Owner changed from xave to Tomtom33
  • Status changed from new to assigned

Replying to JcDenis:

Ben non, je dirais que c'est le plugin qui définie son status: un premier plugin dit qu'il veut un status "100" et un autre plugin un status "500" après premier arrivé = premier servi, si deux plugin veulent un status "100" ben les developpeur se tapent dessus jusqu'a qu'un des deux change... Si on se refaire au post_type (qui est différent je sais) le plugin dit bien je veux le type "pages"...

Certes seulement ici, le but est de justement ne pas pouvoir changer le code du statut sauf si le plugin en est le owner. Et pour ça, la seule solution et de sauvegarder les couples code/owner dans un setting pour s'en souvenir.

comment:8 in reply to: ↑ 6 Changed 14 years ago by Tomtom33

Replying to franck:

Ça serait pas plus simple de maintenir une liste à jour, sur une page de la doc officielle par exemple, des "statuts occupés" par le core et par les différents plugins ?

Plus simple oui, c'est sur :) Mais ça ne me parait pas viable car comme tout le monde le sait, une doc n'est jamais lu par les dev et ils rechignent toujours à la mettre à jour, moi le premier :P

comment:9 follow-up: ↓ 10 Changed 14 years ago by bruno

Comme discuté sur le forum, si on ne veut pas transformer un post/comment_status en string et non plus en int (qui pose beaucoup moins de souci), on peut passer par une table intermédiaire gérant une association entier<->id de statut.

Charge au plugin de demander à DC quel statut lui a été associé, le plugin n'a pas à gérer ça...

comment:10 in reply to: ↑ 9 Changed 14 years ago by Tomtom33

Replying to bruno:

Comme discuté sur le forum, si on ne veut pas transformer un post/comment_status en string et non plus en int (qui pose beaucoup moins de souci), on peut passer par une table intermédiaire gérant une association entier<->id de statut.

Charge au plugin de demander à DC quel statut lui a été associé, le plugin n'a pas à gérer ça...

C'est pas bête mais je suis pas forcément super fan de rajouter une table à la distribution de base. M'enfin c'est mon avis.

comment:11 Changed 14 years ago by franck

Perso je trouve que coder et maintenir tout ça pour une (petite) liste de statuts est exagéré. Il y a-t-il vraiment beaucoup de plugins qui tapent à la porte pour avoir un statut à eux ?

comment:12 follow-up: ↓ 13 Changed 14 years ago by Moe

Est-il possible de remplacer les nombres de post_status par des chaînes de caractère comme pour post_type ? Si chaque plugin choisit comme post_status son nom, il y aura moins de risques de collision. Par contre, il faut repenser tout le code actuel ...

comment:13 in reply to: ↑ 12 Changed 14 years ago by bruno

Replying to Moe:

Est-il possible de remplacer les nombres de post_status par des chaînes de caractère comme pour post_type ? Si chaque plugin choisit comme post_status son nom, il y aura moins de risques de collision. Par contre, il faut repenser tout le code actuel ...

Pour moi, oui ça a un sens. Il n'y a pas vraiment de justification à gérer le statut comme un nombre, vu qu'il n'y a pas forcément d'ordre dans les statuts. Cela entraînera bien sûr des effets de bord, mais ils me semblent loin d'être surmontables...

comment:14 Changed 14 years ago by Tomtom33

Bon du coup je sais plus trop comment tourner le truc. Faut que je reprenne tout ça au calme.

Au fait Xave, tu aurais peut être une idée à partager?

comment:15 Changed 14 years ago by xave

Qui, moi ? Non, je suis chef, je suis pas là pour réfléchir !

comment:16 Changed 14 years ago by xave

Enfin, pour dire quand même qu'effectivement, il n'est pas question de passer à la légère le tableau en public.

comment:17 Changed 14 years ago by Tomtom33

Un "démerde toi tout seul", ça aurait été plus court.... chef!

comment:18 Changed 14 years ago by xave

Oh ben non, au contraire : il faut qu'on en cause tous ensemble.

comment:19 Changed 14 years ago by xave

  • Milestone 2.2 deleted

Bon, plus j'y réfléchis, et plus je me dis qu'il faut y réfléchir. Du coup, ça ne sera pas pour la 2.2.

comment:20 Changed 13 years ago by bruno

  • Owner changed from Tomtom33 to bruno
  • Status changed from assigned to new

comment:21 Changed 13 years ago by bruno

  • Priority changed from high to normal

comment:22 Changed 13 years ago by bruno

Je pense qu'on va garder ce ticket sous le coude pour le moment, les impacts au niveau du core, et au niveau des plugins est assez important...

comment:23 Changed 13 years ago by bruno

  • Status changed from new to onhold

comment:24 Changed 12 years ago by JcDenis

J'ai bricolé quelques trucs autour du post_status et finalement c'est assez simple de passer son type en "char" sans même de problème de rétrocompatibilité, et sans rendre le tableau publique. Il est juste préférable de passer par dcCore pour faciliter l'ajout de nouveau status, avec une fonction de rétrocompatibilité dans dcBlog. (fait et ça roule)

Par contre, j'ai un peu de mal à voir comment goupiller ça, mais je pense qu'il faut ajouter la gestion des droits par post_status. en effet en l'état on regarde si un utilisateur peut modifier ou publier en article avec "usage,publish,contentadmin", mais si d'autres status comme "en relecture", "poubelle" arrivent qui à le droit de les utiliser ?

comment:25 Changed 11 years ago by franck

  • Milestone set to A definir

comment:26 Changed 7 years ago by franck

  • Status changed from onhold to closed
  • Resolution set to wontfix
  • Milestone A definir deleted
Note: See TracTickets for help on using tickets.

Sites map