Fonctionnalité #15949
open[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.
Files
Updated by Solange De Malliard over 3 years ago
- Status changed from A traiter to En cours
Updated by Solange De Malliard over 3 years ago
- Status changed from En cours to A traiter
Updated by Arnaud PAUGET over 3 years ago
- Target version changed from 2.8 to 2.8.0
Updated by Cyril VAZQUEZ over 3 years ago
- Target version changed from 2.8.0 to 2.8
Updated by Jérôme BOUCHER over 3 years ago
- Status changed from A traiter to R&D - En test
À tester sur branche feat/15949_communication_rule socle et AP
Updated by Alexandre GOLDSTEIN over 3 years ago
fusionné sur develop pour démo du jour
Updated by Emmanuel DILLARD over 3 years ago
- Project changed from 252 to Backlog RM
- Target version changed from 2.8 to 2.8
- Fonction deleted (
Communication)
Updated by Arnaud PAUGET almost 3 years ago
- File Modif-15949.png Modif-15949.png added
- Status changed from R&D - En test to 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)
Updated by Jérôme BOUCHER almost 3 years ago
- Status changed from A revoir (S) to 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 ?
Updated by Cyril VAZQUEZ almost 3 years ago
- Status changed from Complément d'Informations to Clôturé
Updated by Cyril VAZQUEZ almost 3 years ago
- Status changed from Clôturé to 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)
Updated by Cyril VAZQUEZ almost 3 years ago
- Target version changed from 2.8 to 2.8.2
Updated by Cyril VAZQUEZ over 2 years ago
- Target version changed from 2.8.2 to 3.0
Updated by Jérôme BOUCHER over 1 year ago
- Status changed from A revoir (S) to Complément d'Informations
- Assignee set to 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 ?