Ajout d'envoi des mails par domaine + invitations ICS - #585
Ajout d'envoi des mails par domaine + invitations ICS#585DidierSardine wants to merge 64 commits into
Conversation
- Upgrading symfony/cache (v6.4.40 => v6.4.41) - Upgrading symfony/framework-bundle (v6.4.39 => v6.4.41) - Upgrading symfony/http-foundation (v6.4.35 => v6.4.41) - Upgrading symfony/http-kernel (v6.4.40 => v6.4.41) - Upgrading symfony/polyfill-intl-grapheme (v1.37.0 => v1.38.1) - Upgrading symfony/polyfill-intl-icu (v1.37.0 => v1.38.0) - Upgrading symfony/polyfill-intl-normalizer (v1.37.0 => v1.38.0) - Upgrading symfony/polyfill-mbstring (v1.37.0 => v1.38.1) - Upgrading symfony/polyfill-php83 (v1.37.0 => v1.38.1) - Upgrading symfony/routing (v6.4.40 => v6.4.41) - Upgrading twig/twig (v3.26.0 => v3.27.1)
Problème suite à la mise en place du drag and drop.
- Upgrading symfony/polyfill-mbstring (v1.38.1 => v1.38.2) - Upgrading symfony/polyfill-php83 (v1.38.1 => v1.38.2) - Update PDF Make : 0.18.0 => 0.19.1
Pouvant bloquer requête depuis modification grr_sql_query
- Upgrading symfony/cache (v6.4.41 => v6.4.42) - Upgrading symfony/cache-contracts (v3.7.0 => v3.7.1) - Upgrading symfony/config (v6.4.37 => v6.4.42) - Upgrading symfony/dependency-injection (v6.4.38 => v6.4.42) - Upgrading symfony/deprecation-contracts (v3.7.0 => v3.7.1) - Upgrading symfony/event-dispatcher-contracts (v3.7.0 => v3.7.1) - Upgrading symfony/finder (v6.4.34 => v6.4.42) - Upgrading symfony/form (v6.4.36 => v6.4.42) - Upgrading symfony/framework-bundle (v6.4.41 => v6.4.42) - Upgrading symfony/http-foundation (v6.4.41 => v6.4.42) - Upgrading symfony/http-kernel (v6.4.41 => v6.4.42) - Upgrading symfony/service-contracts (v3.7.0 => v3.7.1) - Upgrading symfony/translation (v6.4.38 => v6.4.42) - Upgrading symfony/translation-contracts (v3.7.0 => v3.7.1) - Upgrading symfony/var-dumper (v6.4.36 => v6.4.42) - Upgrading symfony/var-exporter (v6.4.37 => v6.4.42)
|
Bonjour, J'ai une question, lors de la modification de la périodicité d'une réservation ou de la réservation elle même, celle-ci change d'ID, l'ID de périodicité aussi est susceptible de changer, afin de traquer l'ID original de la réservation (pour recalculer l'UID du calendrier) je pensais ajouter une colonne "old_id" dans la table *_entry pour pouvoir retracer la réservation d'origine et retrouver le bon ID pour recalculer l'UID du calendrier. Le problème c'est que le protocole iCal utilise la méthode REQUEST pour créer et modifier, donc si l'ID du calendrier change, alors REQUEST ne retrouvera pas le calendrier existant et va en créer un nouveau, ce qui va donc dupliquer tout les événements de la résa. Ça va aussi poser problème lors de la suppression, donc ce champ permettrait de retrouver le bon calendrier à supprimer. Si vous avez des idées, je suis à votre écoute. |
| 'rep_end_day' => 'int', | ||
| 'rep_end_month' => 'int', | ||
| 'rep_end_year' => 'int', | ||
| 'rep_id' => 'int', |
There was a problem hiding this comment.
Bonjour,
ce n'est pas la seule...
on peut faire le même constat avec la gestion des variables temporelles.
C'est l'héritage des anciennes versions de GRR.
Cordialement,
YN
There was a problem hiding this comment.
À propos des modifications, êtes-vous sûr que l'id de la réservation est modifié ?
Il me semble que les modifications apportées dans la version 4 vs les versions 3 conservaient l'id de la réservation tout au long des modifications. Si ce n'est pas le cas dans les périodicités, il y a peut-être à faire sur cette table-là.
There was a problem hiding this comment.
Sur les deux images c'est la même résa, avec quelques modifications effectuées, en effet il semblerait que modifier la résa elle même ne change pas son ID, mais toucher a la périodicité si, la résa voit son champ "supprimer" passer à 1 et une nouvelle entrée est créée dans la table *_entry. Je peux m'occuper aussi d'essayer de changer le comportement de la modification de la périodicité d'une résa pour qu'elle applique les changements sur la même entrée plutôt que d'en recréer une si ce n'est pas un comportement nécessaire.
Modif Description / Desc Brève -> Pas de changement d'ID
Modif horaire / jour -> Pas de changement d'ID
Modif de valeur dans un overload -> Pas de changement d'ID
Changement de beneficiaire -> Pas de changement d'ID
Changement dans la périodicité -> Changement d'ID
There was a problem hiding this comment.
Effectivement, ce n'est pas très cohérent.
D'après ce que vous disiez dans les messages précédents, il vaudrait mieux ne pas changer l'id lorsque la périodicité est modifiée, si j'ai bien compris.
À propos, je serais curieux de voir comment mrbs gère cette question - il y a là un export ICS depuis plusieurs versions.
v3.27.1 => v3.28.0
|
Bonjour, J'ai bien avancé et j'ai une version fonctionnelle de mon code. J'ai ajouté le support des périodicité et les réservations périodiques peuvent être créées modifiées et supprimée et l'iCal généré suivra et s'enverra comme ICS par mail pour mettre à jour le calendrier de la boîte mail. Les deux seuls problèmes qu'il reste c'est le passage de réservations périodiques vers unique (suppression que de certaines instances / toutes pour n'en garder qu'une) - celui-ci supprime entièrement la résa du calendrier mail - ainsi que le passage de réservation unique vers périodique (ajout d'une périodicité sur une résa existante), faire cette action ajoutera la série de résas périodiques au calendrier mail sans remplacer la résa unique originale, donc la première résa sera dupliquée. J'accordais de mon temps de travail pour ce projet mais je dois travailler sur autre chose aussi, alors je ne vais sûrement pas corriger ces problèmes sans avoir la garantie que cette fonctionnalité soit ajoutée dans la repo principale, je compte sur vous pour prendre le flambeau et peaufiner la feature, ou sinon tenez moi au courant, je reste joignable et je viendrais régulièrement voir l'était de la PR. Bonne journée à vous ! |
|
Bonjour, Les invitations ICS seraient une fonctionnalité très utile. Bien cordialement, |
|
Bonjour, |
6 participants
Dans cette PR, j'ai ajouté la possibilité de définir par domaines l'envoi de mails automatiques en conservant le paramètre global.
J'ai surtout ajouté la possibilité (activable ou non par domaine) de générer et envoyer une invitation (iCal RFC 2445, compatible avec multitude de clients mails) automatiquement avec le mail, permettant aux utilisateurs réservant leur ressource de la voir sur leur agenda mail personnel.
J'ai également développé les comportement de modification de réservation et suppression ce qui permet de suivre les réservations directement dans son client mail, avec l'ICal du mail qui met à jour l'agenda automatiquement.
Surtout n'hésitez pas à me faire des remarques, modifier, améliorer et adapter le code au style de code de GRR car j'ai fait de mon maximum pour avoir quelque chose qui convienne et fonctionne.
FEATURES:
TODO:
Screenshots