Project

General

Profile

Développement #50560

Évènements récurrents : avoir une page de paramétrage avancé

Added by Valentin Deniaud almost 4 years ago. Updated over 3 years ago.

Status:
Fermé
Priority:
Normal
Category:
-
Target version:
-
Start date:
26 January 2021
Due date:
% Done:

0%

Estimated time:
Patch proposed:
Yes
Planning:
No

Description

Sur la page d'ajout/édition d'un évènement, on trouve un <select> qui permet d'avoir une récurrence prédéfinie, genre tous les jours, une fois toutes les deux semaines...

Mais under the hood on supporte la génération de récurrences arbitraires plus complexes, genre le premier lundi et le troisième vendredi de chaque mois, etc. Il reste le travail d'interface à faire afin de permettre de créer un tel évènement.

S'inspirer de comment c'est fait ailleurs, cf les captures dans #41663.


Files

Associated revisions

Revision 6372afc4 (diff)
Added by Valentin Deniaud over 3 years ago

manager: add more granular control over event recurrence (#50560)

Revision da6055a9 (diff)
Added by Thomas Jund over 3 years ago

manager: add styles for weekdays buttons group (#50560)

History

#2

Updated by Thomas Jund over 3 years ago

  • Status changed from Nouveau to En cours
  • Assignee set to Thomas Jund

Note suite aux échanges avec Valentin hier :

  • Under the hood = on supporte l'intégralité de la spec https://icalendar.org/iCalendar-RFC-5545/3-8-5-3-recurrence-rule.html.
  • l'interface n'a pas pour but de tout exposer, il y a des choix à faire.
    • Par exemple, Les valeurs pour fréquences peuvent être `YEARLY, MONTHLY, WEEKLY, DAILY, HOURLY, MINUTELY, or SECONDLY`
    • mais on ne veut surtout pas permettre HOURLY, MINUTELY etc, pour des raisons techniques, et probablement pas YEARLY, pour des raisons métier.
  • Ne pas proposer la possibilité de taper des récurrences manuellement (par ex syntaxe Rrule via un input avec validateur de syntaxe).
  • Idée d'avoir un feedback utilisateur qui présente la liste des X prochains jours de récurrence choisie : pas possible pour le moment mais envisageable.
  • La récurrence se fait sur la date uniquement, la durée et l'heure de l'événement reste identitque.
    • pas possible de faire tous les samedis à 16h et les dimanches à 15h
    • ce genre de besoin se fera par collage de deux évènements.
  • Options de durée de la récurrence: "repeat forever", "until" et "x times". À voir si "repeat forever" et "X times" est pertinent dans les cas métier.

Voir avec Stef pour faire ressortir les cas d'usage les plus importants à prendre en compte dans l'optique de Publik Famille.

#3

Updated by Thomas Jund over 3 years ago

Notes suite aux échanges avec Steph sur les cas d'usage Publik Famille

  • Récurrences par jours: "tous les jours" et "tous les jours ouvrés" => pertinent
  • Récurrences par semaines : (les lundi et mardi toutes les (x) semaines) => pertinent, proposer toutes les (1, 2 ou 3) semaines.
  • Récurrences mensuelles : (les premiers mercredi et troisième jeudi de tous les (x) mois) => Pas vraiment pertinent. Ce genre d'événement à fréquence faible doit souvent faire également varier d'autres paramètres comme le lieu, la durée, nombre de places, etc. Un système de "copie" d'événement lui paraitrait plus pertinent.
  • Durée de répétition :
    • illimité : les administrations sont très bornées par des calendriers, elles pensent en année scolaire et civile => pas pertinent
    • Jusqu'à X => besoin principal (faut-il rendre ce champ obligatoire ? => Pas d'avis)
    • X fois => Pas de cas d'usage pertinent, surtout si lors du paramétrage l'usager n'a pas de feedback visuel de ses choix (surtout lorsque c'est croisé avec un calendrier d'exclusion comme les vacances scolaires, jours fériés, etc.)

Il ressort donc qu'un paramétrage de récurrence par jours et par semaines (FREQ = WEEKLY || DAILY) satisferait la très grosse majorité des cas d'usage.

#4

Updated by Thomas Jund over 3 years ago

Première proposition :

proposer 2 champs : un champ de sélection de jours, un champ de sélection de Fréquence.
Ça rempli le scope défini avec Steph et Valentin. Merci aux CPFs qui voient des cas d'usages au-delà des possibilités offertes de se manifester.

Le champ de sélection de jours est un champ de checkboxs transformé en groupe de boutons (only CSS). Ce nouveau widget serait à créer, mais pourrait être intéressant pour d'autres formulaires et être exposé pour tout gadjo.
Seuls les liens [ Tous | Jours ouvrés ] demanderaient du JS et ne sont pas obligatoires, sélectionner les 5 ou 7 jours se fait très rapidement (compatible clavier)

J'ai codé en respectant les bonnes pratiques et en utilisant des fieldsets, mais ça demande alors un code CSS assez tordu. L'utilisation des attributs role="group" demanderais moins de contournements.

interface testable et code disponible sur un codepen : https://codepen.io/Sacripant/pen/QWGYpmE

#5

Updated by Valentin Deniaud over 3 years ago

Je trouve ça bien, pour l'anecdote à la base j'imaginais une interface plus compliquée et donc un deuxième formulaire : le premier aurait gardé le champ « Répéter » avec le select des options les plus courantes, et le second cette nouvelle interface, avec un lien « paramétrage avancé » quelque part pour avoir l'un ou l'autre.

Mais en fait pas besoin de ça, notamment grâce au fait que les récurrences mensuelles soient hors scope.

Reste quand même que les évènements récurrents vont rester marginaux, et que les boutons du formulaire pour configurer la récurrence prennent pas mal de places : est-ce qu'on ne pourrait pas avoir ces boutons sous « Répéter » masqués au chargement (si vides), avec un clic nécessaire pour les afficher ?

#6

Updated by Thomas Jund over 3 years ago

C'est la version la plus light en termes de code.

Oui c'est possible de complexifier l'UX du formulaire

Soit avec des champs conditionnels (à mon avis le plus compréhensible pour l'usager) :
  • Ajouter un champ radios "Fréquence" avec choix "unique" ou "récurrent"
  • Si unique (par défaut)
    • champ date et heure
  • Si "Récurrent"
    • Champ date avec label 'date de début de la récurrence'
    • champ 'heure de l'événement'
    • et les autres champs présent dans la capture

Soit comme tu le proposes de faire un fieldset 'foldable' qui ne s'affiche qu'au clic sur la legend. Cette solution est moins claire mais sur une interface BO, ça ne devrait pas poser de problème.

S'il n'y a pas de champs conditionnels, comment comptes-tu détecter s'il y a récurrence ou pas au traitement du formulaire ?

#7

Updated by Valentin Deniaud over 3 years ago

OK pour le champ conditionnel si ça te paraît mieux.

Thomas Jund a écrit :

S'il n'y a pas de champs conditionnels, comment comptes-tu détecter s'il y a récurrence ou pas au traitement du formulaire ?

Comme c'est fait actuellement, rempli -> récurrent, pas rempli -> pas récurrent (à moitié rempli -> erreur). Avoir ce champ conditionnel permettrait de « vider » en un clic, mais l'usage « transformer un évènement récurrent en évènement normal » n'existe pas je pense.

#8

Updated by Thomas Jund over 3 years ago

mais l'usage « transformer un évènement récurrent en évènement normal » n'existe pas je pense.

Ça veut dire que ce champ conditionnel devra être visible à la création d'un événement et hidden lors de sa modification ?

#9

Updated by Valentin Deniaud over 3 years ago

Thomas Jund a écrit :

mais l'usage « transformer un évènement récurrent en évènement normal » n'existe pas je pense.

Ça veut dire que ce champ conditionnel devra être visible à la création d'un événement et hidden lors de sa modification ?

Non non c'est juste lié au morceau de phrase qui précède, à lire comme « il y a cet avantage mais en fait pas très utile ».

#10

Updated by Valentin Deniaud over 3 years ago

Autre remarque qui me vient, pour le moment l'interface permet de sélectionner un début genre mercredi 17/03, et choisir lundi dans le champ « Jour de l'évènement », ce qui je pense devrait être interdit. Peut-être un bout de JS qui sélectionne le bon jour de la semaine une fois choisie la date, et empêche de le désélectionner ?

#11

Updated by Thomas Jund over 3 years ago

v2

à tester ici https://codepen.io/Sacripant/pen/MWbdeZL

Commentaires

  • Je suis parti sur un champ radio group conditionnel, ce qui devrait te faciliter l’interprétation du formulaire côté back. Si event unique alors prendre "date + heure", si event récurrent alors prendre en compte, "Jours de l'événement", "répéter", "date début", "date fin", "heure".
    • Le JS est écrit de façon à être générique pour pouvoir être utilisé par d'autres formulaires, pour le moment il ne prend en compte que les conditions sur des radio group mais est extensible.
  • J'ai remplacé les fieldsets par des divs avec attribut `role='group'`, plus simple à styler.
    • Pour le moment publik n'a rien (en tout cas rien trouvé, ni coté WCS ni autre) pour faire des groupes de champs dans les formulaires, j'ai l'impression d'introduire le truc.
  • Le formulaire est en mode paragraphe (Form.as_p ?), sémantique valable (quoi que) pour les formulaires très simple. Comme on commence à compliquer le truc, ça montre ses limites. N'hésite pas à me faire des retours sur ce qu'il est possible de faire côté markup et si tu rencontres des problèmes.
    • Par exemple, je n'ai aucune idée du markup que retourne django dans les cas d'un radiogroup avec cette option, j'ai fait au pif (j'ai déjà croisé un ul > li dans un p sur un formulaire authentic, le massacre :/ ).
  • J'ai viré les options [tous | jours ouvrés] qui n'apportaient pas grand-chose

Autre remarque qui me vient, pour le moment l'interface permet de sélectionner un début genre mercredi 17/03, et choisir lundi dans le champ « Jour de l'évènement »,

Pour la récurrence j'ai remplacé le champ "date et heure" qui me paraissait aussi confus par "date de début de la récurrence".

#12

Updated by Frédéric Péters over 3 years ago

as_p

Il faut remplacer ça par |with_template et ne surtout pas travailler sur des évolutions du rendu as_p.

#13

Updated by Valentin Deniaud over 3 years ago

Thomas Jund a écrit :

  • Le formulaire est en mode paragraphe (Form.as_p ?), sémantique valable (quoi que) pour les formulaires très simple. Comme on commence à compliquer le truc, ça montre ses limites. N'hésite pas à me faire des retours sur ce qu'il est possible de faire côté markup et si tu rencontres des problèmes.

Je pense que Django ne pourra pas générer tout seul un formulaire aussi complexe et qu'il faudra taper pas mal de html à la main (donc en remplaçant |with_template par du code explicite). Mais plus le markup est simple mieux ce sera.

  • Par exemple, je n'ai aucune idée du markup que retourne django dans les cas d'un radiogroup avec cette option, j'ai fait au pif (j'ai déjà croisé un ul > li dans un p sur un formulaire authentic, le massacre :/ ).

