Release Note de la version 99 de LpBackEnd

Perso des checklist

1

Evolution

Perso des checklist

STEP 1 - Modification du nom de la catégorie de checklist

Je réalise mes tests sur l'environnement GYZMO_DEV et sur la base AlocproGyzmo_dev.

Mon jeu de données est le suivant, avec quelques explications utiles associés:
-- PERSO DES CHECKLISTS (MODIFICATION DE NOM DE CATEGORIE DE CHECKLIST) --

-- On part du parc (parc = relativekey du body POST d'inspection)
-- Possible aussi de partir du mouvement directement en fonction de "field" dans le body POST d'inspection ("F090KY" ou "F570KY")
select F090KY, K090060MOD from F090PARC where F090KY = 'PIM'

-- On récupère le modèle de notre parc dans la F060MOD (K090060MOD), puis le type de modèle dans la FTB1MOD (K060061MOD)
-- Le type de modèle determinera la liste des checklists associés au modèle ainsi que ces faces
select F090KY, K090060MOD, K061TB1ETAT from F090PARC
JOIN F060MOD ON F060KY = K090060MOD
JOIN F061MODINF ON F061KY = K060061MOD
where F090KY = 'PIM'

-- Avec l'appel POST /inspection-group-categories , il est possible de créer une catégorie (FTA3DEGAT), lié a une catégorie existante (ACCESS par exemple), pour la renommer
-- de ce fait, on personnalise un nouveau nom de catégorie pour une société donnée (body exemple ci-dessous)

-- "wording": "Accessoires PIM", --> Le nouveau nom souhaité pour la categorie
    -- "hidden": true, --> La possibilité de masquer cette catégorie
    -- "company": {
    --    "id": "GYZMO" --> la société qui personnalise
    --},
    --"internalLink": "ACCESS" --> Correspond au lien avec le FTA3DEGAT existant

-- On a le type de modèle, on peut donc récupérer ses Checklists associés (FTA3KY  lié a notre FTB1KY)
-- On filtre uniquement sur les CHECKLIST, pour éviter d'avoir les FACES associé au modèle (filtre sur FTA3FILTRE2)
-- Ensuite, on sait que si la société (KTA3001SOC) est renseigné avec la société courrante, c'est qu'il existe une personnalisation pour cette société là.
SELECT DISTINCT FTA3KY, KTA3TA3LIEN, KTA3001SOC, FTB1KY, FTA3FILTRE2
FROM FTA3DEGAT
JOIN FTK2ZONENOMENC ON FTA3KY = KTK2TA3OBJET
JOIN FTB1MOD ON FTB1KY = KTK2TB1MOD
WHERE FTB1KY = 'REM'
AND FTA3FILTRE2 = 'CHECKLIST'
AND KTA3001SOC = 'GYZMO'

-- Test et reset jeu de données inspection:
select * from F575ETAT where K575090UNI = 'PIM'

delete F575ETAT where R575ETAT = ''

Test:

Lorsque je crée mon inspection avec mon parc PIM, ma perso est bien prise en compte sur mes lignes dupliquées:
Image

Mes 15 lignes de bases:
Image

Mes 15 lignes dupliqués de mes 15 lignes de base avec ACCESSOIRES qui devient ACCESS:
Image

La perso a été prise en compte car ici:
Image
J'ai bien une donnée pour la société GYZMO (qui correspond à la company de ma session sur laquelle je réalise ce test), donc on prend cette valeur. 

Si je réalise un appel avec une autre société que GYZMO dans ma session. Pour se faire donc, je fais un login avec un autre utilisateur d'une autre company et je change le token pour mon test:

Je change de login :
Image

Puis je refais mon post inspection avec ce token (même body, je change juste le token):
Image

On voit bien alors que mes lignes dupliqué n'ont pas pris la personnalisation, car ce n'est pas la bonne company, on ne prend donc pas en compte la personnalisation et on garde le standard :
Image

Attention changement après coups: on ne filtre plus par le modèle, une catégorie modifié sera modifié pour tous les modèles à qui elle est liée.