Lorsque la base est vide, la création d'un premier créneau bloque la page d'affichage de la page d'un utilisateur

[sebastienbianco]

Bonjour,

Je rencontre un problèmes d'affichage lorsque je réserve le créneau d'une personne sur une base vide.

La stackTrace complete est en PJ
stackTrace.txt

Je vous communique également le dump BDD (ce sont des utilisateurs de tests, mais ils sont branchés sur un keycloak via OIDC).
dump-scopeli_elefan2-202311271832.zip
Ainsi que notre fichier de config :
parameters.offusc.txt

La branche en erreur est la branche OIDC, mais je ne pense pas que cette régression ai été introduit par ce biais.

Bonne fin de journée

Sébastien

[sebastienbianco]

Notez qu'en enlevant les lignes 86 à 103 dans le fichier app\Resources\views\booking\home_booked_shifts.html.twig j'ai pu rétablir l'affichage de ma page.

[sebastienbianco]

Il m'a semblé que dès que je n'ai plus de personne fusionnées dans la base je n'ai plus de problème... (Mais je n'ai pas de problème que sur des personnes fusionnées)

[raphodn]

Salut Sebastien !

Merci d'avoir remonté ce bug, et tous les détails fournis.

J'ai essayé de reproduire en supprimant tous les créneaux dans ma base en local, mais la page d'accueil connecté charge toujours correctement chez moi.

• je n'ai pas testé sur la branche en question par contre (mais sur master)
• tu parles de "réserve le créneau d'une personne sur une base vide". mais du coup dans cette base il y au moins 1 utilisateur, et combien de créneaux ?
• la section qui semble poser problème affiche normalement les créneaux passés du membre, ceux qui ont eu lieu dans les X cycles précédents
• à noter que dans tes paramètres tu as cycle_type: personnal, ce qui veut dire que les cycles sont différents pour chaque membre (car pas abcd), et définis à partir du first_shift_date du membre. si ce membre n'a pas de first_shift_date, alors c'est la date d'aujourd'hui qui sert de base de calcul (cf MembershipService > getStartOfCycle())

[sebastienbianco]

Bonjour Pas de dispo cette semaine pour fournir plus d'éléments. Je tente de vous en donner le 11/12 Bonne fin de journée Sébastien Le ven. 1 déc. 2023 à 22:20, Raphael Odini ***@***.***> a écrit :

…

Salut Sebastien ! Merci d'avoir remonté ce bug, et tous les détails fournis. J'ai essayé de reproduire ne supprimant tous les créneaux dans ma base en local, mais la page d'accueil connecté charge toujours correctement chez moi. - je n'ai pas testé sur la branche en question par contre (mais sur master) - tu parles de "réserve le créneau d'une personne sur une base vide". mais du coup dans cette base il y au moins 1 utilisateur, et combien de créneaux ? — Reply to this email directly, view it on GitHub <#1074 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGHVG6DC4S4UFWT7IX3IBW3YHJC3RAVCNFSM6AAAAABAAD57BWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZWG44TGMJTGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[sebastienbianco]

Bonjour

Je viens de rejouer le test :

