Conversation
| "Lookup a Commune object by INSEE code and valid at the given period" | ||
| return ( | ||
| self.filter(code=insee_code, start_date__lte=period) | ||
| .filter(Q(end_date=None) | Q(end_date__gt=period)) |
There was a problem hiding this comment.
À quand l’utilisation de InclusiveDateRange ?
There was a problem hiding this comment.
Un jour. Peut-être. 😁
tests/asp/test_communes.py
Outdated
|
|
||
| result = Commune.objects.by_insee_code_and_period(99999, datetime.datetime(2022, 11, 28)) | ||
| assert new_commune == result | ||
| for period in [new_commune.start_date, datetime.date(2022, 11, 28), timezone.now()]: |
There was a problem hiding this comment.
| for period in [new_commune.start_date, datetime.date(2022, 11, 28), timezone.now()]: | |
| for period in [new_commune.start_date, datetime.date(2022, 11, 28), timezone.localdate()]: |
d4b2993 to
89478a6
Compare
rsebille
left a comment
There was a problem hiding this comment.
@francoisfreitag La correction pour le test en échec au moment de ta relecture est assez velue donc je veux bien un zieutage pour être sûr que c'est compréhensible :).
| "Lookup a Commune object by INSEE code and valid at the given period" | ||
| return ( | ||
| self.filter(code=insee_code, start_date__lte=period) | ||
| .filter(Q(end_date=None) | Q(end_date__gt=period)) |
There was a problem hiding this comment.
Un jour. Peut-être. 😁
|
Je n’étais pas satisfait par ta proposition, je viens de pousser un fixup pour clarifier. Effectivement c’est velu. |
9b0aebe to
e9e2350
Compare
e9e2350 to
36a63b5
Compare
|
Romain, je te laisse merger si ça te convient ? |
|
Ça mériterait peut-être un changelog au final: https://itou-inclusion.slack.com/archives/C01181Y04LT/p1733996418452109 🙈 |
0f24b23 to
645b129
Compare
|
J’ai l’impression qu’on s’est télescopé ? |
Je pense pas, j'ai rien push en tout cas. |
|
C’est moi qui utilisait une remote pas à jour dont la branche master avait déviée. |
| ) | ||
| assert form.is_valid() | ||
|
|
||
| def test_submit_commune_invalid_commune_lookup(self): |
There was a problem hiding this comment.
Ce test avait le même problème et c’est un doublon moins bien intégré de test_accept_updated_birthdate_invalidating_birth_place. => 🗑️
There was a problem hiding this comment.
Je préférerais presque garder celui-ci et virer sa logique de l'autre mais oui 1 seul est suffisant ;).
There was a problem hiding this comment.
Je préfère garder les tests d’intégration, qui couvrent mieux la façon dont les données arrivent au formulaire et limitent le risque de couvrir des cas impossible en réalité. 🤷
code | start_date | end_date -------+------------+------------ 01001 | 1900-01-01 | 1999-12-31 01001 | 2000-01-01 | [NULL]
The content is already verified in the accept views integration, and
getting the data right is tricky:
```
birth_place = (
Commune.objects.filter(
# The birthdate must be >= 1900-01-01, and we’re removing 1 day from start_date.
Q(start_date__gt=datetime.date(1900, 1, 2)),
# Must be a valid choice for the user current birthdate.
Q(start_date__lte=birthdate),
Q(end_date__gte=birthdate) | Q(end_date=None),
)
.exclude(
Exists(
# The same code must not exists at the early_date.
Commune.objects.exclude(pk=OuterRef("pk")).filter(
code=OuterRef("code"),
start_date__lt=OuterRef("start_date"),
)
)
)
.first()
)
```
5a4e6af to
5d85773
Compare
🤔 Pourquoi ?
Test bagottant : https://github.com/gip-inclusion/les-emplois/actions/runs/12235030153/attempts/1
Reproductible avec
pytest --randomly-seed=3864335593 -vv tests/www/employee_record_views/test_create.py::TestCreateEmployeeRecordStep2::test_access_grantedLes valeurs choisies était "1999-12-31" pour la date de naissance alors que la ville était :