NPDS : Gestion de contenu et de communauté

(WS16 oeuf corse!) Salut ;-)
Je veux changer l'index de la rubrique modèle pré-existante (le passer de 0 à 9997). Impossible car le contrôle force 3 caractères seulement alors que divers et presse-papier sont sur 4...
ça marchait dans WS13 donc il y a une bonne raison de passer l'index sur 3car. Mais on ne peut plus valider le nouvel ordre des rubriques et, du coup, impossible de créer la moindre rubrique.
Je retourne faire joujou avec mon imprimante 3D...

http://bartok371.free.fr/0/renum_rubriques.jpg

Message édité par : bartok / 18-02-2020 18:19

Message édité par : jpb / 20-02-2020 11:33

probleme deja remonté et on l'a dit que c'etait comme ca maintenant ...

il faut changer tout les index a chaque fois

oui on en a parlé ici https://github.com/npds/npds_dune/issues/392

pour le problème que souleve Bartok y'a effectivement une erreur dans le js du controle on devrait être à 4
et dans le html ( maxlength="3" qui devrait etre à 4) caractères (pour correspondre au valeur maxi de la bd (9999))
donc oui avec le 9999 et le 9998 du presse papier et de divers ca ne colle pas ...

dans admin/sections.php
ligne 1127 remplacer maxlength="3" par maxlength="4"
ligne 1137 remplacer d{1,3} par d{1,4}

Message édité par : jpb / 18-02-2020 19:34

Ok merci.
J'avais envie d'aller taper directement dans la table mais je craignais les effets de bord.

est ce que ca fonctionne mieux ???

Merci pour la piste mais ça bloque toujours.
même si je renomme presse-papier en 999, divers en 998 et modèle en 997.

ça passe seulement pour des valeurs d'index comprises strictement entre 1 et 4 (tiens tiens...) et le contrôle accepte (?) les doublons (divers à 4 et modèle à 4 aussi, par exemple)
Je continue à chercher. :paf

Message édité par : bartok / 19-02-2020 18:01

ah oui je vois on a deux fois ce controle ...l'autre est pour les sous rubriques... il faut aussi faire la même manip

Message édité par : jpb / 19-02-2020 18:21

C'est pas mieux
En analysant la table, il y a quelque part confusion entre rubid et ordre dans un test de validité.
C'est pas bloquant: je crée les rubriques et je vais biner l'ordre directement dans la table rubriques. 8-)

Message édité par : bartok / 20-02-2020 11:56

peux tu me réexpliquer /décrire quel est le problème de fonctionnement dans quel contexte ?

Mes excuses tout d'abord : j'ai créé un post au lieu d'utiliser le post ad'hoc... :D
C'est tout simple: tu crée une nouvelle rubrique et tu modifie l'ordre pour que la nouvelle rubrique aie, par exemple, l'ordre 1000. Et pour des raisons de cohérence dans l'ordre, tu donne à la rubrique existante Modele l'ordre 9997. Le test refuse de valider.
La seule chose qui est acceptée dans mon exemple, c'est:
ordre 1: nouvelle rubrique
ordre 2: modele
ordre 3:divers
ordre 4: presse papier
refusés: ordre=0 et ordre >= 5.
J'ai aussi testé dans un autre contexte (WS16.0.2) sans ajouter de rubrique: les seuls Nos d'ordre acceptés sont 1, 2 et 3 (mais pas 0 ni 4 et plus)
ce qui correspond exactement aux valeurs contenues par rubid dans la table, au moment de la validation du changement d'ordre!
Il suffit de le faire pour s'en rendre compte.

Message édité par : bartok / 20-02-2020 11:53

ok

tu as lu ? https://github.com/npds/npds_dune/issues/392

je vais présenter le problème autrement ou tout du moins poser la question suivante pourquoi les rubriques divers et presse papier doivent toujours être les dernières ??

on peut pour résoudre le problème que tu soulèves en enlevant le controle js de la valeur max (qui correspond au nombre de rubriques ...)

