Cas un peu compliqué où on crée une nouvelle note dans un champ "sauvegardable avec un bouton", comme la transcription .
On ajoute une note, on ne sauvegarde pas la transcription (ex: recharge la page).
La note existe bien mais l'appel de note non.

Sur la page d'une collection, dans le composant interactif de collection, afficher les responsables scientifiques de la collection :

• Uniquement sur les collections racines
• En fonction de l'Id de la collection en cours
• Codés en "dur"

Conformément à la maquette, afficher les personnes, lieux sous forme d'étiquettes :

Maquette personnes :

Maquette lieux (afficher Destination en dessous d'Expédition, comme pour les Personnes) :

Concernant la visionneuse, nous souhaitons adopter une approche similaire à Positions de thèses :

Desktop : lorsque la visionneuse est ouverte, afficher par défaut le texte à gauche et la visionneuse à droite :

Il serait intéressant d'utiliser également un toggle pour permettre d'afficher le texte seul, le texte et l'image ou l'image seule (toggle css, si oui, quelles classes css faire varier ?) :

Responsive : afficher la visionneuse d'une manière similaire à Positions de thèses mais en l'insérant sous le témoin, est-ce possible ?

Merci

le champ "analyse" plante lorsque je tape un chiffre suivi d'un point et d'un espace. Ex: si je tape "1. ", la page plante.

Bug Quill : la page plante (!) quand on saisit un chiffre suivi d’un point (^[0-9]\.) au début du premier paragraphe d’un champ.

La suppression d’un document doit être implémentée puis intégrée côté frontend sous la forme d’un composant (un bouton) intégrable à différents endroits de l’interface.

• Il faut être connecté avec le role admin pour avoir le droit de supprimer un document
• La suppression d’un document doit entrainer la suppression des dépendances associées (delete on cascade) : bookmarks, witnesses, changelog, notes, images

Page de gestion du référentiel des personnes : https://dev.chartes.psl.eu/lettres/persons

NB. Voir documentation chartes/lettres-app#77

Évolutions à discuter. Pour une personne, afficher :

• la liste de ses correspondants
• le nombre de lettres échangées
• la carte des lieux associés à la personne (lieu d’expédition si la personne est l‘expéditeur | lieu de réception si la personne est le destinataire).
• revoir l’affichage tabulaire (une ligne par type de contenu) : les filtres suffisent sans doute (à discuter).

Quid des personnes morales (organisations ?)

Supprimer l'affichage des colonnes Lieu d'expédition et Lieu de destination dans les résultats de la recherche (mode Tableau).

NB : conserver ces données en mode Déplié, ainsi que toutes les colonnes de la page /locks.
Cela fonctionnait avant les dernières mises à jour.

Merci

Cliquer sur les notes ne renvoie pas à leur contenu en bas de document
Le contenu des notes en bas de page ne contient pas d'id et n'est donc pas lié par une ancre aux appels de note

cf #69

Lettres, moteur de recherche

• Le moteur de recherche doit permettre prioritairement d’accéder aux documents (plutôt qu’aux occurrences d’un motif de recherche plein texte). Il s’appuie sur les métadonnées attachées à chaque document. La recherche plein texte vient en complément : le concordancier est "secondaire".
• Souhait d’un formulaire par défaut à 4 critères (1), complété par d’autres critères (2).

(1) Formulaire par défaut

Objectif

Il s’agit de la boîte de recherche qui doit être toujours accessible.

Objectif : lister tous les documents mentionnant une/des personne(s) ET/OU un/des lieu(x) ET/OU contenant une expression, pour une période définie.

Exemples de requêtes :

• Lister les lettres en lien avec Henri IV
• Lister les lettres en lien avec Henri IV ET Catherine de Médicis
• Lister les lettres en lien avec Senlis
• Lister les lettres en lien avec Senlis et Lille
• Lister les lettres en lien avec Henri IV ET Lille
• Lister les lettres en lien avec Henri IV ET Catherine de Médicis ET Senlis ET Lille
• Lister les lettres datées (expédiées) à partir de 1562
• Lister les lettres datées (expédiées) jusqu’à 1593
• Lister les lettres datées (expédiées) entre 1562 et 1593
• Lister les lettres datées (expédiées) entre 1562 et 1593, en lien avec Henri IV
• Lister les lettres datées (expédiées) entre 1562 et 1593, en lien avec Henri IV ET Catherine de Médicis ET Senlis ET Lille
• Lister les lettres dont la transcription contient le terme réformés?
• Lister les lettres dont la transcription contient le terme réformés?, en lien avec Catherine de Médicis
• Lister les lettres dont la transcription contient le terme réformés?, entre 1572 et 1573, en lien avec Catherine de Médicis ET Gaspard de Coligny ET Paris ET Blois

Filtres :

NB. On ne prend PAS en charge l’opérateur 'OU' ; la combinatoire est difficile à appréhender avec autant de filtres. "Lister les lettres en lien avec Henri IV ET Catherine de Médicis" : la collection des lettres où il est question des 2 personnages (et non pas de l’un OU de l’autre).

Il s’agit de filtres : on réduit le nombre de résultats (logique d’entonnoir).

Champs

1. Personne
2. Date de lieu
3. Date de temps
4. Content

1. Personne

Input avec autocomplétion pour sélectionner une personne décrite en base, quel que soit son statut : expéditeur (sender), destinataire (recipient) ou sujet (inlined).

On doit pouvoir sélectionner plusieurs personnes successivement.

La sélection active est affichée sous la forme d’un tag-filtre activé.

Remarques / questions :

• Dans le volet de recherche avancée, la sélection se retrouve réexprimée avec l’activation de 3 filtres, pour la même personne : expéditeur, destinataire, sujet
• Par défaut, permettre la sélection de plusieurs personnes ?
• Exemple de sélecteur : https://vuejsexamples.com/nova-4-filter-component-based-on-the-headless-ui-combobox-component/

2. Date de lieu

Input avec autocomplétion pour sélectionner une ville décrite en base, quel que soit son statut : lieu d’expédition (location-date-from), lieu de réception (location-date-to) ou sujet (inlined).

On doit pouvoir sélectionner plusieurs villes successivement.

3. Date de temps

Dans cette vue de base, un slider doit permettre de sélectionner l’intervalle entre 2 années.

Cf modèle ENCPOS (slider + 2 inputs pour spécifier une date).

4. Content

Input pour saisir une chaîne de caractères (regex).

(2) Formulaire étendu

Objectif

Il s’agit :

• d’affiner certains filtres (par ex. pouvoir préciser une date au jour près) ;
• de fournir de nouveaux filtres.

Exemples de requêtes :

• Lister les lettres dont Catherine de Medicis est l’expéditrice d’avril 1572
• Lister les lettres dont la transcription contient le terme réformés? et cite Gaspard de Coligny entre 1572 et 1573
• Lister les lettres dont la transcription contient le terme réformés? et mentionne Gaspard de Coligny en date du 14 avril 1572 expédiées depuis Blois.
• Lister les lettres dont la transcription contient le terme réformés? et le paratexte éditorial (notes et analyse) contient le terme protestant.
• Lister les lettres dont la transcription mentionne Gaspard de Coligny et dont Catherine de Médicis est la destinataire.
• Lister les lettres dont un témoin est conservé à la BnF.
• Lister les lettres dont la transcription mentionne Gaspard de Coligny, dont Catherine de Médicis est la destinataire en 1572 et dont un témoin est conservé à la BnF.
• Lister les lettres dont la transcription mentionne Gaspard de Coligny, dont Catherine de Médicis est la destinataire en 1572 en allemand.
• Lister les lettres dont un témoin est conservé à la BnF dans le volume coté Fr. 3205.

Champs

1. Personne
   1. Expéditeur
   2. Destinataire
   3. Sujet
2. Date de lieu
   1. lieu d’expédition
   2. lieu de réception
   3. sujet
3. Date de temps
4. Content
   1. Transcription
   2. Note
   3. Titre ?
   4. Analyse ?
5. Langue du document
6. Institution de conservation
   1. • cote

Personne

Input avec autocomplétion pour sélectionner une personne décrite en base SELON son statut : expéditeur (sender), destinataire (recipient) ou sujet (inlined).

On doit pouvoir sélectionner plusieurs personnes successivement.

La sélection active est affichée sous la forme d’un tag-filtre activé.

Date de lieu

Input avec autocomplétion pour sélectionner une ville décrite en base SELON son statut : lieu d’expédition (location-date-from), lieu de réception (location-date-to) ou sujet (inlined).

On doit pouvoir sélectionner plusieurs villes successivement.

Date de temps

Dans cette vue de base, un slider doit permettre de sélectionner l’intervalle entre 2 dates exprimées au jour près.

Cf modèle déployé dans la recherche avancée de l’application en développement.

Content

Input pour saisir une chaîne de caractères (regex).

Pouvoir activer la recherche floue (ex. du DicoTopo pour le réglage de la fuzziness).

Langue du document

Sélecteur pour la/les langue(s) de la lettre (document_has_language.language_id).

Institution de conservation

Sélectionner une institution de conservation (sélection d’une valeur de institution.name).

Pouvoir saisir une cote (recherche plein texte dans witness.classification_mark)

Visualisation des résultats

• Liste simple (comme version actuellement déployée enrichies de l’expéditeur et du destinataire)
• Pouvoir déplier l’analyse
• Pouvoir en cas de recherche Content afficher les occurrences (modèles ENCPOS)
• TODO. Spécifier les filtres à afficher pour affiner la réponse (cf EMLO)
• TODO. Imaginer une vue cartographique (3 types de lieu…)
• TODO. Imaginer pour chaque personne le graphe de ses correspondants (rebond depuis un tag vers une notice d’autorité ?)

Fonctionnalités

• conserver dans la session le résultat de la dernière recherche (recherche courante)
• fournir un lien pour chaque recherche
• export des résultats ? => une liste ? quel formatage ?
• pouvoir rechercher des lettres selon un ark Gallica ? Lister toutes les lettres contenues dans un document Gallica identifié par son ark ?

NB. OP écarte l’idée de proposer un filtre par (sous-)collection

Problèmes

mise en cohérence des formulaires (1) et (2)

Exemple du statut des personnes : par défaut (1), on sélectionne une personne quel que soit sont statut. Dans la vue de résultats, ce filtre peut être réexprimé sous la forme de 3 filtres : par ex. le tag sélectionné Catherine de Médicis sera affiché 3 fois, sous les 3 catégories (Expéditeur, Destinataire et Sujet) ; possiblement déselectionnable…

Du coup, un résultat affiché pourra ne plus correspondre à la requête formulée dans le formulaire par défaut.

Bref, on bascule facilement du formualaire (1) au formulaire (2), mais le chemin inverse pose problème.

Point à discuter.

Vue 1

Vue 2

Localistion du problème : Création d'un nouveau document via la route /document-creation :

Comportement actuel :
Un utilisateur connecté peut créer un nouveau document via le menu user (en haut à droite) "Créer un nouveau document".
Un formulaire (route /document-creation) permet d'en créer le titre (seul élément requis à ce stade), puis l'application charge ce nouveau document (/documents/nouvel Id du document créé).

• Sans ouverture d'un document au préalable lors de la session :
  Le nouveau document affiché est vierge, ce qui est le comportement attendu dans tous les cas de figure.

• Si un document a déjà été consulté lors de la session en revanche, certaines données de ce dernier sont reprises :

Ici, la date de rédaction, l'étiquette, l'analyse, l'adresse et la lettre sont issues du document consulté au préalable, ce qui n'est pas souhaité.

Comportement souhaité :
Dans tous les cas de figure, un nouveau document ne doit contenir que des données non renseignées, à l'exception du Titre validé et de la Collection défaut.

Edition d'une lettre :

erreur d'affichage des correspondances et ouverture du RichTextEditor sur la transcription (adresse et transcription) si cette dernière n'est pas disponible.

Gérer l'affichage du breadcrumb des collections:

• alignement de l'icône de suppression des collections associées (mode édition)

• amélioration de l'affichage du breadcrumb (chemin de la collection) :

  • réduction de la police ?
  • chaque breadcrumb encadré ?
  • meilleure séparation des lignes (plus d'espace entre les breadcrumbs, par rapport aux sauts de ligne éventuels dans un breadcrumb)

• Hors-connection :

• Mode éditeur :

Merci

Rappel : filtrer les collections est l'un des développements nécessaires discutés à l'issue #14.

Rechercher / filtrer parmi les collections

Développements nécessaires :

• Ajout d'une boite de recherche pour filtrer les collections :

  • pour tous les users connectés (quel que soit leur statut) et non connectés

• Affichage des résultats :

  • présenter les cartes simplifiées des (sous-)collections correspondantes au motif de recherche, à plat (quel que soit leur niveau hiéarchique)
  • voir notre illustration n°5 à #14 (comment)

• Ajout de tris : TBD

Le bouton nouveau témoin (+) est le seul à apparaître pas lorsque la section Témoin est repliée (contrairement aux autres sections) :

• le déplacer au dessus des témoins dans la même div ? ou
• le rendre invisible lorque la section est repliée ?

Merci

En mode édition :

aligner les textes à gauche sur la règle rouge ci-dessous, en particulier la transcription actuellement décalée à droite, notamment en supprimant l'icône de cette vue (elle n'est attendue que sur les prévisualisations des résultats de recherche).

Affichage du verrou fermé non fonctionnel :

• Edition d'une lettre : le cadenas n'est pas fermé, ni coloré, alors que le document est verrouillé
  

• Recherche : idem

Merci

Rappel : l'ajout et l'édition d'une collection est l'un des développements nécessaires discutés à l'issue #14.

Ajout, Gestion des (sous-)collections

Développements nécessaires :

• construire le formulaire de création / édition de (sous-)collections.

• pour les seuls admin.

• le formulaire doit être éditable par tout user admin, comme la mise à jour de la description.

• le formulaire consiste en : voir #14 (comment).

  • éléments propres à la collection :
    • titre (obligatoire, champ de texte)
    • "administrateur" (obligatoire, sélection d'un administrateur)
      NB : il serait nécessaire de pouvoir sélectionner / éditer l'administrateur associé à une (sous-)collection car c'est celui qui apparaîtra en tant que "Curated by ..." sur la page. Voir le comment : #14 (comment)
    • description (optionnel, champ de texte)
    • NB : les dates associées à la (sous-)collection créée ne sont pas éditables (calculées à partir des documents associés). En l'absence de documents à la création, les attributs date_min et date_max = leur valeur défaut et gérés côté Front pour afficher "na" ou "Non renseigné".

• gérer relations parents/enfants d'une nouvelle collection (sur la base de la maquette) :
  NB : voir #14 (comment), #14 (comment).

• page /collections/ :

  • une collection racine est ajoutée à partir de l'URL /collections seulement (image 1 de la pj)

• page /collections/id :

  • une sous-collection est ajoutée à partir l'URL /collections/id de son parent (image 3 de la pj)

• redirection à l'issue de la création :
  NB : le comment #14 (comment)

• Renvoyer vers la collection nouvellement créée

Rappel : l'ajout de lettres à une collection est l'un des développements nécessaires discutés à l'issue #14.

édition d'un document pour éditer son(ses) lien(s) vers une(des) collection(s) :

Développements nécessaires :

• pour les users connectés admin et contributeurs

• l'ajout d'un document à une collection met à jour la liste des collections auxquelles il est rattaché dans la section "Collections" de sa page /documents/id :
  

• ajouter à la page /documents/id/ (section "Collections") un sélecteur de collection(s)

  • liste déroulante (none|toutes les collections disponibles, à plat)
  • pouvoir sélectionner plusieurs (sous-)collections

Rappel : la suppression d'une collection est l'un des développements nécessaires discutés à l'issue #14.

Suppression des (sous-)collections

Développements nécessaires :

• ajouter pour les admin un bouton de suppression de (sous-)collections.

• suppression de la collection mais SURTOUT PAS des lettres associées !

• droits : tout user admin peut supprimer des (sous-)collections.

• au moment de la suppression, gestion de la migration des lettres (voir #14 (comment)) :

• page /collections/ :

  • la collection supprimée est collection racine : supprimer la collection, et lier les documents à une collection "fantôme" (qui remplacerait Catherine de Médicis comme collection "défaut"). Voir
    #14 (comment)

• page /collections/id :

  • les lettres d’une sous-collection restent dans la collection de niveau supérieur (par rapport à la collection supprimée uniquement : elles restent attachées aux autres (sous-)collections auxquelles elles appartiennaient par ailleurs et qui ne sont pas impactées par la suppression)
  • la collection supprimée a des enfants (voir #14 (comment)) : à confirmer entre
    • erreur dans l'interface
    • rattachement de toutes les lettres de ces enfants au niveau supérieur du noeud supprimé (e.g. la supression d'une (sous-)collection signifie qu'il n'est plus pertinent de conserver sa structure et ses enfants)

NB : pas d’impact sur indexation, puisqu’on fait le choix de ne pas proposer de filtre par collection sur la recherche.

Les colonnes Lieu d'expédition / Lieu de destination d'un résultat de recherche (mode Déplié) ne sont pas alignées d'un résultat à l'autre :

Merci !

Corriger l'affichage du renvoi à la ligne automatique du lieu d'expédition :

Merci

D'une manière générale : réduction substantielle de la taille des boutons, trop imposants par rapport au texte actuellement :

Merci

Achever la page '.../documentation' de l'application :

• Implémenter la documentation

• Implémenter la charte graphique

L'ajout de la fonctionnalité de la suppression d'une collection a été ajouté en réponse à l'issue #25 .

Il conviendrait d'ajouter un modal de confirmation avant d'effectuer une telle opération de suppression.

• Ajouter un bouton d'édition sur les lettres au lieu d'ouvrir les éditeurs par défaut (sauf users non connectés) :
  

• Caler les boutons

Achever la page '.../document-creation' de l'application :

• Ajouter un titre "CRÉER UN NOUVEAU DOCUMENT" (similaire à la page /bookmarks, voir ci-dessous) :
  

• Etablir les données par défaut d'un nouveau document :

  • Seul le titre est obligatoire : ajouter un sous-titre "Renseigner le Titre du document"
  • Ajouter une validation (Titre est une chaîne de caractère non vide)

• Implémenter la charte graphique

Implémenter les suggestions (page recherche avancée) :

Rappel : la présentation de la structure d'une collection est l'un des développements nécessaires discutés à l'issue #14.

Présentation des collections sous forme d’arbre (2) sur la page d'une (sous-)collection /collections/id/

Développements nécessaires :

• Affichage une colonne « Arbre de la collection » :
  • arborescence simplifiée de la collection (Titre seul)
  • depuis le niveau racine
  • dépliée avec indication du niveau courant
  • voir nos illustration n°3 et 4 à #14 (comment)
  • pour tous les users connectés (quel que soit leur statut) et non connectés

• lister (pour l’instant dans cette issue) les abréviations utiles (institutions, fonds, cotes, éléments de texte comme titres protocolaires, etc.)
• ajouter ce dictionnaire au projet
• prévoir un accès direct pour les utilisateurs authentifiés

Edition d'une lettre :

la sauvegarde d'un RichTextEditor sans données renvoie la valeur "" (chaîne vide) en base au lieu de null (valeur par défaut).

Changer le comportement de src/components/forms/fields/EditorSaveButton.vue pour renvoyer une valeur nulle au lieu d'une chaîne vide.

Concevoir la partie gestion de collection

Ce ticket se décompose désormais comme suit :

• #24
• #25
• #28
• #26
• #27
• #29

L'historique des discussions sur l'issue 14 avant son découpage est conservé ci-dessous pour référence.

Supprimer les fichiers copiés du projet Adèle qui ne servent pas à ce projet.

• Boutons en bas à droite hors-champs :
• Lieux

• Témoins :

Supprimer les sauts de lignes aux balises dans l'affichage du texte dans les prévisualisations (/search) :

La présence de balises (saut de page, persName, placeName, note etc) semble causer un saut de ligne dans la version preview :

Résultats de la recherche : la prévisualisation semble engendrer plus de requêtes API que nécessaire

Optimiser :

Rappel : la présentation de la structure d'une collection est l'un des développements nécessaires discutés à l'issue #14.

Présentation des collections sous forme d’arbre (1) sur la page racine /collections/

Développements nécessaires :

• bouton « Parcourir la collection »
  • pour tous les users connectés (quel que soit leur statut) et non connectés
• ce bouton affiche une arborescence simplifiée de la collection :
  • Titre, nombre de lettres
  • depuis le niveau racine
  • repliée par défaut
  • voir notre illustration n°2 à #14 (comment). NB : Même arbre à afficher sur une liste de résultat comme celle de l'illustration n°5 (e.g. depuis la racine, pour chaque résultat).

Pouvoir feuilleter (prev/next) les lettres d’une même collection : pouvoir éditer la lettre précédente / suivante.

Dans la perspective de la première mise en production :

• Finaliser l'implémentation de la maquette :
  • #44
  • #70
  • #71
  • #84
  • Finaliser le maquetage des pages :
  • #45
  • #46
  • #47
  • #77
  • #105
  • Supprimer les éléments exclus de la V1 :
    • Voir aussi #66
    • Page dédiée Gestion des témoins '.../witnesses'
    • Page dédié Gestion des users ? '.../users'
  • Prévoir les icônes par défaut (collection sans illustration)
  • Calage des boutons :
    • #50
  • #79
  • Compacter légèrement le contenu des pages documents notamment '.../documents/{id}' (padding)
  • Finaliser la version responsive
  • Corrections des bugs (affichage) :
    • #48
    • #51
    • #52
    • #53
    • #54
    • #55
    • #56
    • #57
    • #58
    • #59
    • #60
    • #61
    • #73
    • #74
    • #75
    • #78
    • #80
    • #81
    • #82
    • #83
    • #85
    • #87
    • #88
    • #89
    • #90
    • #91
    • #92
    • #100
    • #131
• S'assurer du fonctionnement correct des éléments du Front (boutons, etc) :
  • #11
  • #62
  • #63
  • #64
  • #65
  • #76
  • #104
  • #130
• Corrections éditoriales :
  • #86
  • #129

Les éléments à l'intérieur des sections d'un document doivent être alignés.

Concernant la section Titre, on observe un décalage à droite du titre de la lettre et de "Langue" par rapport aux autres sections :

Il en va de même pour la section Témoins léger décalage trop à droite pour le texte du témoin et les statuts :

Merci

Achever la page '.../about' de l'application :

• Basculer le menu à gauche : cd DicoTopo:
  

• Implémenter la charte graphique

Résultats de la recherche (mode tableau et déplié, sans motif de recherche) :

la prévisualisation d'une lettre engendre une erreur :

-> raison : function truncate de DocumentTranscription.vue pour l'obtention de l'extrait de transcription

si aucune transcription n'est pas disponible.

Les notes devraient apparaître avec leur numéro de note relatif au document.
Faire attention à mettre à jour ce numéro pour toutes les notes (qui n'existe que côté frontend) quand on supprime des notes.

PopUp Témoins / Sélection images (URL de la ressource) :

• centrage du tilde vert de validation / wrap texte

• Boutons en bas à droite hors-champs (cf #60)

• Zone d'affichage des images hors-champs (bloc noir en haut)

Merci

Concernant le bouton sauvegarde de l'édition d'une collection (page '.../collection/{id}'):
le bouton actuel sert à sauvegarder les changements sur différents champs (titre, curateur etc.), ce que la maquette n'a pas prévu :

-> avoir un seul bouton de sauvegarde à côté du bouton supprimer en haut ?

Appliquer la maquette à la page .../forgot-password:

Autoriser les listes ordonnées pour le champ analyse

Edition d'une lettre : problème d'affichage vertical du texte des dates (erreur apparaissant par intermittence ?) :

Merci

Sur la page d'une collection, afficher les la description détaillée (historique, contributeurs, biblio) de la collection :

• Uniquement sur les collections racines
• En fonction de l'Id de la collection en cours
• Codés en "dur"

Les entités nommées (personnes, lieux) sont actuellement étiquetées manuellement par des utilisateurs au sein de l’éditeur de texte riche QuillJS à l’aide des balises persName et placeName.
L’application lie correctement un identifiant à une portion de texte mais ne crée pour le moment qu’un lien html factice qui ne permet, ni d’identifier facilement la cible du lien (nom de la personne ou du lieu), ni d’accéder à la notice d’autorité de l’entité concernée.

Objectif : concevoir un moyen d’afficher un composant au survol des entités permettant d'afficher :

• Des informations complémentaires concernant l'entité
• un lien cliquable menant à la page de notice (tbd) de l’entité
• En mode édition (utilisateur connecté), des boutons d’action supplémentaires :
  • supprimer la liaison entre la portion de texte et l'entité
  • ouvrir le formulaire d’édition de l’entité

Attention, l’utilisation de popup/tooltip via l’insertion de balises autour des entités ne doit pas entrer en conflit avec QuillJS. De plus, ces balises ne doivent pas être sauvegardées.