Conversation
|
🥁 La recette jetable est prête ! 👉 Je veux tester cette PR ! |
9854f7a to
251a901
Compare
0ddf52a to
45cd526
Compare
f5f2321 to
daff556
Compare
daff556 to
95610b2
Compare
francoisfreitag
left a comment
There was a problem hiding this comment.
La synchro est un peu compliquée à cause des défauts de l’API, mais le code est super propre ! 👍
| current_end = new_end | ||
| else: # new_start > current_end | ||
| # new distinct period found: count the current one and switch to the new one | ||
| nb_days += (current_end - current_start).days + 1 |
There was a problem hiding this comment.
J’espère qu’il est bien documenté que la date de fin est inclusive…
There was a problem hiding this comment.
Pas documenté mais ça me semblait évident 😬 .
Et si ce n'est pas le cas, on nous le dira 😇 .
015dbff to
9abceaf
Compare
francoisfreitag
left a comment
There was a problem hiding this comment.
C’est top, les vues donnent vraiment l’impression d’être une transformation bête et méchante des données, la complexité étant déjà gérée dans le mécanisme de sync. Les permissions m’ont l’air OK, et c’est très simple à suivre 💯
| </form> | ||
| </div> | ||
| </div> | ||
| <div class="col-12 col-lg-4"> |
There was a problem hiding this comment.
J’espère que le commentaire de la DDETS sera court…
| name="employee_details", | ||
| ), | ||
| path( | ||
| "list/<int:institution_pk>", |
There was a problem hiding this comment.
Ne faudrait-il pas prévoir de passer l’assessment dans l’URL pour historiser ces données ?
| logger.warning("Error while syncing Label data for assessement=%s", assessment) | ||
| messages.error(request, "Erreur lors de la synchronisation avec Label.") | ||
|
|
||
| match info_type: |
| employees = Employee.objects.filter( | ||
| assessment__company_id__in={org.pk for org in request.organizations}, | ||
| ).select_related("assessment__campaign") | ||
| employee = get_object_or_404(employees, pk=employee_pk) |
There was a problem hiding this comment.
Juste pour confirmer, le même employé ne devrait pas apparaître dans deux assessments différents, parce qu’on devrait recréer un employé à chaque fois ? (cas DDETS)
There was a problem hiding this comment.
Alors un même employé peut apparaître dans plusieurs ImplementationAssessments différents mais cela sera sous la forme de 2 objets Employee différents chacun rattaché à son ImplementationAssessment.
| ): | ||
| membership = InstitutionMembershipFactory(institution__kind=institution_kind) | ||
| user = membership.user | ||
| self.client.force_login(user) |
There was a problem hiding this comment.
Romain m’a fait remarqué qu’on peut passer l’assertion directement dans le parametrize.
| response = client.post(reverse("geiq:label_sync", kwargs={"assessment_pk": assessment.pk})) | ||
| assessment.refresh_from_db() | ||
| assert assessment.last_synced_at is not None | ||
| assertContains(response, "Dernière synchronisation:") |
There was a problem hiding this comment.
Ce serait aussi le cas s’il n’y avait pas eu de dernière synchronisation (le texte serait Dernière synchronisation: -). Peut-être mettre la date ?
francoisfreitag
left a comment
There was a problem hiding this comment.
Gros gros boulot, mais finalement suffisamment digeste pour qu’on suive bien.
Sans connaissance de l’API Label et ses petites facéties, difficile de trouver des cas qui mettront en défaut le code. Mais au moins, je suis plutôt serein sur le fait que les erreurs nous remonteront rapidement, et surtout qu’il sera facile d’intervenir. 🎩
5fe1da8 to
cd8bf65
Compare
eb5d6ee to
524e86f
Compare
524e86f to
9d24cae
Compare
🤔 Pourquoi ?
🍰 Comment ?
💻 Captures d'écran
🚨 À vérifier
🏝️ Comment tester