Fonctionnalité #15949
[Communicabilité] Comportement pour règle de communicabilité non définie
Description
En tant que SA, je veux définir le comportement du système lorsque la règle de communicabilité n'est pas définie, considérer comme librement communicable ou au contraire jamais communicable.
Idem que pour DUA et l'élimination: en absence de règle, un point de configuration définit si on considère l'archive comme éliminiable à tout moment ou au contraire verrouillée.
Historique
#1 Mis à jour par Solange De Malliard il y a environ 3 ans
- Statut changé de A traiter à En cours
#2 Mis à jour par Solange De Malliard il y a environ 3 ans
- Statut changé de En cours à A traiter
#3 Mis à jour par Arnaud PAUGET il y a presque 3 ans
- Version cible changé de 2.8 à 2.8.0
#4 Mis à jour par Cyril VAZQUEZ il y a presque 3 ans
- Version cible changé de 2.8.0 à 2.8
#5 Mis à jour par Jérôme BOUCHER il y a presque 3 ans
- Statut changé de A traiter à R&D - En test
À tester sur branche feat/15949_communication_rule socle et AP
#6 Mis à jour par Alexandre GOLDSTEIN il y a presque 3 ans
fusionné sur develop pour démo du jour
#7 Mis à jour par Emmanuel DILLARD il y a presque 3 ans
- Projet changé de Maarch RM - Product Backlog à Backlog RM
- Version cible changé de 2.8 à 2.8
- Fonction
Communicationsupprimé
#8 Mis à jour par Arnaud PAUGET il y a plus de 2 ans
- Fichier Modif-15949.png Modif-15949.png ajouté
- Statut changé de R&D - En test à A revoir (S)
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)
#9 Mis à jour par Jérôme BOUCHER il y a plus de 2 ans
- Statut changé de A revoir (S) à Complément d'Informations
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 ?
#10 Mis à jour par Cyril VAZQUEZ il y a plus de 2 ans
- Statut changé de Complément d'Informations à Clôturé
#11 Mis à jour par Cyril VAZQUEZ il y a environ 2 ans
- Statut changé de Clôturé à A revoir (S)
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)
#12 Mis à jour par Cyril VAZQUEZ il y a environ 2 ans
- Version cible changé de 2.8 à 2.8.2
#13 Mis à jour par Cyril VAZQUEZ il y a presque 2 ans
- Version cible changé de 2.8.2 à 3.0
#14 Mis à jour par Jérôme BOUCHER il y a 9 mois
- Statut changé de A revoir (S) à Complément d'Informations
- Assigné à mis à Cyril VAZQUEZ
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 ?
#15 Mis à jour par Cyril VAZQUEZ il y a environ un mois
- Version cible changé de 3.0 à 3.X