• Création d'une base vide
• Ajout de formations/ jobs/commissions/period/period_positions (script dans la PJ)
• Connexion avec un Admin et génération de créneaux sur la base de la semaine type => Dump (en PJ)
• Connexion avec un nouvel utilisateur
• Réservation de 2 créneaux (je reste sur la page de booking après résa créneau 1... Il me semble que ce n'étais pas le cas. Pas très grave mais gênants car notre page de créneau met 10 ans à se charger)
• Retour sur la page Accueil => Bug tel que déjà remonté
• Arrêt de l'onglet Nav Privée et relance d'un nouvel onglet, Connexion => Recoucou le bug.

Test réalisé sur le master avec module OIDC activé.

dumpBDD_etAutres.zip

[sebastienbianco]

Si je remplace le bloc en erreur dans le template twin par

<div class="collapsible-body"> {# Shift history #} <div class="row"> {{ dump(shifts_by_cycle) }} </div> </div>

J'obtiens le résultat suivant :

C'est assez bizarre car il trouve des créneaux dans le passé alors que c'est le premier créneau réalisé.

Comment puis-je faire afficher les requêtes envoyées à la base ?

Bonne fin de journée

[raphodn]

C'est bizarre en effet, surtout que les dates au dessus ne correspondent pas. le cycle a l'air d'aller du 9 janvier au 5 février, alors que les créneaux affichés sont en décembre.. ca a l'air similaire à #963 mais toi tu as une erreur..

Pour le temps de chargement, on a avait le même soucis on a fini par faire une PR pour soulager un peu cette page : #1081

Tu dis que tu as réservé 2 créneaux, c'était le cas aussi dans ton tout premier message ? Et le 2e créneau il a lieu avant ou après le premier ?

Dans tes paramètres je vois "cycle_duration: '7 days'", c'est voulu ? vs '28 days'. c'est peut-être un soucis où l'on ne gère pas ou mal les cas autres que 28 jours..

[sebastienbianco]

C'est vraiment le premier créneau. En effet, j'ai refait un test sur un utilisateur ayant réservé (car la résa se fait malgré le bug d'affichage) et dont les créneaux sont déjà passés et je n'ai plus le message. Par contre je l'ai bien sur un nouvel utilisateur en train de réserver son premier créneau. Je pense plutôt que c'est lié à la concordance de date. Le "dump" me renvoie visiblement les mêmes valeurs dans les cas où ca marche. Le contenu de l'objet doit être une fausse piste.

La valeur du cycle ne change pas la donne. Je viens de tester avec 28j

Pour les perfs, je n'ai pas d'amélioration flagrante. Un dev de chez nous va peut-être tenter de s'y atteler. Je lui proposer de creuser la piste d'une pagination... Moins d'éléments à afficher => Affichage plus rapide :)

[sebastienbianco]

Je dis une bêtise. Dans les cas passant, le cycle "-1" est bien initialisé :

[sebastienbianco]

L'erreur vient de la ligne 281 de ShiftRepository

$startCycleNumber = intval($now->diff($start_after)->format('%r%a') / 28); => Renvoie 0 et pas -1 pour la première réservation du jour
(Y a la durée du cycle en dur ce qui n'est vraiment pas terrible d'ailleurs quand un veut pas un cycle de 28j...

C'est une erreur d'arrondi visiblement qui fou la merde...

Je pense que le plus simple est de protéger l'affichage.

`app\Resources\views\booking\home_booked_shifts.html.twig

         {% for cycle in -1..(-1 * max_nb_of_past_cycles_to_display) %}
                    <div class="col s12 m6 xl4">
                        <h6>Cycle précédent (du {{ membership_service.startOfCycle(member,cycle) | date_short }} au {{ membership_service.endOfCycle(member,cycle) | date_short }})</h6>
                        {% set iscycleexist = cycle in shifts_by_cycle|keys %}
                        {% if iscycleexist  %}
                            {% set previousShifts = shifts_by_cycle[cycle] %}
                            {% if previousShifts | length > 0 %}
                                {% for shift in previousShifts %}
                                    <div class="col s12 m12">
                                        {% include "user/_partial/mini_shift_card.html.twig" with { shift: shift } %}
                                    </div>
                                {% endfor %}
                            {% else %}
                                Pas de créneau
                            {% endif %}
                        {% else %}
                                Pas de créneau    
                        {% endif %}
                    </div>
                {% endfor %}

`

permet visiblement de corriger le problème.

Je ferais une MR d'ici la fin de semaine pour proposer la correction

[raphodn]

Merci d'avoir creusé !
J'ai ré-ouvert une vieille issue - #200 - pour enlever en effet ces "28" en durs dans le code...
Je me pencherais sur ta MR dès que tu la créé 🙏