Affiche, appro : option pour dépublier diagnostics non-TDés

[hfroot]

closes #3888

les parties de cette PR:

• création d'un nouveau composant DsfrToggle
• refacto tests endpoints publication pour les isoler en: single published canteen; claim canteen; public canteen preview
• ajout du champ redacted_appro_years
• ajout de la logique de badges sur les diagnostics
• ajout d'une separation de diagnostics sur le modèle cantine entre appro et "service"
• ajouter les badges pour une cantine sur plusieurs serializers

rappel des règles fonctionnelles existantes:

• si l'établissement n'a pas les données de l'année n-1 on prend les données les plus recentes qu'on a (n-2, n-3...)
• le diag de la CC prend précedent du diag du satellite (vois hasCentralDiagnosticForMeasure)

règles fonctionnelles créées par cette PR:

• n'importe quel établissement peut décider de cacher les données d'appro pas télédéclarées pour n'importe quelle année
• la décision est fait au niveau de chaque établissement, alors les décisions prises par les satellites et CCs n’impactent pas l'un et l'autre
• si il cache les données d'appro pour l'année n - 1, les données seront caché : sur l'affiche en ligne, sur la carte dans nos cantines, dans les filtres nos cantines, dans le widget qu'il pourrait intégré sur leur site. Le badge appro sera éteint dans ce cas.
• si il cache les données d'appro pour l'année n - 1, les données restent visibles sur l'affiche générable en PDF (à voir si c'est le comportement voulu), et la vérsion édition affiche en ligne

les views a tester sur le front:

• affiche en ligne, modifiable
• affiche en ligne, public
• carte cantine publiée
• widget cantine publiée

les configurations a tester:

• cantine site
• satellite avec CC diag ALL
• satellite avec CC diag APPRO
• satellite avec leur propre diag et un CC diag
• cacher n-1
• cacher n-2
• cacher tous
• cacher, puis TD?

Later:
Complete tests of new badges backend logic. Consider removing applicableDiagnosticRules from the frontend

todo:

• make DSFR toggle component
• remove added field, admin stuff, tests
• add unpublished_years array to canteen model
• define behaviour for satellites with CC appro data
• define behaviour for satellites with CC all data
• define behaviour for satellites with their own diag
• front and backend functionality to support changing redacted appro diagnostic years
• update frontend affiche page to use new appro_diagnostics
• test with satellite with one own diag and one CC diag
• handle published canteen preview (appro badge)
• remove central kitchen diagnostics from published canteen serializer?
• check on appro badge filter behaviour

[alemangui]

(Pas obligatoire)... Je me demande si on pouvait le rendre plus transparent en utilisant max 🤔

@property
def latest_published_year(self):
    if not self.published_appro_diagnostics and not self.published_service_diagnostics:
        return None

    max_appro_year = self.published_appro_diagnostics.only("year").order_by("-year").first().year if self.published_appro_diagnostics else 0
    max_service_year = self.published_service_diagnostics.only("year").order_by("-year").first().year if self.published_service_diagnostics else 0

    return max(max_appro_year, max_service_year)

[alemangui]

À voir après, mais si l'année est différente pour published_appro_diagnostics et latest_published_service_diagnostic, une de ces deux properties retournera None même s'il y a un diagnostic derrière. C'est peut-être voulu ?

Par ex, imaginons que

• self.published_appro_diagnostics.only("year").order_by("-year").first().year est égal à 2024, et
• self.published_service_diagnostics.only("year").order_by("-year").first().year est égal à 2021

Donc, latest_published_year sera égal à 2024.

• latest_published_appro_diagnosticretournera bien un diagnostic, mais
• latest_published_service_diagnostic retournera None, et non pas le dernier diagnostic service de 2021

[hfroot]

Alors je l'ai fait comme ça surtout pour les badges, pour qu'on montre toujours les badges pour la même année. Ça me paraît le plus simple à comprendre, tu penses quoi ? Peut-être c'est un problème du nom de variable plutôt de comportement aussi.

[hfroot]

En vrai, entre ce commentaire et le commentaire perf, peut-être c'est mieux de faire comme tu proposes en premier temps, vu que le cas où les deux sont en décalage est rare.

[alemangui]

Moi ça me va de rester comme tu l'as fait, je voulais juste comprendre si c'était voulu ou non

[hfroot]

en deuxieme temps : p-e au lieu de queryset.exclude(redacted_appro_years__contains=[publication_year]) le exclude pourrait être effectué sur qs_diag comme .exclude(canteen__redacted_appro_years__contains... pour éviter avoir les diagnostics inutils dès le debut. Mais aussi ce query est un peu moche car les cartes pourrait montrer le badge dès une année n-2 etc mais cette logique vérifie que n-1... bof c'est un pb pour une autre PR vu que ce comportement existe déjà