Spécifications de Maarch MoReq2 V1.0
De Maarch MoReq2.
Sommaire |
Finalité
Objectif à atteindre et fonctions à réaliser pour y arriver.
Conformément à la réunion du 26/05/2010, la V1 implémentera les points suivants :
- Une première version du plan de classement : /Plan de classement V1.0
- Une première version de la sécurité : /Sécurité V1.0
Le plan de classement implémenté permettra l'exécution des cas d'utilisation suivants :
Structure
Éléments nécessaires pour accomplir la finalité.
Structure existante
Les résultats de l'analyse de Maarch Entreprise sont exposés sur une page dédiée.
Structure finale
Vues
En plus de la vue res_view_letterbox qui est basé sur res_letterbox, nous avons besoin d'une nouvelle vue qui prendra en compte le plan de classement.
Vue axée documents : res_view_lettebox
Tables actuellement nécessaires à la création de la vue :
- res_letterbox
- doctypes
- doctypes_first_level dfl
- doctypes_second_level dsl
- ar_batch
- entities
- folder
- cases_res
- cases
- mlb_coll_ext
- foldertypes
- contacts
- users
- listinstance
Tables à rajouter :
- res_classification (en cas de collection multi-classement)
Tables à enlever :
- doctypes_first_level dfl
- doctypes_second_level dsl
- folder
- foldertypes
Vue axée plan de classement : classification_view
Cette vue doit reprendre toutes les arborescences des différents plans de classement. Il faut donc exclure les agrégations "serielles".
Tables concernées :
- aggregation
- classification_scheme
- entities
- aggregation_type ?
Modèles
Modèle physique
Charte de nommage :
| Nommage | Correspond à | Exemple |
|---|---|---|
| mr_sth | Métadonnée du MoReq2 ou Nom d'un objet du moreq | mr_title ou mr_classification_scheme |
| is_sth ou can_sth | Booléen | is_mr_vital ou can_have_documents |
| obj_id | Identifiant de l'objet | mr_aggregation_id |
| role_externalObject_id | Identifiant faisant référence à un objet externe | parent_mr_aggregation_id |
| sth_date | Date | mr_creation_date |
| sth_number | Nombre (entier ou réel) | level_number |
| role_nameOfExternalTable_nameOfOtherTable[_nameOfOtherTables] | Table de lien [*,*] entre deux tables ou plus | classification_mr_res_record_multi_mr_aggregation |
| Terme physique | Terme MoReq2 correspondant | Observations |
|---|---|---|
| mr_reclassification_user_id | M162 - Relation.agent.relocated | Tous les « relocat* » seront renommés en « reclassificat* » |
| mr_reclassification_date | M159 - Event_history.date.relocated | |
| mr_deletion_date | M141 - Event_history.date.destroyed | Tous les « destr* » seront renommés en « delet* » |
| Métadonnées adaptées | ||
| mr_aggregation_id | system_identifier | Vaut pour les métadonnées suivantes : M020, M008, M044, M137 |
| mr_r&d_schedule_id | ||
| mr_classification_scheme_id | ||
| mr_disposal_hold_id | ||
| mr_full_classification_code | M12 - Description.classification.fully_qualified_classification_code | Vaut pour mr_aggregation et les res_record_*. |
| parent_mr_aggregation_id | M057 - Relation.is_child_of | Vaut pour mr_aggregation, mr_res_record_mono et classification_mr_res_record_multi_mr_aggregation. |
| mr_owner_entity_id | M002 - Relation.agent.owner | Vaut pour mr_aggregation, res_record_mono et res_classification. |
| mr_review_planned_date | M138 - Event_plan.abstract.review_date | Vaut pour mr_aggregation. |
| mr_applied_reason | reason_applied | Cohérent avec les dénominations « relocated_reason » et « review_reason ». Vaut pour mr_disposal_hold |
| mr_applied_user_id | agent_applied | Vaut pour mr_disposal_hold |
| mr_lifted_user_id | agent_lifted | Vaut pour mr_disposal_hold |
| mr_is_inheritable | inheritance | Vaut pour mr_disposal_hold et mr_r&d_schedule. |
| mr_serial_id | case_id | Vaut pour mr_aggregation. Ajout d'une nouvelle règle de gestion[1]. |
| redaction_from_mr_res_record_multi_id | has_redaction | Noter le changement de direction. Vaut pour les res_record_*. |
| rendition_from_mr_res_record_multi_id | has_rendition | |
| mr_keywords | keyword | Pluriel. Vaut pour les mr_aggregation et res_*. |
| mr_is_validated_signature | M113 - Use.status.electronic_signature | Pour lever l'ambiguïté de cette métadonnée. Vaut pour les res_record_*. |
| mr_signature_validation_user_id | M147 - Use.technical_environment.validated_by | Vaut pour les res_record_*. |
| Ajouts de métadonnées à mr_aggregation | ||
| level_number | Faciliter les calculs. | |
| aggregation_type_id | Distinguer les différents types d'agrégation. | |
| reviewed_user_id | Pour tracer. | |
| checked_user_id | ||
| is_public | Accès public. | |
| Métadonnées ajoutées à res_record_multi | ||
| mr_keywords | M004 - Description.abstract.keyword | Pluriel. |
| mr_sent_date | M074 - Event_history.date.sent | |
| mr_received_date | M088 - Event_history.date.received | |
| mr_encrypted_date | M119 - Event_history.date.encrypted | |
| mr_decrypted_date | M119 - Event_history.date.decrypted | |
| mr_electronic_signature_verification_date | M119 - Event_history.date.verification.electronic_signature | |
| mr_rendition_of_res_id | M149 - Relation.is_rendition_of | |
| mr_rendition_date | M127 - Event_history.date.rendition | |
| redaction_of_mr_res_record_multi_id | M082 - Relation.has_redaction | Noter le changement de direction. |
| mr_electronic_signature | M076 - Use.technical_environment.electronic_signature | |
| Métadonnées ajoutées à res_classification | ||
| parent_mr_aggregation_id | M057 - Relation.is_child_of | |
| mr_owner_entity_id | M002 - Relation.owner | |
| mr_full_classification_code | M012 - Description.classification.fully_qualified_classification_code | Ajouté également à mr_classification_scheme |
| previous_mr_full_classification_code | M091 - Relation.previous_fully_qualified_classification_code | |
| mr_reclassification_date | M159 - Event_history.date.relocated | |
| mr_reclassification_reason | M021 - Event_history.abstract.reclassification_reason | |
| mr_reclassification_user_id | M162 - Relation.agent.relocated | |
| Métadonnées ajoutées à res_record_mono | ||
| parent_mr_aggregation_id | M057 - Relation.is_child_of | |
| mr_owner_entity_id | M002 - Relation.owner | |
| mr_full_classification_code | M012 - Description.classification.fully_qualified_classification_code | |
| previous_mr_full_classification_code | M091 - Relation.previous_fully_qualified_classification_code | |
| mr_reclassification_date | M159 - Event_history.date.relocated | |
| mr_reclassification_reason | M021 - Event_history.abstract.reclassification_reason | |
| mr_reclassification_user_id | M162 - Relation.agent.relocated | |
| Les champs de res_x qui correspondent à des métadonnées MoReq2 : | ||
| res_id | M020 - system_identifier | Sera modifié en mr_res_record_multi_id |
| title | M003 - title | |
| type_id | M026 - record_type | |
| creation_date | M071 - captured | |
| doc_date | M065 - Description.date | |
| identifier | M070 - Description.external_identifier.internal_reference et M195 - Description.external_identifier.external_system_reference | |
| arbox_id | M084 - Use.status.physical | Permet de retrouver les métadonnées liées à l'état physique. |
| doc_language | M145 - Use.language | |
| Métadonnées supprimées car pouvant être recalculées | ||
| M155 - Use.status.deleted_or_moved | Déduite des valeurs de date.moved et date.deleted. | |
| M125 - Identity.system_identifier_rendition | Aucune différence avec le system_identifier « classique ». | |
| Composition de la table de gel disposal_hold | ||
| mr_disposal_hold_id | M137 - Identity.system_identifier.disposal_hold | |
| mr_applied_date | M034 - Event_history.disposal_hold.date_applied | |
| mr_applied_reason | M135 - Event_history.disposal_hold.reason_applied | |
| mr_applied_user_id | M035 - Event_history.disposal_hold.agent_applied | |
| mr_lifted_date | M102 - Event_history.disposal_hold.date_lifted | |
| mr_lifted_reason | M136 - Event_history.disposal_hold.reason_lifted | |
| mr_lifted_user_id | M134 - Event_history.disposal_hold.agent_lifted | |
| mr_reminder_date | M037 - Event_planned.reminder | |
- Gestion des auteurs, expéditeurs et destinataires : puisque ceux-ci peuvent être internes ou externes, un champ sera rajouté par possibilité, ce qui donne pour la table res_record_multi et la métadonnée M190 - Relation.agent.author :
- mr_author_contact_id référence un identifiant de la table contacts
- mr_author_user_id référence un identifiant de la table users
- mr_author_entity_id référence un identifiant de la table entities
Modèle logique
Principe de base : canevas « MVC[2] ». Concrètement, il y a un contrôleur entre les pages affichées et le modèle objet, ainsi qu'entre le modèle objet et la base de donnée.
Charte de nommage des fichiers PHP :
| Principe | Concerne | Observations | Exemples |
|---|---|---|---|
| page_name.php | Page « web » | Tout en minuscules, un « souligné » pour séparer les mots. En anglais. | aggregation_navigation_page.php |
| class/object_name.php | Classe d'objet | En anglais. On notera que object_name=table_name. | mr_classification_scheme.php |
| class/object_name_ontroler.php | Contrôleur d'un objet. | Ajout du terme « controler » au nom concerné. En anglais. | mr_res_record_multi_controler.php |
| action_object_name_controler.php | Contrôleur pour une action de modification de la base de données[3] | object_name peut être différent du nom de la classe concernée. | capture_record_controler.php |
| object_name_page_controler.php | Contrôleur pour une action de lecture de la base de données. | object_name peut être différent du nom de la classe concernée − et même ne pas avoir de lien avec un objet de class, mais avec un objet de l'affichage. | aggregation_page_controler.php |
Group
Group.getAccess(coll_id) => renvoie un accès
Group.getAccesses() => renvoie un tableau d'accès
Group.addAccess(...) => crée un accès
Group.setAccess(coll_id, [id, val]) => met à jour un accès
Group.deleteAccess(coll_id) => supprime un accès
ClassificationScheme
ClassificationScheme.create(label, ...) => Création d'un plan de classement
ClassificationScheme.update(id, label, ...) => Modification d'un plan de classement
ClassificationScheme.delete(id) => Suppression d'un plan de classement
ClassificationScheme.getAggregations(where_clause) => Renvoie dans un tableau les identifiants des agrégations dépendantes de ce plan en fonction de la clause de sécurité
Aggregation
Aggregation.create(...) => création d'une agrégation
Aggregation.update(...) => modification d'une agrégation
Aggregation.delete() => suppression de l'agrégation
Aggregation.getChildren() => Renvoie dans un tableau les identifiants de toutes les agrégations filles
Aggregation.getParent => renvoie l'identifiant de l'agrégation parente ou du plan de classement
Aggregation.getMetadata(field_names) => renvoie les valeurs des champs contenu dans le tableau
Aggregation.getRecords(where_clause) => renvoie la liste des documents contenus dans l'agrégation en appliquant un filtre de sécurité
Aggregation.getLog(id, filters) => renvoie l'historique, filtré ou non, d'une agrégations dans un tableau
Record
Liste des actions à implémenter
Nombre de bits du bitmask à implémenter :
- capturer un doc
- créer une série
- créer un dossier /sous-dossier/volume
- modifier les métadonnées
- supprimer un document
- supprimer une série
- supprimer un dossier / sous-dossier / volume
- consultation de l'historique
Règles de gestion
Les règles de gestion et l'état d'avancement des développements sont à présent sur une page dédiée :
Interfaces livrées
Dernière version (24/08/2010)[4] :
Version du 12/08/2010 :
Interfaces prévues
N.B. : Si l'utilisateur a accès à deux séries non reliées par une série mère commune, l'arbre de navigation doit présenter ces deux séries au même niveau.
Exemple de structure :
Les 2 diagrammes ci-dessous donnent un exemple concret de la répartition des actions, en l'occurrence pour la capture de document :
- Le diagramme Record capture montre les actions effectuées sur la page HTML, grâce à la gestion Javascript de ses éléments. Après l'action Validate, l'activité Record capture validation est à son tour détaillée dans le diagramme de droite. C'est un composant Javascript asynchrone qui appelle cette activité.
- Le diagramme Record capture validation montre les actions effectuées par le contrôleur de page, appelé par le composant asynchrone et auquel sont transmis les informations nécessaires au traitement.
- On peut noter que l'action Update displayed document list fait elle aussi appel à un contrôleur spécifique.
Interactions
Flux entrants de l'environnement.
Analyse de risques
Partie non publiée (disponible sur l'intranet).
Notes
- ↑ Si parent_aggregation_id=null alors serial_id≠null.
- ↑ Modèle-Vue-Contrôleur.
- ↑ Ajout, suppression, modification.
- ↑ Attention : Sur cette capture apparaissent en même temps les actions possibles de capture de document et de création d'agrégations (série, autres), ce qui est bien sûr une incohérence du point de vue du MoReq2. Cela vient du « fantôme » de fonction utilisé pour le moment pour la récupération des actions possibles qui renvoie toujours la même chose. La prochaine étape sera donc la gestion exacte des actions possibles à un endroit donné.
