Projet

Général

Profil

Actions

Fonctionnalité #15949

ouvert

[Communicabilité] Comportement pour règle de communicabilité non définie

Ajouté par Cyril VAZQUEZ il y a presque 4 ans. Mis à jour il y a 10 mois.

Statut:
Complément d'Informations
Priorité:
2-Sérieux
Assigné à:
Version cible:
Début:
18/01/2021
Echéance:
Tags RM:

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.


Fichiers

Modif-15949.png (60,2 ko) Modif-15949.png Arnaud PAUGET, 13/12/2021 16:02

Mis à jour par Solange De Malliard il y a presque 4 ans

  • Statut changé de A traiter à En cours

Mis à jour par Solange De Malliard il y a presque 4 ans

  • Statut changé de En cours à A traiter

Mis à jour par Arnaud PAUGET il y a plus de 3 ans

  • Version cible changé de 2.8 à 2.8.0

Mis à jour par Cyril VAZQUEZ il y a plus de 3 ans

  • Version cible changé de 2.8.0 à 2.8

Mis à jour par Jérôme BOUCHER il y a plus de 3 ans

  • Statut changé de A traiter à R&D - En test

À tester sur branche feat/15949_communication_rule socle et AP

Mis à jour par Alexandre GOLDSTEIN il y a plus de 3 ans

fusionné sur develop pour démo du jour

Mis à jour par Emmanuel DILLARD il y a plus de 3 ans

  • Projet changé de 252 à Backlog RM
  • Version cible changé de 2.8 à 2.8
  • Fonction Communication supprimé

Mis à jour par Arnaud PAUGET il y a environ 3 ans

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)

Mis à jour par Jérôme BOUCHER il y a presque 3 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 ?

Mis à jour par Cyril VAZQUEZ il y a presque 3 ans

  • Statut changé de Complément d'Informations à Clôturé

Mis à jour par Cyril VAZQUEZ il y a presque 3 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)

Mis à jour par Cyril VAZQUEZ il y a presque 3 ans

  • Version cible changé de 2.8 à 2.8.2

Mis à jour par Cyril VAZQUEZ il y a plus de 2 ans

  • Version cible changé de 2.8.2 à 3.0

Mis à jour par Jérôme BOUCHER il y a plus d'un an

  • 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 ?

Mis à jour par Cyril VAZQUEZ il y a 10 mois

  • Version cible changé de 3.0 à 3.X
Actions

Formats disponibles : Atom PDF