Project

General

Profile

Development #70122

Prendre un RDV en BO directement depuis la vue calendaire de l’agenda

Added by Anaïs Ecuvillon over 1 year ago. Updated 8 months ago.

Status:
Nouveau
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
11 October 2022
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No

Description

Évoqué lors du club pour un dev mutualisé.
https://pad.libre-entreprise.org/p/eo_roadmap23 première évaluation entre 5 à 7K lors de l'EO Camp

techniquement ce serait : clic vers la démarche avec le créneau pré-rempli, mais nécessite d'adapter un formulaire spécifique
Anaïs voit avec Berre à l'origine de la demande (principe = lien cliquable dans chrono qui pointe vers un formulaire saisie BO avec le créneau agenda pré-rempli, donc sur première page, et ensuite remplissage des autres informations nécessaires)

Et clairement non, le besoin va au delà, lors du club, ils (les utilisateurs de Publik) auraient été plusieurs à prendre en exemple Gogole Google Agenda : sélection d'un créneau qui ouvre la résa avec une date de début sélectionnée (et heure de fin aussi donc, on clic au niveau de la date/heure de début et on étire le créneau jusqu’à la date de fin. En relâchant le clic le formulaire pré-rempli apparaît).

Donc après échange avec Berre, le besoin est le suivant :
Quand un agent est sur la vue calendaire d'un agenda de type rdv ou d'un agenda virtuel, il clique sur un créneau disponible, cela ouvre le formulaire qui permet de réserver ce créneau et le pré-remplit.
L'agent remplit les champs demandés, y compris le type de rdv.
Dans un formulaire qui contient plusieurs pages, le créneau pré-rempli peut-être sur une autre page que la première.

Je liste ici ce qui me semble être des pré-requis nécessaires à ce dev et les points sensibles que cela soulèvent :
  • pouvoir passer un paramètre dans l'url qui soit utilisable sur une page xx et non uniquement en page 1 du formulaire (ou autre chose qui réponde au besoin du créneau pré-rempli sur une page x) ;
  • depuis chrono, identifier quel formulaire permet de réserver ce créneau ;
  • pré-réserver le créneau le temps nécessaire à la saisie des autres informations dans le formulaire, pour éviter que plusieurs agents tentent simultanément de réserver un même créneau ;
  • on est plus dans une logique, sélection du type de rdv pour obtenir le créneau, mais sélection d'un créneau (en fait d'une date de début de rdv) puis d'un type de rdv (donc d'une durée)

Files

1695114029.png (25.1 KB) 1695114029.png Valentin Deniaud, 19 September 2023 11:02 AM

Related issues

Related to Publik - Development #71042: Prendre un RDV directement depuis la vue calendaire de l’agendaFermé07 November 2022

Actions

History

#1

Updated by Chloé Girard over 1 year ago

  • Related to Development #71042: Prendre un RDV directement depuis la vue calendaire de l’agenda added
#2

Updated by Anaïs Ecuvillon over 1 year ago

  • Tags set to simplification agenda
#4

Updated by Anaïs Ecuvillon 9 months ago

  • Subject changed from Prendre un RDV directement depuis la vue calendaire de l’agenda to Prendre un RDV en BO directement depuis la vue calendaire de l’agenda
  • Assignee set to Valentin Deniaud

à chiffrer

#5

Updated by Valentin Deniaud 9 months ago

Anaïs Ecuvillon a écrit :

Quand un agent est sur la vue calendaire d'un agenda de type rdv ou d'un agenda virtuel, il clique sur un créneau disponible, cela ouvre le formulaire qui permet de réserver ce créneau et le pré-remplit.

Grosse partie front pour permettre ça, donc.

L'agent remplit les champs demandés, y compris le type de rdv.

À part le type de rdv il reste quels champs à remplir ?

Dans un formulaire qui contient plusieurs pages, le créneau pré-rempli peut-être sur une autre page que la première.

Pour moi le formulaire de prise de rdv doit être retravaillé pour prendre en compte cette fonctionnalité : le champ de sélection du créneau sera conditionné et n'apparaîtra pas, à la place il y aura juste un commentaire « vous être en train de réserver le créneau xxx ».

  • pouvoir passer un paramètre dans l'url qui soit utilisable sur une page xx et non uniquement en page 1 du formulaire (ou autre chose qui réponde au besoin du créneau pré-rempli sur une page x) ;

Pour ça on a les données calculées.

  • depuis chrono, identifier quel formulaire permet de réserver ce créneau ;

