@VincentAntoine Merci pour l'analyse !

+1 pour l'option 1 (recalcul des sommes/nombre de pièces pour le colonne BFT).

A passer en prod après correction du front

WITH bft_reports AS (
    SELECT DISTINCT report_id
    FROM manual_prior_notifications, jsonb_array_elements(value->'catchOnboard') catch
    WHERE catch->>'species' IN ('BF1', 'BF2', 'BF3')
),

summed_bft_data AS (
    SELECT
        report_id,
        SUM(CASE WHEN catch->>'species' IN ('BF1', 'BF2', 'BF3') THEN (catch->>'nbFish')::DOUBLE PRECISION ELSE 0 END) OVER report AS nb_bft,
        SUM(CASE WHEN catch->>'species' IN ('BF1', 'BF2', 'BF3') THEN (catch->>'weight')::DOUBLE PRECISION ELSE 0 END) OVER report AS weight_bft,
        catch
    FROM manual_prior_notifications, jsonb_array_elements(value->'catchOnboard') catch
    WHERE
        report_id IN (SELECT report_id FROM bft_reports)
    WINDOW report AS (PARTITION BY report_id)
),

corrected_catches AS (
    SELECT
        report_id,
        CASE
            WHEN catch->>'species' = 'BFT' THEN jsonb_set(
                jsonb_set(
                    catch,
                    '{nbFish}',
                    nb_bft::text::jsonb
                ),
                '{weight}',
                weight_bft::text::jsonb
            )
            ELSE catch
        END AS catch
    FROM summed_bft_data
),

corrected_catches_array AS (
    SELECT
        report_id,
        jsonb_agg(catch) AS catches
    FROM corrected_catches
    GROUP BY report_id
),

corrected_values AS (
    SELECT
        pno.report_id,
        jsonb_set(
            jsonb_set(
                pno.value,
                '{catchToLand}',
                cor.catches
            ),
            '{catchOnboard}',
            cor.catches
        ) AS corrected_value
    FROM manual_prior_notifications pno
    JOIN corrected_catches_array cor
    ON pno.report_id = cor.report_id
)

UPDATE manual_prior_notifications pno
SET value = cor.corrected_value
FROM corrected_values cor
WHERE pno.report_id = cor.report_id

@VincentAntoine merci pour le récap !
L'option 1 me va, si en effet on peut retirer la ligne BFT du pdf du préavis dans le cas où il y a déjà des lignes BF1, BF2, BF3.

Je viens de me rendre compte qu'il est possible dans le formulaire de saisir directement BF1, BF2 ou BF3 en tant qu'espèces plutôt que de saisir BFT puis le détail par calibre à l'intérieur de BFT. Voire, si on fait vraiment n'importe quoi, de saisir BFT avec un détail par calibre ET saisir aussi BF1, BF2 BF3 en tant qu'espère séparée de BFT.
En pratique ça n'a pas l'air d'être le cas, mais le formulaire le permet.

Je crois me souvenir que l'ajout de BF1, BF2, BF3 dans le référentiel espèces a été fait pour permettre de saisir le détail par calibre dans les CR de contrôle. On n'a pas le même système dans les CR de contrôles et dans les préavis, dans les CR de contrôle on peut saisir BF1, BF2, BF3 en tant qu'espèces, ou BFT si on ne veut pas spécifier les infos par calibre (ou les deux si on fait n'importe quoi, ce qui est aussi possible).

Si on regarde les données de contrôle :

WITH bft_controls AS (
    SELECT
        id,
        is_from_poseidon,
        SUM(CASE WHEN species->>'speciesCode' = 'BF1' THEN 1 ELSE 0 END) > 0 AS has_bf1,
        SUM(CASE WHEN species->>'speciesCode' = 'BF2' THEN 1 ELSE 0 END) > 0 AS has_bf2,
        SUM(CASE WHEN species->>'speciesCode' = 'BF3' THEN 1 ELSE 0 END) > 0 AS has_bf3,
        SUM(CASE WHEN species->>'speciesCode' = 'BFT' THEN 1 ELSE 0 END) > 0 AS has_bft
    FROM mission_actions, jsonb_array_elements(species_onboard) species
    WHERE species->>'speciesCode' IN ('BF1', 'BF2', 'BF3', 'BFT')
    GROUP BY 1, 2
)

SELECT
    is_from_poseidon,
    has_bf1,
    has_bf2,
    has_bf3,
    has_bft,
    COUNT(DISTINCT id) AS nb_controls
FROM bft_controls
GROUP BY 1, 2, 3, 4, 5

On voit que la saisie est faite soit par calibre (BF1, BF2, BF3) soit sur BFT au global, à de rares exceptions près sur quelques contrôles issus de Poséidon où il y a à la fois BFT et BF1 / BF2 / BF3.

Mais pour que ce soit clean, l'idéal serait :

• de mettre dans les CR de contrôle le même système que dans les préavis, c'est-à-dire que pour le code BFT la saisie se fasse par calibre puis que BFT soit automatiquement la somme des calibres (à condition que ce soit OK de rendre obligatoire la saisie par calibre pour les contrôles, à checker)
• de supprimer BF1, BF2, BF3 du référentiel espèces, ou en tout cas ne pas les faire remonter vers les formulaires pour que la seule entrée possible pour saisir les infos thon rouge soit BFT, avec détail par calibre à l'intérieur

@VincentAntoine si je lis bien ta capture d'écran, je comprends que la plupart du temps dans MF ils saisissent en BFT et ne détaillent pas par calibre. J'ai donc peur que les obliger à saisir par calibre soit assez contraignant, je ne suis pas sûre qu'ils aient systématiquement l'info – peut-être à vérifier avec eux.
Est-ce que ce serait galère de se dire que soit ils saisissent par BFT et auquel cas les cases BF1/BF2/BF3 se grisent, soit l'inverse : ils saisissent un calibre et auquel cas ne peuvent plus rien saisir dans la case BFT ?

Vu avec l'ops, en effet lors de contrôles de gros navires le détail par calibre n'est pas connu et il faut pouvoir saisir les données en BFT sans détail BF1 / BF2 / BF3. Donc il faut les deux modes de saisie sur les contrôles, contrairement aux préavis manuels où il s'agit forcément de petits navires sur lesquels le détail par calibre est donné.
Donc peut-être qu'on peut se contenter du fonctionnement actuel sur les contrôles et traiter uniquement le problème d'incohérence sur les préavis.

Donc en résumé, si OK pour vous, sur les préavis il faut :

• Faire la modif dans le front pour que les nombres de pièces soient sommés et reportésé dans BFT à partir des infos BF1, BF2, BF3 saisies par l'utilisateur (en plus du poids pour lequel c'est déjà fait)
• Passer la requête ci-dessus en prod pour corriger les incohérences dans les données