Publication des interviews via le BO#2321
Conversation
65694b7 to
8a79077
Compare
| 'signed' => false, | ||
| ]) | ||
| ->addForeignKey('interview_id', 'interview', 'id', ['delete' => 'CASCADE', 'update' => 'NO_ACTION']) | ||
| ->addIndex('speaker_id', ['unique' => true]) |
There was a problem hiding this comment.
Attention, l'unicité porte uniquement sur speaker_id, sans notion d'événement.
Du coup un speaker ne peut être rattaché à une seule interview, alors que la description dit "une personne ne peut être que dans une seule interview par évènement".
Je me trompe peut être mais j'ai l'impression qu'il y a un souci avec le modèle de donnée.
There was a problem hiding this comment.
Ah oui c'est normal ça.
Dans la table des speakers (afup_conferenciers) il y a l'id de l'event (id_forum). Quand une personne est speaker à plusieurs events, il y a plusieurs lignes dans la table des speakers.
Donc pas besoin de refaire un lien vers l'event, on l'a via le speaker.
There was a problem hiding this comment.
Oui je suis d'accord avec toi, pas besoin de refaire le lien mais la contrainte d'unicité n'est pas bonne car uniquement sur la colonne speaker_id.
Si un speaker est interviewé pour un premier event, on ne pourra pas rajouter d'interview pour un évènement suivant.
A priori il faudrait mettre la contrainte d'unicité sur interview_id et speaker_id. Je me trompe ?
There was a problem hiding this comment.
Dans notre modèle de données, un speaker_id ne peut pas être dans plusieurs events.
Si je soumet au CFP du Forum 2025 et au Forum 2026, j'aurais 2 speaker_id différents, un par Forum. Avec à chaque fois les données dupliquées (pour garder l'historique). Et du coup pas de soucis pour avoir une interview par event, vu que j'aurais un speaker_id différent pour chaque event.
Donc un speaker_id ne peut pas, et ne doit pas, être présent plusieurs fois dans la table interview_speaker. Avoir la contrainte sur la pair interview_id/speaker_id aurait le même effet en pratique mais aide moins à la perf quand on cherche une interview par speaker_id.
Est-ce que c'est plus clair ?
8a79077 to
77ab368
Compare
77ab368 to
fc2235e
Compare
|
|
||
| return true; | ||
| } catch (\Exception $e) { | ||
| $this->addFlash('error', 'Erreur WordPress : ' . $e->getMessage()); |
There was a problem hiding this comment.
j'allais dire qu'il y avait peut-être un risque d'envoyer des informations qui ne devraient pas être affichées (secrétaire ou autre) en catchant tout \Exception et renvoyant le message, mais vu le public qui utilisera la fonctionnalité ça ne devrait pas être gênant.
There was a problem hiding this comment.
Hm oui ça me paraissait ok. J'ai rajouté un log pour avoir une trace si besoin de debug plus tard.
| public function buildForm(FormBuilderInterface $builder, array $options): void | ||
| { | ||
| $builder | ||
| ->add('speakers', EntityType::class, [ |
There was a problem hiding this comment.
le sélecteur semble être peu pratique à utiliser. ça serait compliqué de mettre un select2 ou équivalent dessus ? (si c'est trop long ça ne devrait pas être gênant)
There was a problem hiding this comment.
J'avais tenté avec des checkbox mais le template faisait des affichages étranges alors en attendant j'ai mis un select multiple qui s'adapte à la quantité de speakers pour tous les afficher.
Il suffit de faire CTRL + click (ou CMD + click sur mac) pour en choisir plusieurs. Et c'est assez rare les confs à plusieurs non ?
Est-ce qu'avec des checkbox (si je trouve comment corriger) ça te semblerait mieux ?
3 participants
Ce système permet de piloter la publication des interviews depuis le BO pour simplifier cette étape souvent assez chronophage.
Une configuration par évènement est nécessaire
La configuration permet le pont avec WordPress
Création/édition d'une interview
La liste des interviews