[DOCUMENT CREATE EDIT] Improve pages input UX

[urien]

Describe the bug Dans un article, il n'est pas possible de déclarer seulement la première page mais il est possible de déclarer uniquement la dernière page (demande du BBS). Quand on édite un document qui n'a qu'une dernière page de déclarée, dans le formulaire permettant l'édition la valeur apparait dans le champ première page, ce qui interdit de poursuivre l'édition, sauf à déplacer la valeur du champ première page vers le champ dernière page.

[Clm-Roig]

Données actuelles et contexte

Actuellement, côté serveur, on stocke une seule valeur pages. Côté client, on manipule startPage et endPage (que je nomme sP et eP ci-dessous) et on construit pages pour le serveur.

L'idée de base était de pouvoir gérer de nombreux cas avec juste ces données :

#	Cas	Exemple	sP & eP	pages
1	Intervalles de pages au sein d'un magazine	article de la page 3 à 6	sP=3, eP=6	pages=3-6
2	Multiples pages entrecoupées au sein d'un magazine	article de 3 à 5, pub sur la 6, puis de nouveau article de 7 à 10	sP=3-5, eP=7-10	pages=3-5,7-10
3	Article sur une page	article page 9	sP=null, eP=9	pages=9
4.1	Nombre de pages	livres de 200 pages	sP=200 eP=null	pages=,200
4.1	Nombre de pages	livres de 200 pages	sP=200 eP=null	pages=200,

J'ai un doute sur le cas 4, je ne sais plus ce qui avait été retenu par le BBS. À noter que certaines données en base de données ne tombent dans aucun des 4 cas (112-119, par exemple, avec la virgule à la fin...)

Questions

• Quel est le bon format pour 4 ?
• Que signifie 112-119, ? Si ça ne signifie rien, un nettoyage côté BD s'impose pour retirer la virgule à la fin.

Évolution

Il serait peut-être judicieux d'améliorer l'interface utilisateur pour lui simplifier la tâche de "construire" l'attribut pages. Ma proposition est la suivante :

• Cas # 1 et 2 : interface actuelle, avec 2 champs mais en ajoutant une explication textuelle quant à la possibilité de saisir des plages au sein de chaque champ (cas 2)
• Cas # 3 : cocher une case "Document présent sur une seule page" et ne voir plus qu'un champ "numéro de la page"
• Cas # 4 : cocher une case "inscrire le nombre de pages" et ne voir plus qu'un champ "nombre de pages"

[urien]

Je ne vois pas à quoi peut correspondre 112-119, > Je propose de retirer la virgule.

Le cas 2 correspond à des données existantes dans le BBS mais que l'on ne peut pas générer actuellement. Je pense que ce n'est pas une priorité que de permettre de faire ce type de saisie

Pour le nombre de pages qui est stocké sous forme ",200" ou "200," est-ce qu'on ne peut pas le stocker sous la forme "200". Au niveau front si on a un seul nombre sans virgule c'est que c'est un nombre de pages. Je pense que l'erreur actuelle est lié à ces deux représentations possibles.

Pour éviter de multiplier les cases à cocher je propose pour le cas 3 d'autoriser sP=eP. Pour gérer le cas 4 on pourrait mettre un bouton ON/OFF "Page début - page fin" / "Nombre de pages" avec "Page début - page fin" par défaut et la possibilité de renseigner SP et eP et un texte correspondant. Si le bouton est sur "Nombre de pages" il n'y aurait qu'une case à compléter et un texte correspondant.

En édition, il faudrait voir comment on gère le passage de l'un à l'autre

[Clm-Roig]

Je suis d'accord avec toi sur les points suivants, je récapitule :

• Nettoyage des données au format "XXX-YYY," avec virgule à la fin
• Concernant le passage de l'un à l'autre, ce n'est pas très dur. La donnée "finale" c'est un attribut pages unique. Selon la case cochée, on construit juste cet attribut d'une manière différente, avec ou sans virgule / tiret 🙂

Par contre sur ce point :

Pour le nombre de pages qui est stocké sous forme ",200" ou "200," est-ce qu'on ne peut pas le stocker sous la forme "200". Au niveau front si on a un seul nombre sans virgule c'est que c'est un nombre de pages.

200 peut soit être le nombre de pages, soit la page 200 du magazine : il faut conserver une écriture pour différencier les deux cas, avec une virgule ou un tiret final par exemple. Pour l'utilisateur, il ne verra jamais cette virgule finale et on ne lui demandera jamais de la taper (trop compliqué).

Au final, on a trois cas et non deux. Il faudra donc bien 3 cases à cocher, avec une case cochée à la fois (par défaut la première) :

• "Page de début - Page de fin" ➡️ formatage classique "XX-YY" (voire "XX-YY, AA-BB": rien n'empêche l'utilisateur de le faire s'il connaît ce format)
• "Page unique au sein d'un autre document" ➡️ un seul champ visible, mais on rajoute une virgule à la fin avant d'envoyer la donnée à l'API "XX,"
• "Nombre de pages" ➡️ un seul champ visible, on envoie tel quel à l'API "XX"

Qu'est-ce que tu en penses ? Je fais fausse route @urien ?

[urien]

Oui, c'est très bien ainsi