Dans les options de l'agenda, « URL de la démarche de réservation » qui pointe vers le formulaire (ça exclut le cas où on aurait plusieurs démarches qui utilisent le même agenda, il faudrait s'assurer que c'est OK niveau cas d'usages).

  • pré-réserver le créneau le temps nécessaire à la saisie des autres informations dans le formulaire, pour éviter que plusieurs agents tentent simultanément de réserver un même créneau ;

C'est donc #17685 et ça sera proposé séparément.

#6

Updated by Anaïs Ecuvillon 9 months ago

Valentin Deniaud a écrit :

À part le type de rdv il reste quels champs à remplir ?

tout dépend du formulaire, chaque formulaire étant différent. Je ne citais que ce champ là car le type de rdv conditionne la durée, et donc normalement la dispo.
En fait, les champs à remplir peuvent tellement conditionner le créneau disponible (dans le cas d'un formulaire utilisant plusieurs agendas par exemple), qu'il faut je pense réduire cette fonctionnalité à un cas d'usage bien précis, très délimité.
Genre, il est possible de prendre rdv côté agenda, si l'agenda est utilisé que dans un seul formulaire, que le formulaire en question n'utilise qu'un seul agenda, et que cet agenda ne compte qu'un type de rdv.
Sans ça, je ne vois pas comment faire.

Pour moi le formulaire de prise de rdv doit être retravaillé pour prendre en compte cette fonctionnalité : le champ de sélection du créneau sera conditionné et n'apparaîtra pas, à la place il y aura juste un commentaire « vous être en train de réserver le créneau xxx ».

oui, on peut faire comme ça sans souci.

Pour ça on a les données calculées.

tout à fait.

Dans les options de l'agenda, « URL de la démarche de réservation » qui pointe vers le formulaire

Cette url n'existe que côté agenda de type évènement, pas côté agenda de type rdv. Et là, on est sur les agendas de type RDV.
Mais il suffirait d'ajouter cette information dans les options. Ce qui débloquerait alors la possibilité de prendre rdv dans la vue calendaire.

(ça exclut le cas où on aurait plusieurs démarches qui utilisent le même agenda, il faudrait s'assurer que c'est OK niveau cas d'usages).

oui, comme je l'indique juste au dessus. Je ne vois pas comment faire autrement.

#7

Updated by Valentin Deniaud 9 months ago

Anaïs Ecuvillon a écrit :

tout dépend du formulaire, chaque formulaire étant différent.

Oups j'ai amené une confusion ici, je ne parlais pas de ça.

Pour moi le type de rdv est choisi dans chrono, sinon on ne peut rien prébloquer.
Donc

Quand un agent est sur la vue calendaire d'un agenda de type rdv ou d'un agenda virtuel, il clique sur un créneau disponible, cela ouvre le formulaire qui permet de réserver ce créneau et le pré-remplit.

j'y lisais qu'on ouvrait une pop-up dans chrono, en saisissant les infos techniques du rdv c'est à dire la date et l'heure préremplies, et le type de rdv.

D'où ma question sur les champs, est-ce qu'il en faut davantage dans cette pop-up ? Pour moi la réponse est oui, il faut le guichet, le nombre de places, et j'en oublie sûrement.

Si je reprends le parcours :
  • Dans la vue calendaire de l'agenda, l'agent clique
  • Cela ouvre une popup, avec les champs :
    • Date/heure préremplis mais éditables, un clic étant forcément imprécis
    • Guichet, prérempli grâce au clic également
    • Le type de rdv souhaité
    • Le nombre de places souhaitées
  • L'agent valide cette pop-up
    • Soit le créneau est dispo (ce qu'on est désormais en mesure de déterminer grâce aux infos saisies), il est est pré-bloqué et l'agent est redirigé vers la démarche
    • Soit le créneau est pas dispo, la pop-up affiche une erreur de validation
Côté démarche, l'adaptation d'un formulaire pour permettre la prise de rdv backoffice c'est :
  • Ajouter sur la première page des données calculées, qu'on alimentera à partir de ce que chrono aura envoyé (date/heure, type, nombre de places)
  • Ajouter une condition pour ne pas afficher la page/les champs où on saisit habituellement créneau/nombre de places
#8

Updated by Anaïs Ecuvillon 9 months ago

Valentin Deniaud a écrit :

Pour moi le type de rdv est choisi dans chrono, sinon on ne peut rien prébloquer.

ok avec ça.

D'où ma question sur les champs, est-ce qu'il en faut davantage dans cette pop-up ? Pour moi la réponse est oui, il faut le guichet, le nombre de places, et j'en oublie sûrement.

je dirais plutôt non :
  • guichet : en FO, choisir un créneau n'offre pas la possibilité de choisir un guichet vs en BO depuis la vue calendaire, on sélectionnera directement un créneau dans une colonne correspondant à un guichet, toutefois, il n'y a pas besoin de redonner cette information dans la popup, ça induirait une possibilité de choix qui n'existe pas côté FO.
  • nombre de places : côté rdv, le nombre de place est géré par le type de rdv. en FO, on demande à l'usager le nombre de place pour choisir un type de rdv vs, en BO depuis la vue calendaire, l'agent n'aura qu'à sélectionner directement le bon type de rdv, ça fait le job.

Donc pour résumer, ok avec une pop-up qui reprend le créneau et le type de rdv.

Si je reprends le parcours :
  • Dans la vue calendaire de l'agenda, l'agent clique
  • Cela ouvre une popup, avec les champs :
    • Date/heure préremplis mais éditables, un clic étant forcément imprécis
    • Guichet, prérempli grâce au clic également
    • Le type de rdv souhaité
    • Le nombre de places souhaitées
  • L'agent valide cette pop-up
    • Soit le créneau est dispo (ce qu'on est désormais en mesure de déterminer grâce aux infos saisies), il est est pré-bloqué et l'agent est redirigé vers la démarche
    • Soit le créneau est pas dispo, la pop-up affiche une erreur de validation
Côté démarche, l'adaptation d'un formulaire pour permettre la prise de rdv backoffice c'est :
  • Ajouter sur la première page des données calculées, qu'on alimentera à partir de ce que chrono aura envoyé (date/heure, type, nombre de places)
  • Ajouter une condition pour ne pas afficher la page/les champs où on saisit habituellement créneau/nombre de places

Dans les grandes lignes, ça me paraît ok.

#9

Updated by Valentin Deniaud 9 months ago

  • Assignee changed from Valentin Deniaud to Thomas Jund

Anaïs Ecuvillon a écrit :

je dirais plutôt non :
  • guichet : en FO, choisir un créneau n'offre pas la possibilité de choisir un guichet vs en BO depuis la vue calendaire, on sélectionnera directement un créneau dans une colonne correspondant à un guichet, toutefois, il n'y a pas besoin de redonner cette information dans la popup, ça induirait une possibilité de choix qui n'existe pas côté FO.

Pas bien compris, le principe est le même que pour avoir la date/heure dans la pop-up, pouvoir ajuster ce qui a été déduit du clic. Mais OK n'en parlons pas dans la proposition, ça relève du détail.

  • nombre de places

Oui tu as raison, micmac avec les agendas évènement dans ma tête, on oublie.

Dans les grandes lignes, ça me paraît ok.

5 jours pour la partie Python.

Thomas, je te passe la balle (comme tu es observateur de ce ticket, mais tu peux faire la passe si tu n'as pas le temps) : est-ce que tu peux chiffrer la partie front du plan ci-dessus, c'est à dire permettre un clic sur les vues calendaires d'un agenda rdv, qui ouvre une pop-up avec l'info date/heure préremplie ? (je m'attends à ce que ce soit plus de travail que la partie Python)

#10

Updated by Thomas Jund 8 months ago

  • Status changed from Nouveau to Information nécessaire
  • Assignee changed from Thomas Jund to Anaïs Ecuvillon

J'ai besoin de plus de précisions pour bien évaluer les possibilités de cette UI.

  • Sur la partie où plusieurs types des RDVs, donc des durées différentes existent, on propose quoi ?
  • Sur quelle vue il est pertinent de l'activer : jour, semaine, mois ?
  • Prendre en compte l'accessibilité, comme la possibilité d'ajouter un nouveau créneau via le clavier (les interfaces full pointeur, c'est pas bien)
  • UI activée par défaut ? et la réponse n'est pas simple si on anticipe une interface tactile (et pas uniquement avec un pointeur).
  • Anticiper les potentiels conflits avec l'UI existante, je pense notement au créneau qui s'agrandissent au survol actuellement.
#11

Updated by Anaïs Ecuvillon 8 months ago

suite à discussion avec Thomas, je me note pour mémo qu'on sort du périmètre la possibilité de prendre rdv dans un agenda virtuel.

+ on ajoute un bouton + pour prendre rdv, ce bouton pré-sélectionne le premier créneau dispo de la vue en cours

#12

Updated by Anaïs Ecuvillon 8 months ago

  • Assignee changed from Anaïs Ecuvillon to Thomas Jund

on a également décidé dans une V1 de mettre de côté la pré-sélection de l'heure selon où on a cliqué, seul le bouton + permet de prendre rdv côté vue calendaire.

#13

Updated by Valentin Deniaud 8 months ago

À force de « restreindre » le périmètre on est arrivé à complètement autre chose en terme de dev.

L'approche initiale est d'avoir la complexité côté front : permettre une sélection précise à la souris.
Ensuite on fera simplement une vérification de la dispo effective au moment de prébloquer le créneau.

Tandis que la nouvelle approche centrée sur un bouton « Ajouter un rdv » et tout saisir dans la popup, c'est côté back qu'il faut savoir générer dynamiquement la liste des créneaux possibles qui seront présentés.
Tout se passera comme si le bout du formulaire wcs qui permet la sélection de créneau était déporté dans cette popup chrono, avec chrono qui appelle donc ses propres API (ce qu'on ne fera pas en pratique, donc il y a des choses à inventer).

Pour moi cette nouvelle approche est globalement plus complexe (mais je suis biaisé), et en plus on perd 90% de l'intérêt du dev, c'est la double peine :)

#14

Updated by Thomas Jund 8 months ago

  • Assignee changed from Thomas Jund to Valentin Deniaud

L'approche initiale est d'avoir la complexité côté front : permettre une sélection précise à la souris.

D'un point du vu usager, avec la vérification après saisie, l'approche initiale est potentiellement assez frustrante : L'usager choisi un créneau et à la fin on lui annonce "désolé, pas possible essaie encore !)
L'idée proposée est d'éviter cette frustration est de proposer, comme le fait WCS, une liste de créneaux OK avec le type de RDV et le guichet choisi. Ne pas réinventer la roue.
Mais j'entends la possible difficulté.

L'autre contrainte est que l'ajout d'un rdv via un bouton est la bonne voie d'un point de vue interface et accessibilité. Cliquer sur le calendrier pour pré-remplir l'heure et la date est un must-have.

Est-ce qu'on pourrait avoir une voix du milieu : ouvrir une pop-up via un bouton, et lancer la vérification le plus rapidement possible et proposer le ou les créneaux possibles en fonction du choix saisi ?
Ou que proposes-tu à partir d'un bouton ?

#15

Updated by Frédéric Péters (de retour le 27 mai) 8 months ago

D'un point du vu usager, avec la vérification après saisie, l'approche initiale est potentiellement assez frustrante : L'usager choisi un créneau et à la fin on lui annonce "désolé, pas possible essaie encore !)
L'idée proposée est d'éviter cette frustration est de proposer, comme le fait WCS, une liste de créneaux OK avec le type de RDV et le guichet choisi.

Si je comprends bien, la différence posée ici c'est que l'agent pourrait être depuis "longtemps" sur la vue de l'agenda, et qu'au moment où il clique à un endroit pour prendre un rendez-vous l'horaire où il clique n'est plus disponible ? Si jamais ça arrive chrono est en mesure d'immédiatement le voir, ça ne serait pas à la toute fin d'un process qu'il y aurait un message "désolé c'était pris".

La popup avec la liste de créneaux le truc que ça fait (si je comprends toujours), c'est qu'en ajoutant une étape on gagne un "refresh" de la liste des créneaux disponibles. Mais pareil dedans le temps que l'agent choisisse, le créneau peut être pris.

(bref je ne vois pas vraiment l'argument posé ici).

#16

Updated by Valentin Deniaud 8 months ago

Thomas Jund a écrit :

D'un point du vu usager, avec la vérification après saisie, l'approche initiale est potentiellement assez frustrante : L'usager choisi un créneau et à la fin on lui annonce "désolé, pas possible essaie encore !)

Tout est dans le « potentiellement », si on arrive à permettre un clic précis, l'agent sélectionnera très rarement un créneau impossible.

Ce clic précis je l'imagine en ayant une grille sur tout le calendrier, la hauteur de chaque case est la même et correspond au pas minimum entre deux créneaux, passer la souris sur une case la fait apparaître, et affiche l'heure de début explicitement.

L'idée proposée est d'éviter cette frustration est de proposer, comme le fait WCS, une liste de créneaux OK avec le type de RDV et le guichet choisi. Ne pas réinventer la roue.

Mais le but du ticket c'est bien d'inventer une nouvelle roue, présenter la même chose que côté démarche je trouve ça plutôt inutile.

L'autre contrainte est que l'ajout d'un rdv via un bouton est la bonne voie d'un point de vue interface et accessibilité. Cliquer sur le calendrier pour pré-remplir l'heure et la date est un must-have.

Je ne remettais pas en question le bouton, simplement si le bouton vient en plus du clic sur le calendrier, on a pas besoin d'avoir une popup aussi chiadée que si c'était la seule voie d'accès à la feature.

#17

Updated by Valentin Deniaud 8 months ago

Frédéric Péters a écrit :

Si je comprends bien, la différence posée ici c'est que l'agent pourrait être depuis "longtemps" sur la vue de l'agenda, et qu'au moment où il clique à un endroit pour prendre un rendez-vous l'horaire où il clique n'est plus disponible ?

Non pour moi le débat porte plutôt sur un agenda avec plusieurs types de rendez-vous, imaginons un de 30 min l'autre d'une heure, l'agent pourra cliquer sur un endroit où il y a 30 minutes de dispo, puis sélectionner un type de rdv d'une durée d'une heure, il se fera jeter à ce moment là.

Ça a peut de chances d'arriver mais sur des cas plus ambigu (15/30/45/60 minutes possibles), j'imagine qu'on imagine que ça puisse davantage poser problème.

#18

Updated by Thomas Jund 8 months ago

Ça a peut de chances d'arriver. j'imagine qu'on imagine que ça puisse…

Je n'ai pas le même point du vu.

Pour que le rejet n'arrive pas il faut :

  • Que l'agent qui ajoute un nouveau Rdv ai en tête la durée de chaque type de rdv. On peut dire que c'est son métier de savoir, même s'il en a 20, qu'il débute, ou que les durées viennent d'être mises à jour par la hiérarchie. Mais l'interface peut l'assister aussi.
  • Rien n'exclut des trucs bizarres avec un type à 25min et un autre à 35min.
  • Que l'agent mémorise l'heure de fin du rdv précédent (indiquée nulle part dans l'interface) et l'heure de début du prochain (et pas indiquée sur la vue mensuelle : besoin d'un survol). L'indication n'est que visuelle.
  • Il faut que la vue soit précise. Sur une vue journalière, on peut se dire que l'agent voit qu'il y a 15mins de libre et pas 10. En vue mensuelle, 1h = 35px, 10min = 6px; 15min = 9px, c'est sport.
  • Rien n'indique combien de temps est disponible entre 2 rdvs.

L'interface que tu proposes via la capture d'écran :

  • Impose un pas : toutes les 15min, toutes les 30, etc. Comment tu détermines le "pas minimum entre deux créneaux" ? Il faudrait un pas de 5 mins ?
  • On limite à la vue journalière uniquement ?
  • "passer la souris sur une case la fait apparaître". On fait du web, on ne peut exclure le fonctionnement sans pointeur (en full tactile et full clavier). Et s'il est possible d'ajuster manuellement l'heure dans la popup, on en revient aux problèmes cités au dessus.

Pour moi, c'est un vrai plus si l'interface peut dire à l'agent : Tu souhaites ajouter un Rdv "Retrait Passeport" (de 15min) le lundi (parce qu'il a cliqué sur le bouton + en vue journalière) en guichet 1 à 7h13 (parce qu'il a cliqué là sur le calendrier), tu peux l'ajouter à 7h, 7h25 ou 7h40. Et pas de rejet.

si le bouton vient en plus du clic sur le calendrier, on a pas besoin d'avoir une popup aussi chiadée que si c'était la seule voie d'accès à la feature

Je n'ai pas compris ce que tu veux dire.

#19

Updated by Frédéric Péters (de retour le 27 mai) 8 months ago

Que l'agent qui ajoute un nouveau Rdv ai en tête la durée de chaque type de rdv.

Pas nécessairement (comme tu dis l'interface peut aider). La sélection de choix du type de rendez-vous peut afficher des infos supplémentaires pour aider, par exemple à côté de chaque type de rendez-vous un rappel de la durée associée, également le temps disponible avant le prochaine rendez-vous/la fin de journée, etc.

Rien n'exclut des trucs bizarres avec un type à 25min et un autre à 35min.

Rien de neuf ici.

Que l'agent mémorise l'heure de fin du rdv précédent (indiquée nulle part dans l'interface) et l'heure de début du prochain

Je ne vois pas pourquoi il aurait à mémoriser ça, j'ai l'impression que je ne comprends pas les parcours de la même façon que toi.

Pour moi, au clic sur la zone mise en évidence par Valentin, qui désigne le début du rendez-vous à poser, il y a popup avec la liste des rendez-vous possibles, avec éventuellement différentes infos supplémentaires cf premier point. L'agent n'a pas à saisir d'horaire.

Il faut que la vue soit précise. Sur une vue journalière, on peut se dire que l'agent voit qu'il y a 15mins de libre et pas 10. En vue mensuelle, 1h = 35px, 10min = 6px; 15min = 9px, c'est sport.

En pratique il me semble qu'on parle surtout de la vue journalière (et/ou hebdomadaire), cf nos usages dans egroupware, on n'utilise pas la vue mensuelle comme vue de travail.

Impose un pas : toutes les 15min, toutes les 30, etc. Comment tu détermines le "pas minimum entre deux créneaux" ? Il faudrait un pas de 5 mins ?

On propose déjà des créneaux en suivant un pas, il n'y a rien de neuf ici.

"passer la souris sur une case la fait apparaître". On fait du web, on ne peut exclure le fonctionnement sans pointeur

Il faut le réfléchir mais on ne peut pas non plus nier que la souris est un dispositif efficace ici, et pouvoir l'exploiter de manière plus fine que "en cliquant sur un bouton".

en guichet 1 à 7h13 (parce qu'il a cliqué là sur le calendrier),

Il me semble qu'il y a des bouts de parcours que je ne comprends pas, la proposition dont tu parles était expliquée à un moment par "on ajoute un bouton + pour prendre rdv, ce bouton pré-sélectionne le premier créneau dispo de la vue en cours" et je ne vois pas là comment ce bout ("7h13 parce que clique dans le calendrier") arrive.

#20

Updated by Thomas Jund 8 months ago

Pour moi, au clic sur la zone mise en évidence par Valentin, qui désigne le début du rendez-vous à poser, il y a popup avec la liste des rendez-vous possibles, avec éventuellement différentes infos supplémentaires cf premier point. L'agent n'a pas à saisir d'horaire.

En lisant ça, j'ai l'impression que c'est proche de mon idée : l'interface retourne une liste de créneaux possibles en fonction du type de rdv, du guichet et de l'heure selectionnée
Et c'est sur ce point que Valentin a des réserves il me semble.

et je ne vois pas là comment ce bout ("7h13 parce que clique dans le calendrier") arrive

C'était pour illustrer un échange avec Anais, où il n'y a pas de "pas" et de bouton au survol : un simple clic ou double clic sur la zone "jaune" du calendrier chrono ouvre la popup d'ajout.

#21

Updated by Valentin Deniaud 8 months ago

Thomas Jund a écrit :

Pour moi, au clic sur la zone mise en évidence par Valentin, qui désigne le début du rendez-vous à poser, il y a popup avec la liste des rendez-vous possibles, avec éventuellement différentes infos supplémentaires cf premier point. L'agent n'a pas à saisir d'horaire.

En lisant ça, j'ai l'impression que c'est proche de mon idée : l'interface retourne une liste de créneaux possibles en fonction du type de rdv, du guichet et de l'heure selectionnée
Et c'est sur ce point que Valentin a des réserves il me semble.

Oui moi je veux bien afficher une liste d'horaires mais qui ne tiendrait pas compte des dispos, parce que ça rajoute une couche de complexité technique qui ne me paraît pas nécessaire (les dispos sont apparentes dans la vue qu'on vient de quitter).

#22

Updated by Valentin Deniaud 8 months ago

Du coup si l'idée de case qui s'affiche au survol est OK, je peux faire 90% du dev seul. Je ferai au mieux pour le bouton « ajouter » en fonction de ce qu'il est possible de faire techniquement.

En mode tablette/sans pointeur on aura qu'à dire qu'on est obligé de passer par ce bouton.

#25

Updated by Valentin Deniaud 8 months ago

  • Status changed from Information nécessaire to Nouveau
  • Assignee changed from Thomas Jund to Valentin Deniaud
#29

Updated by Valentin Deniaud 8 months ago

  • Assignee deleted (Valentin Deniaud)

(je me réassignerai quand ce sera à développer)

Also available in: Atom PDF