Backlog RM

À tester sur branche feat/15949_communication_rule socle et AP

Sur socle le paramètre n'est pas pris en compte lors de la demande de communication (voir fonction isCommunicable du Controller archiveDeliveryRequest de medona).

Idem sur AP, point de conf non présent dans le fichier configuration.ini.default, et non pris en compte lors de la demande communication (allow ou deny ne change rien).
De plus, la modif du code semble illogique (Voir PJ)

J'ai ajouté le paramètre dans le fichier de conf par défaut sur AP, le comportement est néanmoins OK (Testé avec ccox, sur archives Courrier(s) du jeu de démo).
Le code n'est pas illogique, car les deux valeurs sont 1 ou 2 pour la valeur isCommunicable (c'est historique)

J'ai besoin de plus d'éclaircissements quant au comportement à avoir sur socle. Quel est la modale à afficher quand on a deny et droit d'en connaitre, sachant qu'on passe toujours par le SP ensuite ? Ça ne me parait pas très logique. Si on n'a pas le droit d'en connaitre, il n'y a que le SP et l'archiviste qui ont acces aux archives et aux demandes de comm, du coup ce serait pour quoi ? Faire avec une derogation ?

A revoir

Aujourd'hui le fonctionnement implémenté est le suivant

• utilisé dans archive::getMetadata(), appel à archive::getAccessRule()
• si pas de règle sur archive, fait appel à lecture dans le référentiel des règles avec identifiant=null
• dans le référentiel accessRule, si identifiant nul création d'une règle "fictive" avec P0D ou P999999999Y

A faire:

• ne pas calculer de règle "fictive" mais modifier les tests sur communicabilité (+ d'impact...)
• ajouter aussi une clause dans getAccessRuleAssert() pour résultats de recherche, dans le socle et AP (content)

La règle avait été ajouté dans la lecture d'accessRule afin d'éviter de réaliser un script de migration pour modifier les règles de modification en base de données chez les clients.

Faut-il créer ce script pour la 3.0 ?