C'est certes (un peu) plus lourd, mais ça évite la dépendance à la note (qui n'est pas toujours hyper fiable) et surtout ça évite de checker le linter.
Si le niveau 4 est à 0, il est ignoré (par exemple si l'app ne permet
pas LDPA/SSO). Ainsi, le niveau 4 reste à 0 mais cela n'empêche pas
l'app d'obtenir un niveau plus élevé.
Pas mal de petites modif.
Déjà j'ai pas réécrit tout ton code, je l'ai déplacé avant TEST_RESULTS pour l'appeler au début de la fonction. Ça évite d'appeler la fonction 2 fois, puisqu'il y a 2 appel de TEST_RESULTS.
J'ai modifié le résultat final, ligne 505-513 pour afficher le 1 en gras. Juste pour le mettre en avant. Ainsi que le résultat global.
J'ai ajouté la gestion des tests multiples, puisque que le check process peut comporter plusieurs séries de tests successifs.
Donc un niveau réussi est marqué à 2, pour le dissocier d'un forçage à 1. (C'est pour cette raison aussi que les résultats sont affichés en dur, afficher 1 même si c'est 2).
Le niveau 1 est inchangé, car ces tests doivent toujours être fait.
Le niveau 2 ne comptant que les échec, il ne change pas non plus.
Par contre les suivants sont modifié au niveau du if. Si le niveau est à 2, il a été validé avant, il passe à 0 seulement si les tests échouent.
J'ai testé ça, ça marche bien.
Je pense qu'on peux merger même sans le parsing du check_process (il y a peu de check_process en circulation...)
Merci pour ce boulot scith, ça va vraiment aider!
Ces modifications rajoutent les niveaux:
https://forum.yunohost.org/t/redaction-de-regles-pour-passer-une-app-en-officielle/2256/26
Chaque niveau peut être testé par package_check (option "auto") ou
écrasé (1 ou 0). Les niveaux manuels (4,8,9,10) doivent obligatoirement
être définis (1 ou 0) car ils ne sont pas testables par package_check.
Le script affiche le niveau maximal ainsi que l'état de chaque niveau.
