Project

General

Profile

Actions

Fonctionnalité #15949

open

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

Added by Cyril VAZQUEZ almost 4 years ago. Updated 9 months ago.

Status:
Complément d'Informations
Priority:
2-Sérieux
Assignee:
Target version:
Start date:
01/18/2021
Due date:
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.


Files

Modif-15949.png (60.2 KB) Modif-15949.png Arnaud PAUGET, 12/13/2021 04:02 PM
Actions #1

Updated by Solange De Malliard over 3 years ago

  • Status changed from A traiter to En cours
Actions #2

Updated by Solange De Malliard over 3 years ago

  • Status changed from En cours to A traiter
Actions #3

Updated by Arnaud PAUGET over 3 years ago

  • Target version changed from 2.8 to 2.8.0
Actions #4

Updated by Cyril VAZQUEZ over 3 years ago

  • Target version changed from 2.8.0 to 2.8
Actions #5

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

Actions #6

Updated by Alexandre GOLDSTEIN over 3 years ago

fusionné sur develop pour démo du jour

Actions #7

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)
Actions #8

Updated by Arnaud PAUGET almost 3 years ago

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)

Actions #9

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 ?

Actions #10

Updated by Cyril VAZQUEZ almost 3 years ago

  • Status changed from Complément d'Informations to Clôturé
Actions #11

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)
Actions #12

Updated by Cyril VAZQUEZ almost 3 years ago

  • Target version changed from 2.8 to 2.8.2
Actions #13

Updated by Cyril VAZQUEZ over 2 years ago

  • Target version changed from 2.8.2 to 3.0
Actions #14

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 ?

Actions #15

Updated by Cyril VAZQUEZ 9 months ago

  • Target version changed from 3.0 to 3.X
Actions

Also available in: Atom PDF