fy59/labfy-investigation

Fork 0

Ajouter les métadonnées lors de l’import d’une preuve #51

New issue

Closed

opened 2026-07-20 07:16:43 +02:00 by fy59 · 0 comments

fy59 commented

2026-07-20 07:16:43 +02:00

Owner

Ajouter les métadonnées lors de l’import d’une preuve

Objectif

Ajouter une boîte de dialogue GTK permettant de renseigner les métadonnées
d’une preuve avant de lancer son import asynchrone.

Parcours utilisateur

L’utilisateur clique sur « Importer une preuve ».
Il sélectionne un fichier.
Une boîte de dialogue affiche :
- le fichier sélectionné ;
- le type de preuve ;
- la date et l’heure de collecte ;
- la source ;
- la description.
L’utilisateur valide.
L’import asynchrone existant est lancé.
La preuve est copiée, hachée et enregistrée dans SQLite.
L’arborescence est rafraîchie.

Source des types de preuve

Les types doivent être chargés depuis la table SQLite types_preuve.

Colonnes utilisées :

id
code
label
description

Le dialogue affiche label, mais transmet code à EvidenceImporter.

Aucune liste de types ne doit être codée en dur dans l’interface GTK.

Types présents actuellement

Code	Libellé
`screenshot`	Capture d’écran
`photo`	Photographie
`video`	Vidéo
`document`	Document
`email`	Courrier électronique
`archive`	Archive
`audio`	Audio
`text`	Texte
`other`	Autre

Métadonnées du formulaire

Fichier

affiché en lecture seule ;
obligatoire ;
déjà sélectionné avant l’ouverture du dialogue.

Type de preuve

liste déroulante ;
chargée depuis SQLite ;
obligatoire ;
document sélectionné par défaut lorsqu’il existe.

Date et heure de collecte

préremplie avec la date et l’heure actuelles ;
modifiable ;
convertie en chaîne ISO 8601 avant l’import.

Source

champ texte facultatif ;
exemple : URL, compte utilisateur, téléphone, appareil ou personne.

Description

zone de texte facultative ;
permet d’ajouter le contexte de collecte.

Architecture prévue

EvidenceType

Créer un modèle métier représentant une ligne de types_preuve.

Propriétés :

identifiant numérique ;
code ;
libellé ;
description.

EvidenceTypeDao

Créer un DAO chargé de lire les types depuis SQLite.

Il emprunte une connexion Database existante.

Fonction principale :

GPtrArray *evidence_type_dao_list_all(
    EvidenceTypeDao *evidence_type_dao,
    GError **error
);

Le tableau retourné appartient au code appelant et contient des objets
EvidenceType.

EvidenceImportDialog

Créer un module GTK indépendant.

Il reçoit :

la fenêtre parente ;
le chemin du fichier ;
la liste des types disponibles ;
un callback ;
des données utilisateur.

Il retourne une structure contenant :

type_identifier ;
collected_at ;
source ;
description.

Le dialogue ne doit pas accéder directement à SQLite.

Validation

Le bouton « Importer » doit être désactivé lorsque :

aucun type n’est sélectionné ;
la date de collecte est invalide ;
le fichier sélectionné est absent.

Une annulation ne doit créer :

aucun fichier ;
aucune ligne SQLite ;
aucune tâche de fond.

Tests attendus

EvidenceType

création valide ;
refus des arguments obligatoires invalides ;
getters ;
destruction avec valeurs facultatives absentes.

EvidenceTypeDao

lecture de tous les types ;
ordre stable ;
correspondance correcte entre code et libellé ;
table vide ;
base ou table invalide.

Validation du formulaire

Extraire la validation des données dans une fonction testable sans afficher GTK.

Tester :

valeurs valides ;
type absent ;
date absente ;
date invalide ;
champs facultatifs vides.

Critères d’acceptation

les types sont lus depuis SQLite ;
aucun type n’est codé en dur dans GTK ;
le libellé est affiché à l’utilisateur ;
le code est transmis à l’importeur ;
les métadonnées sont enregistrées dans preuves ;
l’import reste asynchrone ;
l’annulation du dialogue ne démarre aucune tâche ;
tous les tests passent ;
compilation C17 avec -Wall -Wextra -Werror.

Découpage technique

EvidenceType
EvidenceTypeDao
tests du DAO
EvidenceImportDialog
validation des champs
branchement dans Application
test GTK complet

