Travail sur pré-analyse (Création d'une nouvelle et de tests, interactions)

Liste des choses à vérifier

Merci de vérifier is votre Merge Request (MR) satisfait bien aux conditions suivantes (mettre un 'x' pour cocher la case) :

• Le code et les commentaires sont en anglais
• Nous avons ajouté nos noms dans le fichier AUTHORS.md
• Nous avons ajouté quelques mots d'anglais dans le CHANGELOG.md pour résumer notre travail
• Si nous avons utilisé de nouveaux modules python, nous les avons ajouté dans le fichier requirements.txt
• Nous avons effectué quelques tests (et les avons éventuellement ajoutés au dépôt)
• Nous avons ajouté, modifié et revu la documentation, si nécessaire. On peut effectuer une MR sur la page wiki de FlOpEDT, comme expliqué ici : https://stackoverflow.com/a/38537453
• Nous n'avons pas ajouté d'affichage dans les consoles (ni dans celle de django (avec print), ni dans celle du navigateur (avec des console.log))

Nouvelles dépendances

Des dépendances nouvelles ont-elles été ajoutées ?

• Oui
• Non

Si oui, lesquelles ?

Licences

Si de nouvelles dépendances ont été ajoutées, leurs licences sont compatibles avec une inclusion dans un logiciel sous AGPL.

• Tout à fait
• J'ai regardé, mais j'ai un doute. Franchement, les licences, c'est compliqué.
• Non, mais il existe une alternative.

Si non, quelle(s) alternative(s) ?

Type de Merge Request

Merci d'indiquer le type de votre MR (mettre un 'x' pour cocher la case) :

• Réparation de bug
• Fonctionnalité
• Mise à jour de style sur le code (formatage, renommage)
• Refactoring (pas de changement fonctionnel, ni de changement d'API)
• Autre (à décrire) :

Quel est le comportement actuel ?

Quel est le nouveau comportement ?

Est-ce que cette MR casse une autre fonctionnalité ?

• Oui
• Non

Est-ce que cette MR contient de nouvelles migrations de base ?

• Oui
• Non

Informations supplémentaires ?

Introduction

blablabla

Pre-analyse à améliorer

Consider Depencies

• Test 2 dans TTapp/tests/test_pre_analyse_considerant_autres_contraintes/test_slots_constraints.py classe ConsiderDependenciesWithConstraintsTestCase. Ce test renvoie OK (alors qu'il devrait renvoyer KO) parce que :
  • dispo cours 1 = slot le lundi de 14h à 20h
  • dispo cours 2 = slot le lundi de 14h à 20h MAIS c'est le MEME et le seul créneau dispo est à 14h pour les 2 cours donc en pratique, pas moyen de caser les 2. Idée : limiter la durée d'un slot forbidden = False aux durées ou il existe un start time pour ce cours plus la durée pour ce type de cours.

No_Simultaneous_Group_Courses

Cet pré-analyse a plusieurs soucis :

• elle gère bien la structure en profondeur de l'arbre des groupes mais en largeur. Exemple, soit C un groupe transversal de TD1 et TD2, supposons qu'il y ai deux créneaux disponible dans la semaine et que chaque groupe ait un cours dans la semaine. La pré-analyse ne détectera pas l'infaisabilité (on pourrait imaginer traiter le cas des basic_group ET ceux des transversal_group pour remédier à cela)

• Il peut y avoir des infaisabilités non détectés à cause des course_type également. En effet on vérifie dans la pré-analyse le nombre de créneau par course-type mais il peut y avoir plusieurs course_type différents à prendre en compte. Pour gérer cela on vérifie, pour le min des course_type_duration, le nombre de slot dispo, mais il y a surement des opti à trouver.

idée

• ajouter des datas possible dans les partitions, en modifiant add_data dans partition.py afin que les partitions aient plus d'info possible pour expliquer le forbidden ou le available. ( ex rajouter une data de type no_course_group)

chose à modifier

• revoir le try except dans les create_tutor/group_partition et les complete_tutor/group_partition dans partition_with_constraints.py
• le mode d'initialisation de partition (available : true/false)

test à rajouter

• tester les no_course_on_day avec half-day ( seul full_day a été testé)
• tester consider depedencies avec un tutor différent pour les cours 1 et 2