cette implémentation était justement faite pour avoir une cohérence dans le choix des indice de tri (c.a.d si on a 4 rubriques quel est l'interêt de mettre une position à 1000 ) ??

(et si on garde cette implémentation alors oui il faut mettre 2 et 3 au lieu de 9998 et 9999 dans l'archive sql)

donc que faut il faire ?

et non c'est bien mieux de faire un post pour chaque problème :=!

Message édité par : jpb / 20-02-2020 12:57

L’intérêt de mettre un indice de tri haut étant d'anticiper les catégories a venir.

Oui et je n'ai rien compris!

je comprends parfaitement pourquoi et ça ne me pose aucun problème! elles peuvent rester ainsi et c'est pour rester dans cette logique que j'ai tenté de réordonner modeles en 9997...

là, je sens poindre l'incompréhension totale.
je te propose, dans une instal neuve avec, d'origine:
modeles = ordre 0
divers = ordre 9998
presse papier = ordre 9999
de cliquer sur changer l'ordre des rubriques puis de valider sans rien changer. Tu constateras que les 3 zones passent en rouge et qu'il est impossible de valider (alors que ça marchait bien sous WS13, je viens de re-tester). Il n'y a même pas besoin d'ajouter une 4è rubrique pour que ça dysfonctionne.


c'était juste pour l'exemple... mais, souhaitant garder une marge, dans la réalité, j'aurais donné 100 à ma première rubrique, 110 à la deuxième, etc... Qu'est-ce qui m'en empêche? C'est quand même bien plus facile de renuméroter par la suite lorsqu'il y a des intervalles "généreux" que si les numéros d'ordre sont consécutifs, non? (même raisonnement que pour l'index des blocs). Tout en laissant 9998 et 9999 aux rubriques existantes et que l'on doit conserver pour autant qu'il m'en souvienne. J'avais même beaucoup écrit à propos des rubriques il y a quelques années... Je vais aller relire ce que j'avais publié dans la bible.

Pour moi, ce n'est pas nécessaire. Peut-être faire remonter modeles en 9997 car dans cette logique, je ne vois pas pourquoi elle est à zéro. Mais je ne comprends peut-être pas tout... :#

Message édité par : bartok / 20-02-2020 16:36

ça ne m'avait pas échappé.

...là, je sens poindre l'incompréhension totale.
je te propose, dans une instal neuve avec, d'origine:
modeles = ordre 0
divers = ordre 9998
presse papier = ordre 9999
de cliquer sur changer l'ordre des rubriques puis de valider sans rien changer. Tu constateras que les 3 zones passent en rouge et qu'il est impossible de valider (alors que ça marchait bien sous WS13, je viens de retester). Il n'y a même pas besoin d'ajouter une 4è rubrique pour que ça dysfonctionne. ....

OUI (mais si tu met 1 et 2 tu passes ....)

comme tu le soulignes sur une install neuve il ya disfonctionnement ou incohérence
OUI
pour deux raisons situés dans le js de contrôle

la première raison (c'est la limitation des caractères 1 à 3 les premières corrections que je t'ai donné)
et la deuxième c'est le fait que la valeur maxi du controle js est égale à la valeur du nombre de rubrique...

"on peut pour résoudre le problème que tu soulèves en enlevant le controle js de la valeur max (qui correspond au nombre de rubriques ...) " ....

donc sur une install neuve tu ne peux que mettre 1 et 2 ?....

Message édité par : jpb / 20-02-2020 16:47

La valeur 3 passe aussi puisqu'il y a 3 rubriques d'Id 1, 2 et 3 en standard.

Ce contrôle est nouveau et j'imagine qu'il a son utilité, non? Mais dans l'état il bloque le fonctionnement: on valide sans rien changer et ça bloque... pas très friendly user.

On peut mettre 3 aussi puisqu'il y a 3 rubriques en std (comme dit plus haut)
imagine que tu as 50 rubriques numérotées de 1 à 50. si tu veux reclasser la N°50 après la N° 24 il te faudra renommer la 50 en 51, puis la 49 en 50 est ainsi de suite pour enfin repasser la 51 en 25 alors que si tu as des trous entre chaque rubrique, la modif se fait en un seul clic.

Message édité par : jpb / 20-02-2020 16:47