Development #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)
Demandes liées
Historique
Mis à jour par Frédéric Péters il y a plus de 2 ans
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).
Mis à jour par Frédéric Péters il y a plus de 2 ans
- Lié à Development #56159: permettre de préremplir un champ "liste à choix multiple" avec un gabarit ajouté
Mis à jour par Valentin Deniaud il y a plus de 2 ans
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.
Mis à jour par Frédéric Péters il y a plus de 2 ans
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).
Mis à jour par Valentin Deniaud il y a plus de 2 ans
- Sujet changé de Cocher des cases d'un champ liste selon une source de donnée à 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.
Mis à jour par Frédéric Péters il y a plus de 2 ans
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.
Mis à jour par Valentin Deniaud il y a plus de 2 ans
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.