# `Process` et `Role` - Specifications
## 1. Autheurs, validations, dates, versions, changement and historique
Cf. [Git SDK COMMON](https://git.4nk.com/4nk/sdk_common/doc)
## 2. Table des matières
* 1. [Autheurs, validations, dates, versions, changement and historique](#Autheursvalidationsdatesversionschangementandhistorique)
* 2. [Table des matières](#Tabledesmatires)
* 3. [Objectif](#Objectif)
* 4. [Portée](#Porte)
* 5. [Documents de référence](#Documentsderfrence)
* 6. [Rôles et Sous-Rôles](#RlesetSous-Rles)
* 7. [Précisions sur les rôles](#Prcisionssurlesrles)
* 7.1. [RolesGroup - Gestion des Rôles](#RolesGroup-GestiondesRles)
* 7.1.1. [Composition et Fonction](#CompositionetFonction)
* 7.1.2. [Cas d'utilisation](#Casdutilisation)
* 7.2. [Cas d'utilisation](#Casdutilisation-1)
* 7.2.1. [Composition et Fonction](#CompositionetFonction-1)
* 7.2.2. [Cas d'utilisation](#Casdutilisation-1)
* 7.3. [Role - Définition et Gestion des Rôles Spécifiques](#Role-DfinitionetGestiondesRlesSpcifiques)
* 7.3.1. [Composition et Fonction](#CompositionetFonction-1)
* 7.3.2. [Cas d'utilisation](#Casdutilisation-1)
* 8. [Gestion des Engagements et Transactions](#GestiondesEngagementsetTransactions)
* 8.1. [Rolecommit](#Rolecommit)
* 8.2. [RoleDeposit et RolePayments](#RoleDepositetRolePayments)
* 9. [Sécurisation des Communications](#ScurisationdesCommunications)
* 9.1. [Composition et Utilisation](#CompositionetUtilisation)
* 10. [Intégration et Orchestration des Processus](#IntgrationetOrchestrationdesProcessus)
* 11. [Condition PrdAddressSet](#ConditionPrdAddressSet)
* 11.1. [Participants](#Participants)
* 11.2. [Valeurs des signatures (`sig_value`)](#Valeursdessignaturessig_value)
* 11.3. [Minimums et maximums de valeurs "OK", "KO" et "NONE"](#MinimumsetmaximumsdevaleursOKKOetNONE)
* 11.4. [Minimums et maximums de scores](#Minimumsetmaximumsdescores)
* 12. [ConditionPublish : conditions de publication](#ConditionPublish:conditionsdepublication)
* 13. [ConditionOrchestration : conditions d'orchestration des processus](#ConditionOrchestration:conditionsdorchestrationdesprocessus)
* 14. [ConditionPayments : conditions de paiement](#ConditionPayments:conditionsdepaiement)
* 15. [Conditioncommit : conditions d'engagement](#Conditioncommit:conditionsdengagement)
* 16. [ConditionDeposit : conditions de dépôt de garantie](#ConditionDeposit:conditionsdedptdegarantie)
* 17. [ConditionCap : Conditions de passage d'un seuil minimum de paiements ou de déposits ou de d'engagement](#ConditionCap:Conditionsdepassagedunseuilminimumdepaiementsoudedpositsoudedengagement)
* 18. [TransactionMode](#TransactionMode)
* 19. [Exemples de Code](#ExemplesdeCode)
* 20. [Todo](#Todo)
## 3. Objectif
Cette section vise à présenter en détail les Documents de Contrat Portable ( Pcd) et les Documents de Demande Portable ( Prd), qui constituent les piliers du système 4NK. Essentiels pour sécuriser les transactions de données et gérer les `User`, les `Pcd` et `Prd` assurent l'intégrité et la confidentialité au cœur d'un réseau décentralisé.
## 4. Portée
## 5. Documents de référence
Voir [_Doc_references.md](_Doc_references.md).
## 6. Rôles et Sous-Rôles
Les rôles déterminent les permissions et les responsabilités des participants dans le système 4NK. Ils sont essentiels pour contrôler l'accès aux données et les autorisations au sein des `Process` . Les `rôles` principaux incluent :
* **RolePeer**: Conditions des listes de relais participants qui facilitent les communications et les transactions et des versions de ces listes.
* **RoleMember**: Conditions des listes des `User` ou entités ayant une participation directe dans un processus spécifique et des versions de ces listes.
* **RoleProcess**: Conditions des listes des processus et des versions des listes.
* **RoleArtefact**: Définit les permissions et les interactions pour les artefacts au sein du réseau et des version de ces listes, par types d'artefacts.
Chaque rôle peut comporter des sous-rôles spécifiques, tels que `RolePayments`, `RoleDeposit`, et `Rolecommit`, chacun avec des responsabilités et des interactions uniques dans le cadre des processus qu'ils soutiennent.
## 7. Précisions sur les rôles
### 7.1. RolesGroup - Gestion des Rôles
La structure RolesGroup est essentielle pour définir et gérer les groupes de rôles au sein du système 4NK, permettant une organisation claire des permissions et des responsabilités.
#### 7.1.1. Composition et Fonction
* **role_peer**: Définit le rôle des pairs dans le réseau, responsables de la facilitation des communications et des transactions.
* **role_Member**: Spécifie le rôle des Members, ou `User`, qui participent activement dans les processus et les interactions.
* **role_process**: Représente les entités chargées de définir et de gérer les processus au sein du système.
* **role_artefact_list**: Une liste de rôles d'artefacts, permettant la personnalisation et l'extension des fonctionnalités et des interactions au-delà des rôles standards.
#### 7.1.2. Cas d'utilisation
Cette structure permet une gestion flexible des rôles au sein du système, facilitant l'assignation de permissions spécifiques et la délimitation des responsabilités pour une sécurité et une efficacité accrues.
### 7.2. Cas d'utilisation
Ces modes supportent divers scénarios de communication, de la diffusion large d'informations ou de mises à jour, à des échanges directs pour des opérations spécifiques, offrant ainsi une flexibilité dans la gestion des flux d'informations.
# `Role` - Définition et Gestion des Rôles Spécifiques
La structure `Role` est fondamentale pour définir les caractéristiques et les exigences de chaque rôle au sein du système 4NK, y compris les permissions, les validations nécessaires, et les conditions spécifiques d'utilisation.
#### 7.2.1. Composition et Fonction
* **item**: L'entité ou l'objet auquel le rôle est associé, fournissant un contexte pour les permissions et les actions.
* **required_2fa**: Indique si une authentification à deux facteurs est requise pour ce rôle, augmentant la sécurité pour les actions critiques.
* **validation_timeout**: Définit un délai pour la validation des actions ou des demandes associées à ce rôle, assurant la promptitude et l'efficacité des processus.
* **condition**: Ensemble de critères et de règles définissant comment les actions sont validées, exécutées, ou refusées selon le contexte.
#### 7.2.2. Cas d'utilisation
Cette structure permet une personnalisation détaillée des rôles au sein du système, assurant que chaque rôle est équipé des permissions et des contraintes appropriées pour sa fonction spécifique, contribuant à la sécurité et à l'ordre du système global.
### 7.3. Role - Définition et Gestion des Rôles Spécifiques
La structure `Role` est fondamentale pour définir les caractéristiques et les exigences de chaque rôle au sein du système 4NK, y compris les permissions, les validations nécessaires, et les conditions spécifiques d'utilisation.
#### 7.3.1. Composition et Fonction
* **item**: L'entité ou l'objet auquel le rôle est associé, fournissant un contexte pour les permissions et les actions.
* **required_2fa**: Indique si une authentification à deux facteurs est requise pour ce rôle, augmentant la sécurité pour les actions critiques.
* **validation_timeout**: Définit un délai pour la validation des actions ou des demandes associées à ce rôle, assurant la promptitude et l'efficacité des processus.
* **condition**: Ensemble de critères et de règles définissant comment les actions sont validées, exécutées, ou refusées selon le contexte.
#### 7.3.2. Cas d'utilisation
Cette structure permet une personnalisation détaillée des rôles au sein du système, assurant que chaque rôle est équipé des permissions et des contraintes appropriées pour sa fonction spécifique, contribuant à la sécurité et à l'ordre du système global.
## 8. Gestion des Engagements et Transactions
Les engagements dans le système 4NK, tels que représentés par les structures Rolecommit, RoleDeposit, et RolePayments, jouent un rôle crucial dans la formalisation des transactions et des obligations entre les parties.
### 8.1. Rolecommit
* **item_name**: Identifie l'engagement spécifique ou l'obligation prise par une partie.
* **role**: Définit les permissions, les conditions et les critères associés à cet engagement, assurant une exécution et une validation conformes aux attentes.
### 8.2. RoleDeposit et RolePayments
Ces structures gèrent respectivement les dépôts de garantie et les paiements, en spécifiant les conditions sous lesquelles les fonds sont déposés, retenus ou transférés, contribuant ainsi à la confiance et à la fluidité des transactions au sein du réseau.
## 9. Sécurisation des Communications
La structure MetaData et ses sous-structures comme MetadataContractPublic, MetadataRoleConfidential, et MetadataPrivate fournissent un cadre pour sécuriser les communications et les données au sein du système 4NK, permettant une distinction claire entre les informations accessibles publiquement, celles réservées à certains rôles, et celles strictement privées.
### 9.1. Composition et Utilisation
* **meta_data**: Chaque instance de MetaData encapsule des informations détaillées, des attributs et des clés de chiffrement liés à un item, facilitant la gestion sécurisée et la distribution ciblée des données.
* **key_list**: Un élément crucial pour le chiffrement et la sécurisation des données, assurant que seules les parties autorisées peuvent accéder aux informations confidentielles.
## 10. Intégration et Orchestration des Processus
L'Process et ProcessPublicAttributeGroup offrent un cadre pour l'intégration et l'orchestration des processus dans le système 4NK, permettant la définition, la gestion et l'exécution de workflows complexes de manière sécurisée et efficace.
## 11. Condition PrdAddressSet
A l'issue d'un délai `validation_timeout` par `Role` et par * `request_prd_type`, les `PrdRequest` sont collectés afin de vérifier les conditions de validation par roles sont définies en fonction des critères suivants :
Les Members concernés sont identifiés par leurs `adresse SP`.
### 11.1. Participants
* `request_prd_sp_address_list`: Liste des `adresse SP` (cumulatif avec `from_role`)
* `request_prd_sp_address_required_list`: Liste des `adresse SP` requises (toutes valeurs confondues)
* `request_prd_sp_address_quota`: Quota minmum de `adresse SP` participantes (toutes valeurs confondues)
* `request_prd_sp_address_score_min`: Score minimal des Members participants (toutes valeurs confondues)
### 11.2. Valeurs des signatures (`sig_value`)
* (option)`request_prd_value_ok_list`: Liste des valeurs valant pour "OK"
* (option)`request_prd_value_ko_list`: Liste des valeurs valant pour "KO"
* (option)`request_prd_value_none_list`: Liste des valeurs valant pour "NONE"
* (option)`request_prd_value_auto_ok`: Valeur automatique valant pour "OK"
* (option)`request_prd_value_auto_ko`: Valeur automatique valant pour "KO"
* (option)`request_prd_value_auto_none`: Valeur automatique valant pour "NONE"
### 11.3. Minimums et maximums de valeurs "OK", "KO" et "NONE"
* (option)`request_prd_sp_address_value_min_ok`: Nombre minimal de valeurs valant pour "OK"
* (option)`request_prd_sp_adddress_value_ok_min_per`: Pourcentage minimal de valeurs valant pour "OK"
* (option)`request_prd_sp_address_value_ok_max`: Nombre maximal de valeurs valant pour "OK"
* (option)`request_prd_sp_adderss_value_ko_max_per`: Pourcentage maximal de valeurs valant pour "KO"
* (option)`request_prd_sp_address_value_ko_max`: Nombre maximal de valeurs valant pour "OK"
* (option)`request_prd_sp_address_value_none_max`: Nombre maximal de valeurs valant pour "NONE"
* (option)`request_prd_sp_adderss_value_none_max_per`: Pourcentage maximal de valeurs valant pour "NONE"
### 11.4. Minimums et maximums de scores
* (option)`request_prd_sp_address_score_min_min_ok`: Nombre de Members avec un score minimum et une valeur valant pour "OK"
* (option)`request_prd_sp_address_score_min_min_per`:: Pourcentage de Members avec un score minimum et une valeur valant pour "OK"
* (option)`request_prd_sp_address_value_min`: Valeur minimal valant pour "OK" (cas de nombres)
* (option) `from_role` : `address SP` de ce `Role` (pour éviter de dupliquer les `addresse SP`)
## 12. ConditionPublish : conditions de publication
* (option)`request_pcd_data_size_max_unit`: Taille maximale des données de chaque `Pcd` en Mo
* (option)`request_pcd_data_size_max_total`: Taille maximale des données des `Pcd` en Mo
* (option)`request_pcd_number_min`: Nombre minimum de publication de `Pcd`
* (option)`request_pcd_number_max`: Nombre maximum de publication de `Pcd`
* (option)`request_pcd_amount_max_total`: Montant maximum des montants dans les items des `Pcd`
* (option)`request_prd_waiting_timeout`: Délai d'attente pour la réception des `Prd`
* (option)`request_pcd_waiting_timeout`: Délai d'attente pour la réception des `Pcd`
## 13. ConditionOrchestration : conditions d'orchestration des processus
* (option) `role_ok`: `Role` à vérifier en cas de résulats final "OK"
* (option) `role_ko`: `Role` à vérifier en cas de résulats final "KO"
## 14. ConditionPayments : conditions de paiement
* (option) `Payments_method_list`: Liste des modes de paiement acceptés
* (option) `role_transaction` : voir `TransactionMode`
## 15. Conditioncommit : conditions d'engagement
* (option) `role_artefact`
* (option) `role_transaction` : voir `TransactionMode`
## 16. ConditionDeposit : conditions de dépôt de garantie
* (option) `role_deposit`
* (option) `role_transaction` : voir `TransactionMode`
## 17. ConditionCap : Conditions de passage d'un seuil minimum de paiements ou de déposits ou de d'engagement
* (option) `role_deposit`
* (option) `role_transaction` : voir `TransactionMode`
## 18. TransactionMode
* `value`: Montant du paiement (objet `Amount` ou `Number`)
* `from_list` : Liste des adresses ou des rôles qui doivent opérer le paiement
* `from_type` : Soit "addresses" soit "roles"
* `from_method` : Méthode de distribution de la somme des prélèvements : "Amount divided" ou "Same Amount"
* `to_list` : Liste des adresses ou des rôles qui doivent recevoir le Versement
* `to_type` : Soit "addresses" soit "roles"
* `to_method` : Méthode de distribution de la somme des versements : "Amount divided" ou "Same Amount"
## 19. Exemples de Code
## 20. Todo
* [ ] Exemples des fichiers html qui seront à l'intérieur du process
* [ ] Générer les mocks
* [ ] Plus d'exemples et d'explication sur les roles et les sous-roles et leurs fonctions.
* [ ] Extraits de code illustrant l'utilisation des `Pcd` et `Prd` dans des scénarios réels.
* [ ] Diagrammes de séquences