# Ajouter les métadonnées lors de l’import d’une preuve ## Objectif Ajouter une boîte de dialogue GTK permettant de renseigner les métadonnées d’une preuve avant de lancer son import asynchrone. ## Parcours utilisateur 1. L’utilisateur clique sur « Importer une preuve ». 2. Il sélectionne un fichier. 3. Une boîte de dialogue affiche : - le fichier sélectionné ; - le type de preuve ; - la date et l’heure de collecte ; - la source ; - la description. 4. L’utilisateur valide. 5. L’import asynchrone existant est lancé. 6. La preuve est copiée, hachée et enregistrée dans SQLite. 7. L’arborescence est rafraîchie. ## Source des types de preuve Les types doivent être chargés depuis la table SQLite `types_preuve`. Colonnes utilisées : - `id` - `code` - `label` - `description` Le dialogue affiche `label`, mais transmet `code` à `EvidenceImporter`. Aucune liste de types ne doit être codée en dur dans l’interface GTK. ## Types présents actuellement | Code | Libellé | |---|---| | `screenshot` | Capture d’écran | | `photo` | Photographie | | `video` | Vidéo | | `document` | Document | | `email` | Courrier électronique | | `archive` | Archive | | `audio` | Audio | | `text` | Texte | | `other` | Autre | ## Métadonnées du formulaire ### Fichier - affiché en lecture seule ; - obligatoire ; - déjà sélectionné avant l’ouverture du dialogue. ### Type de preuve - liste déroulante ; - chargée depuis SQLite ; - obligatoire ; - `document` sélectionné par défaut lorsqu’il existe. ### Date et heure de collecte - préremplie avec la date et l’heure actuelles ; - modifiable ; - convertie en chaîne ISO 8601 avant l’import. ### Source - champ texte facultatif ; - exemple : URL, compte utilisateur, téléphone, appareil ou personne. ### Description - zone de texte facultative ; - permet d’ajouter le contexte de collecte. ## Architecture prévue ### EvidenceType Créer un modèle métier représentant une ligne de `types_preuve`. Propriétés : - identifiant numérique ; - code ; - libellé ; - description. ### EvidenceTypeDao Créer un DAO chargé de lire les types depuis SQLite. Il emprunte une connexion `Database` existante. Fonction principale : ```c GPtrArray *evidence_type_dao_list_all( EvidenceTypeDao *evidence_type_dao, GError **error ); ``` Le tableau retourné appartient au code appelant et contient des objets `EvidenceType`. ### EvidenceImportDialog Créer un module GTK indépendant. Il reçoit : - la fenêtre parente ; - le chemin du fichier ; - la liste des types disponibles ; - un callback ; - des données utilisateur. Il retourne une structure contenant : - `type_identifier` ; - `collected_at` ; - `source` ; - `description`. Le dialogue ne doit pas accéder directement à SQLite. ## Validation Le bouton « Importer » doit être désactivé lorsque : - aucun type n’est sélectionné ; - la date de collecte est invalide ; - le fichier sélectionné est absent. Une annulation ne doit créer : - aucun fichier ; - aucune ligne SQLite ; - aucune tâche de fond. ## Tests attendus ### EvidenceType - création valide ; - refus des arguments obligatoires invalides ; - getters ; - destruction avec valeurs facultatives absentes. ### EvidenceTypeDao - lecture de tous les types ; - ordre stable ; - correspondance correcte entre code et libellé ; - table vide ; - base ou table invalide. ### Validation du formulaire Extraire la validation des données dans une fonction testable sans afficher GTK. Tester : - valeurs valides ; - type absent ; - date absente ; - date invalide ; - champs facultatifs vides. ## Critères d’acceptation - les types sont lus depuis SQLite ; - aucun type n’est codé en dur dans GTK ; - le libellé est affiché à l’utilisateur ; - le code est transmis à l’importeur ; - les métadonnées sont enregistrées dans `preuves` ; - l’import reste asynchrone ; - l’annulation du dialogue ne démarre aucune tâche ; - tous les tests passent ; - compilation C17 avec `-Wall -Wextra -Werror`. ## Découpage technique 1. `EvidenceType` 2. `EvidenceTypeDao` 3. tests du DAO 4. `EvidenceImportDialog` 5. validation des champs 6. branchement dans `Application` 7. test GTK complet

fy59 closed this issue

2026-07-20 09:36:41 +02:00

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: fy59/labfy-investigation#51

No description provided.