📅 Nouvelle fonctionnalité de calendrier : Date de fin pour les événements récurrents

[j.jaffeux (Joffrey Jaffeux)]

Vous pouvez désormais définir une date de fin pour les événements récurrents dans Discourse Calendar !

Cette fonctionnalité très demandée vous permet de spécifier quand une série d’événements récurrents doit s’arrêter, vous donnant ainsi plus de contrôle sur la planification de vos événements.

Créez des événements qui se répètent quotidiennement, hebdomadairement ou mensuellement - et déterminez maintenant exactement quand ils doivent se terminer.

Pour plus de détails sur le plugin Calendar et ses fonctionnalités, visitez le sujet officiel de Calendar.

À l’avenir, nous pourrions ajouter la possibilité d’exclure des jours de la semaine spécifiques.

[sam (Sam Saffron)]

Une chose délicate avec le mot « Until » est qu’il n’est pas tout à fait évident s’il est inclus ou exclu. Pouvons-nous faire quelque chose ici pour apporter plus de clarté ?

[nathank (Nathan Kershaw)]

Oui, Google Agenda a le même problème ! Ils utilisent On, mais cela souffre de la même ambiguïté :

Cependant, je pense que la plupart des utilisateurs supposeraient sans risque que Until inclut cette date.

[j.jaffeux (Joffrey Jaffeux)]

Jusqu'à (inclus) :

?

edit : J’ai fait ceci pour l’instant UX: better copy by jjaffeux · Pull Request #737 · discourse/discourse-calendar · GitHub semble être un changement simple et bon.

---

Une solution alternative serait d’afficher la date/heure réelle à côté du champ de saisie de la date, mais probablement excessif ?

[meglio (Anton)]

@sam

Une chose délicate avec le mot « Jusqu’à » est qu’il n’est pas totalement évident s’il est inclus ou exclu ? Y a-t-il quelque chose que nous puissions faire ici pour apporter une meilleure clarté ?

Vous pourriez vouloir emprunter quelques idées à mon implémentation des dates de début/fin de bon dans la boîte de dialogue Nouveau bon dans un e-commerce sur lequel je travaille :

---

Un autre exemple pour démontrer la flexibilité et comment nous évitons l’ambiguïté dans les plages de dates dans l’interface utilisateur :

---

Détail technique : Dans notre application, nous enregistrons toujours les dates sous forme de « timestamp avec fuseau horaire » (postgres), de sorte qu’aucun paramètre de base de données, ni aucun paramètre de connexion, ne peut affecter le timestamp réel stocké. Même si Postgres ne le recommande pas, nous le faisons car cela garantit à 100 % la correction de la date dans toutes les situations et dans toutes les requêtes SQL. Vous pouvez manipuler les fuseaux horaires de date directement dans postgres en utilisant leurs fonctions de date/heure/fuseau horaire et être certain que cela fonctionnera toujours à 100 % correctement. Nous nous y fions.

Et ensuite, nous avons un paramètre de fuseau horaire pour tous les types d’entités qui en ont besoin : profils d’utilisateurs, marchés, bons, rapports pour les comptables, etc. - afin que nous puissions traduire n’importe quelles dates dans n’importe quels fuseaux horaires à la volée sans hésitation.

Les principaux points à retenir ici sont :

1. Stockez toujours la date et l’heure avec le fuseau horaire.
2. Stockez toujours la préférence du fuseau horaire.
3. Soyez très explicite sur les dates dans l’interface utilisateur, ne faites pas de magie.
4. Laissez l’utilisateur voir les dates réelles dans le fuseau horaire choisi avant de cliquer sur « Enregistrer ».