Il n'y a rien pour faire ça, pas de notion de groupe de champs dans Django, le formulaire devait être tapé à la main.

Autre remarque qui me vient, pour le moment l'interface permet de sélectionner un début genre mercredi 17/03, et choisir lundi dans le champ « Jour de l'évènement »,

Pour la récurrence j'ai remplacé le champ "date et heure" qui me paraissait aussi confus par "date de début de la récurrence".

OK mais ça ne répond pas à ma remarque, qui est je pense le seul point bloquant qui reste : ne pas pouvoir sélectionner un jour incohérent avec la date de début choisie.


Side note, l'idée du champ conditionnel semble d'autant plus pertinente à la lecture de #52276#note-6.

#14

Updated by Thomas Jund over 3 years ago

Il n'y a rien pour faire ça, pas de notion de groupe de champs

Je parle de radiogroup (liste de boutons radio ou checkbox, c'est un groupe de champs par essence:


◯ Madame
◉ Monsieur

C'est un groupe dans le sens où il a besoin d'une legend/titre et est composé de plusieurs labels et inputs.
Dans les bonnes pratiques d'accessibilité, ce groupe devrait même être un fieldset
Ma remarque était que je ne savais pas quel markup django pouvait retourner pour le champs

Fréquence de l'événement :
◯ unique
◉ récurrent

Et que j'avais fait au pif.

Je pense que Django ne pourra pas générer tout seul un formulaire aussi complexe et qu'il faudra taper pas mal de html à la main

Dans tous les cas, n'hésite pas à me dire si le code proposé est mal adapté, je suis tout à fait ouvert à modifier le code pour faire au plus simple de ton côté.

OK mais ça ne répond pas à ma remarque, qui est je pense le seul point bloquant qui reste : ne pas pouvoir sélectionner un jour incohérent avec la date de début choisie.

En théorie, je ne vois rien de bloquant.

Dans le cas où je choisis
  • "date de début de la récurrence : 20 mars 2021"
  • Jours : LUN, JEU.

Le premier jour de l'événement sera le lundi ou le jeudi le plus proche >= à la date de début. soit le 22 mars dans mon exemple.
Un problème en pratique ?

#15

Updated by Valentin Deniaud over 3 years ago

Thomas Jund a écrit :

Je parle de radiogroup (liste de boutons radio ou checkbox, c'est un groupe de champs par essence:
Ma remarque était que je ne savais pas quel markup django pouvait retourner pour le champs

Dac, le markup c'est bien du ul/li, https://docs.djangoproject.com/en/3.1/ref/forms/widgets/#radioselect. Je vais voir si c'est intéressant de laisser Django générer ça, et donc de modifier ton code, ou si faire les choses à la main ne pose pas de difficulté.

Le premier jour de l'événement sera le lundi ou le jeudi le plus proche >= à la date de début. soit le 22 mars dans mon exemple.
Un problème en pratique ?

Techniquement c'est jouable voire automatique, juste que c'est un plus sympa je pense de sélectionner la date et d'avoir le jour qui se sélectionne automatiquement, en tout cas c'est ce que fait Google Agenda et mon appli android tierce. Mais à ce stade il faudrait solliciter des avis de CPF.

#16

Updated by Thomas Jund over 3 years ago

Je vais voir si c'est intéressant de laisser Django générer ça

Dans ce cas, ne surtout pas laisser un wrapper <p>. Non valide HTML d'avoir une balise ul au sein d'un p, le browser l'interprète comme il peut et casse le code.

Techniquement c'est jouable voire automatique, juste que c'est un plus sympa je pense

Ok, donc ce n'est pas bloquant comme tu l'indiquais précédemment. C'est un 'nice to have' :).
Je ne connais pas google agenda, mais le côté 'plus sympa' peut vite être devenir calvaire en termes de quantité de JS (et on est plutôt 'less JS as possible') :

  1. Le champ "date de début" est au-dessus du champ jour.
  2. Je choisis une date et automatiquement le jour correspondant se sélectionne (le champ 'jours' n'avait aucune valeur).

Ce qui amène à répondre au moins à ces 2-3 questions (qui en amènent sûrement d'autres) :

  • Que se passe-t-il si l'usager a décidé de sélectionner les jours avant de choisir la date de début ?
  • Que se passe-t-il si je re-modifie le champ date au niveau des jours (en JS, l'event est `change`, donc à chaque changement de l'input la fonction asssociée se lance, il n'y a pas de `change:first-time-only` ou il faut la coder) ?
  • que se passe-t-il si je désélectionne le jour qui a été automatiquement sélectionné au niveau du champ date ?
#17

Updated by Valentin Deniaud over 3 years ago

Thomas Jund a écrit :

  • Que se passe-t-il si l'usager a décidé de sélectionner les jours avant de choisir la date de début ?

Griser le champ tant que pas de choix de date de début ?

  • Que se passe-t-il si je re-modifie le champ date au niveau des jours (en JS, l'event est `change`, donc à chaque changement de l'input la fonction asssociée se lance, il n'y a pas de `change:first-time-only` ou il faut la coder) ?

Le JS qui coche le jour correspondant à la date doit toujours tourner, sans s'occuper de décocher un jour précédemment sélectionné par contre.

  • que se passe-t-il si je désélectionne le jour qui a été automatiquement sélectionné au niveau du champ date ?

Ce jour doit être verrouillé, impossible de l'enlever. Toujours dans l'idée (peut-être fausse) qu'on ne voudra jamais avoir une date de début un jour de la semaine où on ne veut pas d'évènement, que ça serait un paramétrage symptomatique d'une erreur.


Un autre manière de voir les choses : on paramètre un évènement récurrent qui commence un lundi 22/03 et se répète les mardi. Quel est le comportement attendu ? Ça peut aussi bien être ce qu'on a imaginé jusqu'à présent (commence effectivement mardi 23) que « l'évènement a lieu une première fois lundi 22, et se répétera ensuite les mardis ».

Enfin bref je suis tout à fait pour ne pas avoir de JS donc je ne vais pas plus insister, si un CPF émet son approbation c'est bon pour moi dans tous les cas :)

#18

Updated by Thomas Jund over 3 years ago

« l'évènement a lieu une première fois lundi 22, et se répétera ensuite les mardis ».

Non. Pourquoi ajouter de la confusion ? Une récurrence c'est tous les mardis. Point. Surtout pas d'_exception implicite_ en UI!

Pour moi, le label du champ "date début de la récurrence" ne signifie pas qu'un événement à lieu ce jour-là et ne doit pas fixer un jour pour l'événement (Et c'est bien pour cela que j'ai choisi ce label et que le champ n'est pas en premier, si la date saisie dans ce champ devait être celle du premier événement alors je l'aurais nommé "date du premier événement").
Seul le champ "Jours de l'événement :" (label assez clair aussi je trouve :)) est la référence qui défini les jours de l'événement. Et c'est pourquoi je l'ai positionné en premier champ à remplir.

#19

Updated by Valentin Deniaud over 3 years ago

  • Assignee changed from Thomas Jund to Valentin Deniaud

La proposition d'interface étant passée sur le salon sans soulever de points bloquants, on va partir là dessus, je reprends le ticket pour faire la partie django.

#20

Updated by Valentin Deniaud over 3 years ago

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

as_p

Il faut remplacer ça par |with_template et ne surtout pas travailler sur des évolutions du rendu as_p.

Dans sa proposition Thomas a utilisé des blocs de champs avec des fieldsets, est-ce que ça doit être l'occasion d'introduire cette possibilité dans le |with_template de gadjo ? Si non, il va sûrement falloir revoir la proposition d'interface car ça me paraît trop de code et de complexité pour ce petit bout de formulaire chrono.

#21

Updated by Thomas Jund over 3 years ago

Pour préciser, ma dernière proposition n'utilise pas la balise 'fieldset' dans une div avec un attribut `role="group"`.
Mais la problématique reste certainement la même.

#22

Updated by Frédéric Péters over 3 years ago

J'écrivais :

as_p

Il faut remplacer ça par |with_template et ne surtout pas travailler sur des évolutions du rendu as_p.

Pour expliciter, https://codepen.io/Sacripant/pen/MWbdeZL a de l'HTML qui me semble modifié du rendu actuel, qui part donc du rendu as_p. Ce n'est pas le bon départ. Le bon départ serait le rendu de |with_template.

La base si on veut faire évoluer le rendu des champs est donc là : https://git.entrouvert.org/gadjo.git/tree/gadjo/templates/gadjo/widget.html

Cela étant posé la question sera en effet similaire dans le sens où ce que le widget django devrait fournir c'est le contenu pour le bloc {% block widget-control %}, sans tellement de possibilité d'influencer en amont sur le conteneur. Je serais pour ignorer ici cette partie. (mais si on veut on peut réfléchir à voir ce qu'il faut formaliser sur l'objet field, pour que ça puisse être exploité dans le widget.html).

L'autre question posée c'est le groupement de champs ("jours de l'événement", "heure", "répétition"), ça ne correspond pas à ce qu'on obtient d'un model form, où tous les champs passent au même niveau; le rendu est du coup :

...
* identifiant
* fréquence de l'événement
* date et heure (de l'événement unique)
* jours de l'événement (de l'événement récurrent)
* heure
* répétition
* date de début de la récurrence
* date de fin de la récurrence
* durée
* date de publication
* ...

Sur ce deuxième point, il y aurait pareil à introduire, je ne sais comment, une notion de groupe de champs.

En l'état, je pense qu'on peut quand même avoir la fonctionnalité avec le rendu "linéaire" des champs; sauf si le détour par ces évolutions générales sur les formulaires motive.

#23

Updated by Thomas Jund over 3 years ago

En l'état, je pense qu'on peut quand même avoir la fonctionnalité avec le rendu "linéaire" des champs

Oui, possible.
‎‎en faisant des hide/show sur les champs directement, plus lourd côté DOM, mais possible.
au passage on perd aussi :
  • Le regroupement graphique (là c'était une ligne qui longe les champs regroupés) et plus possible d'ajouter un titre au bloc. Donc moins clair pour l'usagé.
  • toute la sémantique et l'accessibilité.

Il y a peut-être des alternatives pour compenser en partie ? (rien de trouvé en échangeant avec Valentin)

sauf si le détour par ces évolutions générales sur les formulaires motive.

Pour essayer de motiver, moi je vois plein d'avantages à pouvoir faire des groupes de champs.

  • gagner en clarté d'interface, en sémantique, en accessibilité et performance coté JS (faire un hide/show sur un groupe est plus efficace que sur plusieurs widgets)
  • gagner en simplicité (UX) cotée construction des demandes WCS (faire une exception sur un groupe plutôt que de le répéter sur chaque champ)
  • déclarer une position en grille pour un groupe (c'est lorsque les champs font partie d'un même groupe sémantique qu'on les place les uns à côté des autres) et donc pouvoir migrer vers un système de grille plus moderne et moins buggé que la grille float.

Et enfin : proposer des formulaires c'est un peu le cœur de notre métier, c'est un peu triste qu'on soit pas capable de faire des groupes de champs.

#24

Updated by Frédéric Péters over 3 years ago

Tu mélanges sur la fin la conception de démarches et les formulaires django; je pense qu'il ne faut pas mélanger.

#25

Updated by Valentin Deniaud over 3 years ago

Voilà ce que ça donne côté django sans bloc de champs. Les nouveaux champs ne sont pas branchés, genre configurer la récurrence sur un évènement est pour l'instant sans effet.

#26

Updated by Valentin Deniaud over 3 years ago

  • Status changed from Solution proposée to En cours
#27

Updated by Valentin Deniaud over 3 years ago

J'ai branché les champs et fait le bout de JS pour afficher/cacher, il manque juste à intégrer le CSS pour que le widget soit joli.

#28

Updated by Thomas Jund over 3 years ago

  • Assignee changed from Valentin Deniaud to Thomas Jund

Ok, je regarde et reprends la main

#29

Updated by Thomas Jund over 3 years ago

Branch updaté avec les styles et markup pour le weekdays group

Je suis pour passer le template et le CSS de ce buttons group vers Gadjo et ainsi en faire un nouveau widget pour formulaire gadjo.
Ça permettrait déjà niveau CSS d'utiliser la variable $button-color de gadjo.scss
Valentin n'étant pas de cet avis, j'ai posé le CSS dans chrono/style.scss, avec une class specifique `.weekdays-buttons-group` et la couleur en hexa.

côté JS j'ai juste précisé un peu le selecteur de la variable `recurrence_fields` pour éviter que le script ne fasse de hide/show sur les checkboxs du buttons-group

Dernière remarque :
le champ 'Date de fin de la récurrence' devrait être un input de type date (texte actuellement)

#30

Updated by Valentin Deniaud over 3 years ago

  • Assignee changed from Thomas Jund to Valentin Deniaud

Merci !

#31

Updated by Valentin Deniaud over 3 years ago

Voilà c'est relisable. Gros patch mais la moitié c'est du sed dans les tests, le code c'est juste :
  • Remplacement de deux champs pour faire une nouvelle interface
  • Migration des données des anciens vers les nouveaux champs
  • Amélioration nécessaire du code qui affiche les infos de récurrence (« Le mardi toutes les deux semaines »)
#34

Updated by Valentin Deniaud over 3 years ago

(rebasé)

#36

Updated by Emmanuel Cazenave over 3 years ago

Un petit nom explicite pour le fichier de migration plutôt que 0091_auto_20210421_1556 serait sympa.

Il semble y avoir un problème sur la migration :

  • sur main créer un événement récurrent tous les lundis, première occurrence le 14 juin
  • passer sur la branche de ce ticket, mirgate_schemas, l'évènement est maintenant non récurrent avec une occurrence unique le 14 juin.
#37

Updated by Valentin Deniaud over 3 years ago

Emmanuel Cazenave a écrit :

Il semble y avoir un problème sur la migration :

Bien vu, sed trop agressif de ma part lors d'un rebase,

 def migrate_recurrence_fields(apps, schema_editor):
     Event = apps.get_model('agendas', 'Event')

-    for event in Event.objects.filter(recurrence_days__isnull=False):
+    for event in Event.objects.filter(recurrence_rule__isnull=False):

et c'est rétabli (en fait la migration ne faisait rien parce qu'elle regardait le nouveau champs et pas l'ancien).

Renommée également, branche à jour.

#38

Updated by Emmanuel Cazenave over 3 years ago

EventForm et NewEventForm déclarent frequency dans Meta.fields mais le champ frequency est défini directement sur le formulaire pas sur le modèle, donc j'imagine la déclaration dans Meta superflue et ignorée par django.

Un peu la même histoire pour recurrence_days, qui lui existe sur le modèle mais qui est redéclarée explicitement (recurrence_days = forms.TypedMultipleChoiceField) donc j'imagine toujours la déclaration dans Meta superflue.

#39

Updated by Valentin Deniaud over 3 years ago

Les définitions redondantes dans Meta sont là pour imposer l'ordre (sinon frequency par exemple se retrouverait à la toute fin du formulaire).

#40

Updated by Emmanuel Cazenave over 3 years ago

  • Status changed from Solution proposée to Solution validée
#41

Updated by Valentin Deniaud over 3 years ago

  • Status changed from Solution validée to Solution déployée

Also available in: Atom PDF