Développement #56496
Cocher des cases d'un champ liste à choix multiple selon une source de donnée
0%
Description
J'ai #56413, thème inscription multiple à des évènements, où la personne essaye de permettre à l'usager de modifier ses inscriptions en passant par l'action d'édition d'une demande, histoire d'avoir les évènements où l'usager est inscrit déjà cochés dans le formulaire.
On pourrait presque faire la même chose proprement, chrono est capable de renvoyer une indication que l'usager a réservé un créneau (clé booked_for_user à true ou false), mais il faudrait un truc dans wcs pour savoir cocher une case sur la base de cette info.
J'imagine soit un truc de préremplissage (permettre un gabarit genre {{ datasource.booked_for_user }}), soit une clé en dur comme on fait déjà avec 'disabled', qui pourrait simplement être 'enabled'.
(la question ne s'est jamais posée parce que la réservation multiple avait plein de limitations qui sont maintenant levées)
(pour les applis familles ce n'est pas intéressant non plus car on s'oriente vers une gestion via le portail #56027)
Related issues
History
Updated by Frédéric Péters over 3 years ago
Tu écris à propos d'un champ liste mais soyons précis il s'agit d'un champ "liste à choix multiple", correct ?
Ceux-ci ne peuvent pas être préremplis par un gabarit, il y aurait d'abord à se soucier de ça. (#56159).
Updated by Frédéric Péters over 3 years ago
- Related to Développement #56159: permettre de préremplir un champ "liste à choix multiple" avec un gabarit added
Updated by Valentin Deniaud over 3 years ago
Frédéric Péters a écrit :
Tu écris à propos d'un champ liste mais soyons précis il s'agit d'un champ "liste à choix multiple", correct ?
Ouep, mais comme le comportement avec 'disabled' est commun au champ liste simple, je me suis dis que ce ticket pouvait s'appliquer aux deux.
Updated by Frédéric Péters over 3 years ago
Mais il n'y a pas de cases à cocher dans un champ liste. (???) (peut-être que je ne comprends en fait pas du tout l'intention de ce ticket).
Updated by Valentin Deniaud over 3 years ago
- Subject changed from Cocher des cases d'un champ liste selon une source de donnée to Cocher des cases d'un champ liste à choix multiple selon une source de donnée
Frédéric Péters a écrit :
Mais il n'y a pas de cases à cocher dans un champ liste.
Aller les boutons radio c'est presque pareil :)
Dans ma tête l'idée pour un champ liste à choix multiple ce serait cocher une ou plusieurs cases, pour un champ liste de présélectionner un seul choix. L'analogie entre les deux marchent bien avec la résa d'évènements : démarche de résa multiple, tu viens tu coches tes cases, et on peut retrouver ces cases cochées lors d'une seconde démarche. Démarche de résa simple, pareil, avoir déjà sélectionné l'évènement choisi lors de la première démarche dans la seconde. Mais c'est moins utile et il n'y a pas de cas d'usage derrière, oublions ça et limitons aux listes à choix multiple.
Updated by Frédéric Péters over 3 years ago
J'essaie de reprendre pour voir, le besoin ici in fine ce serait d'avoir pour un agenda la liste des id d'événements réservés par l'usager, cette liste serait alors exploitée pour préremplir un champ de sélection d'événements.
On pourrait déjà avoir une liste de ces événement, via l'API (quelle API?), qui peut fonctionner comme une source de données, c'est-à-dire fournir @{"data": [{"id": "...", "text": "..."}]}
Il y aurait alors à pouvoir préremplir une liste à choix multiples non pas via une liste ['id1', 'id2'...]
mais via une liste {"data": [{id": "id1", "text": ...}]}
.
Ça me semble la voie générique.
Mais. Ce que je semble lire aussi c'est qu'on a l'info "réservé pour l'usager en question" déjà combinée à la source de données qui fournit les événements qu'on affiche. Il pourrait alors s'agir de pas tout ça mais juste avoir lors du rendu du champ, si l'attribut booked_for_user est présent, cocher la case, et ne pas toucher au préremplissage. C'est l'approche qui est prise avec Caluire/Axel.
Updated by Valentin Deniaud over 3 years ago
Frédéric Péters a écrit :
Mais. Ce que je semble lire aussi c'est qu'on a l'info "réservé pour l'usager en question" déjà combinée à la source de données qui fournit les événements qu'on affiche.
Yup, ça semble nettement plus naturel que de devoir générer une sous-liste des choix et ça fait gagner un appel ws.