Bienvenue dans la documentation d'Ishtar !¶

Contents:

Installation¶

Auteur:	Étienne Loks
Date:	2020-09-23
Copyright:	CC-BY 3.0

Ce document présente les instructions d'installation d'Ishtar.

Pour l'instant, elles se limitent à l'installation sous Debian GNU/linux via le paquet Debian.

Un nom de domaine dédié est nécessaire pour chaque instance (une instance Ishtar n'est pas installable dans un sous-répertoire). Par contre un sous-domaine est tout à fait utilisable (par exemple : ishtar.mon-domaine.net).

Note

Sauf mention explicite, chaque commande est exécutée en tant qu'utilisateur root. Les utilisateurs de sudo l'ajouteront à chaque commande faite.

Installation sur poste Debian Buster¶

Un dépôt a été mis en place pour installer sous Debian Buster. Ce dépôt est signé, pour ajouter la clé du dépôt à votre gestionnaire de paquet, lancez la commande

wget -O - http://deb.iggdrasil.net/contact@iggdrasil.net.gpg.key | apt-key add -

Puis, au choix, ajoutez le dépôt à votre /etc/apt/sources.list

deb http://deb.iggdrasil.net/apt/debian/ buster main
deb-src http://deb.iggdrasil.net/apt/debian/ buster main

Ou sauvegardez le fichier iggdrasil.list dans votre répertoire /etc/apt/sources.list.d/

wget -O - http://deb.iggdrasil.net/apt/debian/dists/buster/iggdrasil.list > /etc/apt/sources.list.d/iggdrasil.list

Ensuite mettez à jour la base de données de votre gestionnaire de paquet et installez le paquet

apt-get update
apt-get install python3-django-ishtar

Deux paquets optionnels peuvent être installés :

ishtar-tasks : installe un service de tâche pour gérer en tâche de fond les opérations longues (par exemple les imports). Cette installation est conseillée si vous n'êtes pas juste en ressources serveur.
ishtar-libreoffice : installe libreoffice en mode serveur pour faciliter des imports / exports aux formats bureautique. Ce service permettra notamment à terme de gérer les formats Office Open XML de la suite Microsoft Office. Peu utilisé pour le moment, l'installation de ce paquet est tout à fait optionnelle.

Enfin pour créer une nouvelle instance d'Ishtar

ishtar-prepare-instance

Un ensemble de questions vous sera posé afin de déterminer les paramètres qui concernent cette instance.

Note

Le nom de domaine doit bien entendu pointer vers l'adresse IP du serveur. Si à l'issue de l'installation, le service n'est pas joignable, verifiez bien votre configuration DNS ou le cas échéant verifez bien auprès du gestionnaire de nom de domaine que c'est le cas.

Avertissement

En terme de serveur Web, cette première version de l'installateur fonctionne avec la configuration que nous considérons comme la plus optimisée qui est le couple nginx / uwsgi. À terme, l'installateur prendra aussi en compte Apache. Pour l'instant, si vous avez des services tournant sous Apache, plusieurs options se présentent à vous :

faire tourner nginx sur un autre port ;
faire fonctionner vos autres services avec nginx (je vous laisse découvrir l'abondante documentation en ligne en cherchant « nginx + le nom de mon service ») ;
configurer Ishtar pour fonctionner avec Apache (référez vous à la documentation de Django).

L'installateur vous demandera un identifiant / mot de passe pour le compte administrateur. Une fois l'instance préparée une base de données a été crée avec un nom du type ishtar-le_nom_de_mon_instance (ou le nom que vous avez spécifiquement donné), Ishtar est joignable à l'adresse donnée par la variable URL et les données de cette instances sont stockées dans le répertoire /srv/ishtar/le_nom_de_mon_instance.

Initialisation de la base de données¶

Ishtar dispose de beaucoup de tables de paramétrage permettant d'avoir un logiciel au plus proche de vos besoins. Remplir toutes ces tables est fastidieux, c'est pour cela que des jeux de données de base sont disponibles. Lors de l'installation du paquet, à l'exception des communes (trop lourdes pour être inclues de base), cette initialisation est faite. Si vous avez opté pour cette installation vous pouvez passer tout de suite à l'initialisation des communes.

Initialisation des paramètres de base¶

Pour charger toutes les données par défaut

ISHTAR_PATH=/srv/ishtar # dépend de votre installation
PROJECT_PATH=$ISHTAR_PATH/mon_instance
cd $PROJECT_PATH
for data in $(find ../ -name "initial_*-fr.json"); do
    ./manage.py loaddata $data
done

Sinon regarder le détail de chaque fichier json et charger individuellement. Exemple

cd $PROJECT_PATH
./manage.py loaddata ../ishtar_common/initial_importtypes-fr.json

Initialisation des communes¶

Une liste des communes française peut être téléchargée et chargée

cd /tmp
wget "http://ishtar-archeo.net/fixtures/initial_towns-fr.tar.bz2"
tar xvjf initial_towns-fr.tar.bz2

ISHTAR_PATH=/srv/ishtar # dépend de votre installation
                        # ici pour le paquet Debian
PROJECT_PATH=$ISHTAR_PATH/mon_instance
cd $PROJECT_PATH
./manage.py loaddata /tmp/towns_norel-fr.json
./manage.py loaddata /tmp/towns-fr.json
rm /tmp/initial_towns-fr.tar.bz2
rm /tmp/towns-*

Sinon un script est mis à disposition pour charger des communes depuis des données OSM : $ISHTAR_PATH/scripts/import_towns_from_osm.py.

Lisez les instructions contenu dans le fichier pour savoir comment procéder.

Principes¶

Auteur:	Étienne Loks - Valérie-Emma Leroux - Yann Le Jeune
Date:	2020-11-23
Copyright:	CC-BY 3.0

Ce document présente les grands principes qui structurent Ishtar.

Présentation¶

Présentation générale¶

Ishtar est un projet de gestion de base de données visant à gérer les données et la documentation (mobilier inclus) provenant d'opérations archéologique, publié sous la forme d'un logiciel libre sous licence AGPL 3.0 (ou supérieure).

L'objectif est d'assurer une traçabilité maximale des informations afin de faire vivre cette documentation et la rendre même éventuellement accessible au public ou encore à un (ou des) groupe(s) d'utilisateurs.

Ce logiciel a vocation à être installé sur un serveur web mais peut également fonctionner en local, à l'échelle d'un chantier, d'une commune ou d'une région entière.

Conçu afin de permettre une communication inter-bases, le projet Ishtar vise plutôt un modèle d'information distribué que centralisé : la communication entre les bases est favorisée.

Il est organisé autour d'un tronc commun associé à des modules liés à des besoins « métiers » spécifiques : administration des opérations et inventaires, lieux de conservation, traitements liés aux laboratoires de restauration, analyse stratigraphique avancée, étiquetage QR-code, etc.

De multiples niveaux d'utilisateurs sont possibles, d'un accès pour le public (ou non) à des accès pour chercheurs, responsables d'opérations, gestionnaires de CCE, connexion avec un SIG, etc.

Voici quelques exemples des usages possibles (liste non exhaustive) pour la gestion des données :

d'une opération programmée ou préventive (une instance pour une opération ou une série d'opérations) gérée à l'échelle de l'équipe de recherche associée : gestion des données, mise en commun, production automatique d'inventaires conformes, export et import d'inventaires avec des spécialistes, gestion des relations stratigraphiques, etc. ;
d'une association de bénévoles : enregistrement des résultats de chacun dans une base commune ;
à l'échelle d'un service régional de l'archéologie : gestion des inventaires mobilier, opérations, dossiers d'urbanisme, rapports, dépôts, production d'arrêtés et de courriers, base de connaissances régionale, etc. ;
pour un service de collectivité territoriale : suivi des opérations, gestion de l'ensemble des données et mise à disposition du public et chercheurs ;
pour un laboratoire de restauration : gestion fine des traitements et traçabilité maximale du mobilier (tout l'historique des traitements est conservé) ;
pour un PCR : plate-forme de synthèse des données collectées et valorisation du travail effectué par l'ouverture au public de la base une fois le PCR achevé ;
pour des étudiants : base de données gratuite, utilisant des normes standardisées, possibilité de mettre en commun son travail avec d'autres, de le faire suivre par des tuteurs ou encadrants ;
etc.

Fonctionnalités¶

La version actuelle permet d'accomplir les tâches suivantes :

saisie des opérations,
saisie des unités d'enregistrement (UE),
saisie du mobilier archéologique,
association à de la documentation,
production automatique d'inventaires conformes (UE, mobilier, documents),
gestionnaire de médias (stockage et gestion des photos, pdf des rapports, etc.),
personnalisation des formulaires (ajouts de champs personnalisés, choix de l'affichage des champs Ishtar),
imports paramétrables et archivables, incluant éventuellement les liens vers des images, depuis des fichiers tabulaires (format csv, fichier zip pour les images),
recherche avancée (recherche plein texte et par critère, enregistrement de recherche, gestion d'alertes),
exports (csv) suite à une recherche ou par élément sélectionné (opération, UE, mobilier),
production de documents formatés (patrons au format odt),
production de fiches types pour les opérations, UE ou mobilier (format odt et pdf),
tableau de bord produisant automatiquement des statistiques et des graphiques,
connexion (jointure) avec un SIG (testé avec QGIS),

Module administratif¶

saisie des dossiers,
ajout d'actes administratifs (courriers, arrêtés, etc.),
production automatique de courriers administratifs (accusés de réception, etc.),

Module lieux de conservation¶

gestion des mouvements de mobilier,
production automatique de documents tels conventions de prêts, fiches d'état, etc.
conditionnement,
sélection par « panier »,
gestion des contenants et étiquetage : il n'est pas prévu qu'Ishtar génère directement des étiquettes (pdf) mais plutôt des fichiers csv pouvant être utilisés selon tout format d'étiquette via « publi-postage » dans un logiciel tiers (libre-office, excel, etc.).

Modules / configuration¶

Selon le périmètre fonctionnel dans lequel Ishtar est utilisé, il convient d'activer ou désactiver certains modules. Ces modules permettent d'accéder à plus ou moins de fonctionnalités d'Ishtar, de faire apparaître des champs sur les formulaires, de présenter différemment les données, etc.

Note

L'activation / désactivation d'un module ne change jamais la structure des données. Il est tout à fait possible d'activer ponctuellement un module sans que cela n'altère les données en base.

Des dépendances entre modules existent. Ces dépendances sont logiques et se comprennent aisément si l'on a intégré la structure de la base de données d'Ishtar (cf. Structure de la base de données). En cas de doute, si une dépendance est manquante lors de l'activation du module un message explicite est donné.

L'activation des modules est faite en administration sur la page de configuration d'instance Ishtar (cf. documentation administrateur).

Par ailleurs au niveau de la configuration d'instance Ishtar un certain de nombre de paramètres de fonctionnement Ishtar peuvent être ajustés. Ceux-ci sont détaillés dans la documentation administrateur.

Avertissement

Contrairement à l'activation des modules, certains paramètres ont une incidence importante sur les données stockées dans Ishtar, notamment en ce qui concerne la gestion des identifiants mobiliers, des identifiants documents, etc. En tant qu'administrateur, si vous souhaitez une configuration différente de la configuration par défaut d'Ishtar, il est nécessaire de modifier ces paramètres en amont.

Structure de la base de données¶

La base de données n'est pas détaillée table par table dans cette documentation mais nous allons vous présenter les grandes notions utilisées. La structure présentée peut apparaître rigide mais c'est un mal nécessaire pour une certaine standardisation de données archéologiques. Par ailleurs les concepts sont très larges et d'expérience s'adapte très bien à la plupart des contextes.

Opération archéologique¶

L'opération archéologique est le cœur du modèle de données d'Ishtar. Au sein d'Ishtar, l'opération archéologique est définie comme une action (ou un projet d'action) permettant d'acquérir des données archéologiques, sous la responsabilité d'une personne (exemples : découverte fortuite, diagnostic, fouille programmée, prospection, etc.) et dans un lieu si possible défini.

Si l'opération est au centre du modèle de données d'Ishtar plutôt que le site ou l'entité archéologique, c'est parce que ce dernier est une interprétation (comme toute interprétation, sujette à évolution dans le temps) des données, alors que l'opération est l'information qui permet au mieux de regrouper un corpus documentaire cohérent mettant en lien des documents (plans, rapports, photos, etc.) et du mobilier.

Il est possible de créer des liens entre des opérations, soit en les associant à un même dossier source (avec le module « administratif », ex. : un permis de construire qui est associé à un diagnostic et une fouille préventive), soit en définissant une relation entre des opérations globales (ex. : PCR, suivi d'autoroutes, etc.) et d'autres plus ponctuelles (phases, tranches, secteurs, etc.). Le regroupement d'opérations est également pratique en contexte de fouilles programmées, où il peut être utile d'avoir des inventaires pour chaque opération par année, mais également une vision globale de la succession des fouilles (opération globale). En contexte de grande opération préventive, ce système peut servir à individualiser des secteurs de fouilles disposant de modes d’enregistrements spécifiques. L'utilisateur a toute latitude pour organiser les opérations entres elles selon ses besoins, du moment que ces éléments clefs représentent bien des lots documentaires et mobilier a priori cohérents.

Site/entité archéologique¶

Malgré le choix de l'opération comme rôle central de son modèle de données, Ishtar gère pleinement les sites (ou entité - notion paramétrable en administration) archéologiques et la migration depuis une base orientée site est tout à fait envisageable.

Parcelle¶

Les parcelles sont gérées précisément au sein d'Ishtar en étant directement rattachées aux UE. Cela permet de faciliter la gestion des questions légales concernant le mobilier (réalisation du « partage » ou responsabilité en cas de restauration). Si la parcelle de l'UE n'est pas connue ou si elle n'est pas sujette a contrainte légale, il est possible d'associer une parcelle virtuelle ou de ne pas renseigner ce champ.

Unité d'enregistrement¶

La notion d'Unité d'enregistrement (UE) est à prendre comme un concept large. Elle se définit comme étant un volume (ou une surface) référencé dans l'espace (précisément ou non), associé à des informations archéologiques et contenant (ou pas) du mobilier. La proue du navire, la tranchée 3, la structure ST25, l'US137 ou le quart NE du carré A3 sont tous des UE valides pour Ishtar.

Ishtar gère les relations entre UE. Cela permet notamment de définir des UE emboîtées (par exemple : tranchée > structure > US) mais aussi de gérer les relations stratigraphiques entre US.

Mobilier - Traitement¶

Un traitement est défini comme une action portée par un responsable sur du mobilier archéologique dans un lieu donné. Dans ce cadre, un lavage, une restauration, un prélèvement pour analyse, une radiographie, une étude, un conditionnement, un prêt pour exposition ou une mise en dépôt sont tous des traitements (que le gestionnaire de mobilier est libre d'enregistrer ou non).

Un traitement peut mener à ce que plusieurs objets ou lots deviennent un seul lot ou objet (un remontage par exemple : N à 1), ou à l'inverse qu'un objet suite à un traitement en devienne plusieurs (1 à N).

Le mobilier tel qu'habituellement compris se découpe en deux sous-éléments au sein d'Ishtar :

le mobilier d'origine ;
le mobilier (actuel).

Le mobilier d'origine comprend les informations invariantes tout au long de la vie de l'objet, telle que son contexte de découverte, son inventeur, etc. Le mobilier actuel (généralement juste appelé « mobilier » au sein d'Ishtar) permet de caractériser l'objet tout au long de sa vie.

Le distinguo entre de ces deux notions permet notamment une gestion fine des traitements simples (destructif ou non) et complexes (tri, remontage, etc.) avec une connaissance précise de l'historique de l'objet (lieux, responsables et documentations peuvent être associées à chaque traitement).

Sur la figure ci-dessous chaque « Fiche mobilier » correspond à un élément « mobilier actuel » en base de données. Chaque élément et chaque traitement a une fiche associée.

Mobilier - Demande de traitement¶

La gestion des demandes de traitement au sein d'Ishtar est prévue pour permettre d'archiver les documents liés à toute demande ou préparation de traitement. Elle permet de générer automatiquement des documents liés à chaque contexte.

Par exemple, lors de la réception d'une demande de prêt de mobilier pour une expo, créer une demande de traitement dans Ishtar permet d'enregistrer la demande, puis de générer automatiquement (selon les modèles définis sur l'instance) une réponse de refus ou au contraire une convention de prêt (à la suite de quoi, une fois la convention dûment signée, l'on créera le traitement Prêt associé).

Lors d'un besoin de restauration, créer une demande de traitement dans Ishtar permet de générer une demande de devis, puis éventuellement d'archiver les devis reçus, avant de créer le traitement Restauration avec le prestataire choisi.

Contenant¶

La notion de Contenant est très générique. En effet, un étage, une salle, une étagère sont des contenants au même titre qu'une boîte. Chaque contenant peut contenir du mobilier ou de la documentation mais aussi d'autres contenants. Chaque type de contenant peut être qualifié de mobile (ex : caisse, boîte, carton, palette) ou immobile (ex : étage, salle, travée, étagère, vitrine).

Document¶

Les documents sont gérés de manière transversale et peuvent être librement associés à un ou plusieurs éléments (opération, site, UE, traitement, mobilier, etc.) de la base de données. Des méta-données peuvent être renseignées pour chacun de ces documents et une image et/ou un fichier peuvent être le cas échéant adjoints.

Les flux de données¶

Pour alimenter Ishtar en données, on distingue 3 modes opératoires :

l'import,
l'ajout/modification par formulaire,
la modification par lot.

Chacun de ces modes offrent avantages et inconvénients qu'il faut avoir en tête pour utiliser Ishtar de manière optimale.

Import¶

Mode opératoire¶

Cela consiste en l'import de données dans Ishtar depuis un fichier « tableur » (format CSV).

Un « importeur » est utilisé afin d'extraire les données de ce fichier.

Cet « importeur » définit plusieurs choses, en particulier :

quel est le type de données à importer (des opérations, du mobilier, de la documentation, etc.) ;
un ordre de colonne précis ;
quelles sont les colonnes obligatoires ;
des formats de données attendus pour chaque colonne ;
une correspondance entre colonnes et champs de base de données (sachant que certains champs peuvent être constitués d'une concaténation de plusieurs colonnes) ;
des données par défaut ;
etc.

Une fois un fichier d'import rempli, depuis l'interface Ishtar, on procède à l'import effectif. Celui-ci se déroule en plusieurs phases :

création d'un import (où l'on spécifie le nom, le type d'importeur, le fichier à importer, etc.).
analyse du fichier à importer : Ishtar vérifie la cohérence de base du fichier et désigne d'éventuelles entrées à rapprocher.
rapprochement entre des entrées du fichier du tableur et des listes de types fixes d'Ishtar : une table de correspondance est créée.
import effectif des données.

Atouts¶

Ce mode opératoire permet d'utiliser en amont des outils externes pour le raffinage des données (exemple : OpenRefine).
Les rapprochements permettent aussi une mise en correspondance facilitée des données.
La personne qui fournit les données n'a pas besoin de compte sur Ishtar : l'import peut être fait par un gestionnaire de données qui en amont fournit un exemple de fichier ou alors remodèle les données sources pour correspondre à l'importeur.
Dans le cadre d'intégration de données externes, le fichier d'import demeure afin de pouvoir ainsi remonter à la source des données et conserver l'historique.

Inconvénients¶

Ce mode opératoire nécessite la création d'un importeur qui nécessite une forme d'expertise sur la base (connaître les champs obligatoires en création, générer correctement les identifiants depuis les colonnes, savoir faire correspondre les champs aux noms en base de données). Des importeurs sont disponibles de base dans Ishtar ;
L'importeur n'apporte pas de surcouche de contrôle, des données incohérentes dans le fichier source peuvent déclencher des erreurs en base de données et donner lieu à des messages d'erreur assez peu explicites ;
Les données importées sont écrites dans la base de données directement, un mauvais paramétrage d'importeur peut donner lieu à une destruction de données.

Cas d'utilisation¶

C'est le mode opératoire à privilégier pour les sources de données externes à Ishtar que cela soit une reprise d'une base de données pré-existante ou une intégration de données d'autres intervenants.

En terme de mise à jour, ce mode opératoire peut être pertinent lors de la mise à jour de masse, notamment lorsque cette mise à jour est déléguée. En effet, avec un importeur ciblé sur les seules données à mettre à jour, ce mode peut être très efficace. Le contrôle du fichier avant import est aisé.

Ajout/modification par formulaire¶

Mode opératoire¶

L'ajout se fait via un enchaînement de formulaire web dans l'interface Ishtar. Ces formulaires sont découpés de manière thématique (exemple : formulaire « Conservation » de « Mobilier ») ou logique (le type d'opération est dans le premier formulaire Opération car il conditionne les formulaires suivants).

Chaque formulaire peut être personnalisé en ajoutant certains champs spécifiques (les champs personnalisés) ou en supprimant des champs de l'affichage. Ces personnalisations peuvent être faites pour tous ou simplement pour certains profils d'utilisateurs.

Atouts¶

Notamment via les formulaires spécialisés, ce mode opératoire peut être un moyen efficace de saisie, en offrant des formulaires contextuels.
De base, ces formulaires présentent tous les champs disponibles, c'est la méthode la plus exhaustive.
La mise à disposition de facilitateurs de saisie permet par endroits des filtres de données (exemple : le champ Contenant parent ne liste que les contenants du lieu de conservation actuel) ou de faciliter la saisie (exemple : la saisie intelligente d'une liste de parcelle depuis un champ texte).

Inconvénients¶

Cette saisie peut être longue et fastidieuse sur des gros volumes.

Cas d'utilisation¶

Ce mode opératoire est particulièrement adapté à de la saisie/correction unitaire. Elle peut s'avérer pertinente pour une saisie terrain pour peu que l'on dispose de matériel adapté (tablette avec connexion Internet) et avec éventuellement des formulaires personnalisés afin de réduire la saisie aux seuls champs pertinents.

Modification par lot¶

Mode opératoire¶

Depuis les interfaces tableaux Ishtar, on fait une sélection multiple des lignes correspondant aux élément à modifier puis un clic sur le crayon vert permet d'accéder au formulaire de modification par lot.

Atouts¶

Édition très rapide de champs sur plusieurs éléments.

Inconvénients¶

La facilité et rapidité d'édition est propice aux erreurs si l'on n'est pas vigilant (un élément supplémentaire est vite sélectionné).
Pour cette raison, cette interface n'est accessible qu'aux gestionnaires de base / administrateurs.
Le nombre de champs disponible est limité.
Sur les champs multivalués (types de matériau par exemple), on ne peut actuellement qu'ajouter une nouvelle valeur, pas remplacer une valeur existante.

Cas d'utilisation¶

Ce mode opératoire est particulièrement pertinent pour la correction en masse de données. Cela peut être aussi utile pour des travaux de pointage.

Notions avancées¶

Données géographiques¶

Les éléments principaux d’Ishtar (opérations, sites archéologiques, unités d’enregistrement, mobilier, dépôts et contenants) peuvent être localisés. Actuellement cette localisation est réalisée par le stockage de données géographiques (point ou polygone) parmi les champs de l'élément concerné. Dans une future version d'Ishtar, il est envisagé de créer des éléments distincts de type « Localisation » (qui correspondrait par exemple à un relevé topographique de terrain) auxquels les éléments principaux d'Ishtar pourraient être associés (de la même manière qu'un document est un élément distinct, auquel un ou des éléments parmi opération, site, UE, mobilier, dépôt et contenant peuvent être associés).

Un élément localisé dispose des champs suivants (entre parenthèses le nom du champ en base de données - à utiliser pour les configurations d'import) :

système de coordonnées géographiques utilisé (spatial_reference_system). Les systèmes de coordonnées standards sont présents par défaut dans Ishtar mais d'autres peuvent être ajoutés en administration.
coordonnées en x, y et z (x, y, z).
erreur estimée en x, y et z (estimated_error_x, estimated_error_y, estimated_error_z).
un champ point 2D (point_2d) et point 3D (point). Ce champ est déduit automatiquement des coordonnées (non visible en interface de saisie).
un champ polygone ou plus précisément un champ multi-polygone (multi_polygon) - par abus de langage polygone est repris dans la suite de la documentation. Pour l'instant ce champ n'est éditable qu'en import (mais visible sur les fiches) .
l'origine des coordonnées (point_source) et l'origine du polygone (multi_polygon_source). Trois origines sont possibles :
- « précis » (valeur P pour precise). Les coordonnées ou le polygone ont été relevés précisément.
- le polygone (valeur M pour multi-polygon). Ne concerne que le point : reprend le centroïde du polygone. Géré automatiquement par Ishtar quand le polygone a été défini précisément et qu'il n'y a pas de coordonnées précises associées.
- la commune (valeur T pour town). Le point a été déduit du centroïde de la commune, le polygone reprend celui de la commune. Géré automatiquement par Ishtar quand aucune autre source n'est disponible.
la source des coordonnées (point_source_item), du polygone (multi_polygon_source_item). Quand l'élément n'a pas de coordonnées/de polygone associé, on essaye d'associer les coordonnées d'un élément parent, exemple : sans coordonnées précises, le mobilier a les coordonnées de son unité d'enregistrement qui elle-même hérite des coordonnées de l'opération ou du site archéologique associé si elle n'a pas de coordonnées propres. Cette mécanique est gérée automatiquement par Ishtar.

La gestion des données géographiques dans Ishtar est résumée par le graphe logique suivant pour les coordonnées :

Gestion des coordonnées

Pour les polygones, la gestion est assez similaire aux coordonnées mais sans la déduction possible depuis le polygone :

Gestion des polygones

L'arbre de prise en compte des éléments parents pour les données géographiques est le suivant :

Note

Dans le profil d'instance, il est possible d'activer un degré d'imprécision. Cela permet de mettre un positionnement approximatif des éléments sur la fiche au cas où ces fiches seraient consultables par des tiers non dignes de confiance. Pour ce faire, les coordonnées sont tronquées (X nombres après la virgule) pour l'affichage (les données en base de données restent inchangées). La troncature est opérée sur les coordonnées en WGS 84 (latitude/longitude).

Interface utilisateur¶

Auteur:	Étienne Loks
Date:	2018-10-02
Copyright:	CC-BY 3.0

Interface générale¶

L'interface générale se découpe en 4 zones :

zone de profil
menu d'actions
zone centrale
zone d'alerte et de sélection épinglée

La capture d'écran ci-dessous reprend l'interface « bureau ». L'interface mobile reprend les mêmes éléments dans une version compacte : la zone de profil est accessible via l'icône « hamburger » à droite, le menu d'action est repris en haut en position centrale.

Zone de profil¶

La zone de profil reprend, dans l'ordre :

le nom de l'instance Ishtar (ici « Démo »),
le nom de l'utilisateur et le nom du profil en cours d'utilisation - en cliquant sur ces noms, on accède à un sous-menu permettant de modifier son profil, changer son mot de passe et se déconnecter,
si plusieurs langues sont disponibles, une icône « drapeau » qui permet de changer la langue,
si on a les droits administrateur, une icône « engrenage » qui permet à accéder aux pages spécifiques d'administration (cf. documentation administrateur).

Menu d'actions¶

Ce menu reprend les différentes pages disponibles en fonction des droits dont dispose l'utilisateur et des modules activés dans Ishtar. Visible à tout moment il permet visuellement d'identifier immédiatement le contexte. Ce menu est organisé de manière hiérarchique :

le premier niveau reprend les éléments généraux : « Opération », « Unité d'Enregistrement », « Mobilier », etc. ainsi que des sections génériques telles que « Imports » ou « Annuaire ».
le second niveau fournit le détail des actions disponibles en fonction du premier niveau sélectionné. Classiquement pour les éléments généraux (si l'on dispose des droits adéquats), il y des actions de « Recherche », « Ajout », « Modification » et « Suppression ». Si des sous-élements sont disponibles (par exemple, les « Contenants » dans le menu « Lieu de conservation »), ils sont accessibles après ces actions de base.
le troisième niveau rend disponible les actions des sous-éléments.

La sélection d'un élément du premier niveau charge automatiquement la page de la première action du second niveau. De même la sélection d'un sous-menu dans le second niveau charge automatiquement la première action du troisième niveau correspondant.

Zone centrale¶

La zone centrale est totalement contextuelle. Néanmoins si certaines pages d'action ont une logique particulière, la plupart des pages d'action sur les éléments généraux s'ouvrent sur une « page de recherche » et les actions d'ajout, modification et suppression suivent ensuite une logique de « page d'assistant logiciel » (ou wizard). Le détail de ces pages est décrit dans les sections suivantes de cette documentation.

Zone d'alerte et de sélection épinglée¶

Cette zone reprend les éventuelles alertes (cf. Page de recherche > Marques-pages et alertes), mise en place par l'utilisateur ainsi que (si l'affichage de ceux-ci est activé) les éléments actuellement épinglés (cf. Utilisation avancée > Éléments épinglés).

Page de recherche¶

La page de recherche comporte une barre de recherche et d'un tableau de résultat.

Recherche textuelle et par critères¶

La barre de recherche est composée d'une zone de saisie et d'une série d'icônes d'outils de recherche. Dans l'ordre ces icônes permettent de :

icône « loupe » : lancer la recherche,
icône « engrenage » : accéder à la recherche par critère,
icône « croix » : vider la zone de recherche,
icône « épingle » : épingler la recherche actuelle pour qu'elle devienne la recherche par défaut pour cette session,
icône « étoile » : enregistrer une alerte, un marque-page,
icône « marque-page » : accéder aux marques-pages (les supprimer).

Lorsque aucune recherche n'est active par défaut et que la zone de saisie est vide tous les éléments de la base de données sont listés.

La zone de recherche permet deux types de recherches distinctes : une recherche libre (sur l'ensemble des champs indexés) et une recherche par critère (champ par champ, pour l'ensemble des champs de la base).

Recherche libre¶

Chaque élément de la base de données est indexé afin de pouvoir permettre ce type de recherche de manière performante. Les propriétés et descriptions rattachées aux éléments sont indexées. De même chaque élément parent est compris dans l'index de l'élément enfant.

Plus précisément :

l'index de recherche d'une opération comprend les propriétés des sites(entités) archéologiques lié(e)s ;
l'index de recherche d'un(e) site(entité) archéologique comprend les propriétés des opérations liées ;
l'index de recherche d'une Unité d'Enregistrement comprend les propriétés des opérations et des sites(entités) archéologiques lié(e)s ;
l'index de recherche du mobilier comprend les propriétés des opérations, des sites(entités) archéologiques et des Unités d'Enregistrement lié(e)s.

En revanche tous les champs de la base ne sont pas indexés, ceci afin que les résultats restent cohérents.

Les index de recherche permettent de faire des recherches en s'affranchissant des pluriels et de la casse.

Exemple : des recherches sur les termes « AMPHORE », « AMPHORES » et « amphores » renverront bien tous les éléments concernant des amphores.

Note

Par choix de ne pas intégrer des résultats trop éloignés de la recherche initiale, les fautes de frappe et d'orthographe ne sont pas prises en charge. Les recherches par orthographe approximative sont plus adaptées à des interfaces grand public qu'à des bases de données métier. Concrètement lorsque l'on cherche avec le terme « amphore », les résultats deviennent peu pertinents si par exemple nous sont renvoyés des éléments évoquant un « phare » dans sa description. En revanche la recherche libre comprend tout terme de recherche avec le sens « Commence par ». Ainsi une recherche sur amp renverra autant les amphore que les ampoules.

Adjoindre plusieurs termes correspond à faire une recherche avec l'opérateur logique ET.

Exemple : une recherche avec le terme « amphore dressel 1B » retournera tous les éléments concernant des amphores Dressel de type 1B.

Préfixer un terme par un « moins » : « - » permet d'exclure des termes de notre recherche.

Exemple : une recherche avec « ancre -amphore » permet d'obtenir la liste des ancres en excluant les lots de mobilier comprenant des amphores.

Recherche par critère¶

En cliquant sur l'icône engrenage, on accède à un formulaire permettant de construire simplement sa recherche par critère. Le formulaire de construction de requête dépend bien entendu du type d'élément recherché. Par ailleurs comme les autres formulaires ce formulaire peut avoir été personnalisé sur votre installation Ishtar, permettant de cacher certains champs inutiles ou ajouter d'autres champs personnalisés.

Après sélection d'une ou plusieurs contraintes dans le formulaire, en cliquant sur Ajouter, on les ajoute de manière textuelle sous la forme : « attribut="valeur" ». Cette forme permet de facilement retoucher une requête de manière textuelle sans passer par le formulaire.

Exemple : « annee="2018" » recherchera les éléments de l'année 2018.

Note

Dans la recherche par critère, le moteur recherche exactement la valeur entrée. Si l'on souhaite faire une recherche ouverte du type « contient la valeur », il faut ajouter un astérisque * à la valeur.

Exemple : « denomination="éclat" » retournera uniquement les éléments dont la dénomination est exactement Éclat, tandis que « denomination="éclat*" » renverra tous les éléments dont la dénomination contient le mot éclat, donc par exemple Lots d'éclats, éclat retouché, etc. De la même manière pour les nombres, « patriarche="1012" » donnera uniquement l'OA1012, alors que patriarche="1012*" renverra toutes les OA contenant les chiffres 1012, donc par exemple 101201 ou 1010125.

Avertissement

Contrairement à la recherche libre, la juxtaposition des termes concernant un même attribut est comprise comme un opérateur OU. Ainsi « annee="2018" annee="2017" » listera les éléments de l'année 2017 ou 2018. Néanmoins pour les attributs différents, cela reste à comprendre comme un opérateur ET. Ainsi « annee="2018" annee="2017" type-objet="Ancre et corps-mort" » listera le mobilier avec un type d'objet « Ancre et corps-mort » et rattaché à une des années 2017 ou 2018.

Marques-pages et alertes¶

Les marques-pages permettent de stocker une recherche pour la retrouver plus aisément plus tard. Ceux-ci sont alors directement disponibles depuis le menu qui s'ouvre lorsque l'on clique sur l'icône marque-page de la barre de recherche.

Techniquement le contenu d'un marque-page correspond à la chaîne de texte utilisé dans la zone de recherche. Ainsi (contrairement aux paniers) c'est la requête qui est stockée et donc la liste d'éléments est à même de varier au cours du temps.

On peut stocker indifféremment des requêtes en recherche libre ou en recherche par critère.

Une alerte est un marque-page mis en évidence : il est toujours disponible en haut à gauche de l'interface (à gauche de la zone 4 sur l'image de l'interface générale) avec un badge contenant le nombre d'éléments contenu. En cliquant sur cette alerte, on accède directement au tableau de cette recherche.

Tableaux¶

Les tableaux se présentent de la même manière que les tableaux web « classiques » avec possibilité d'afficher plus ou moins de lignes de tableaux (entre 10 et 100), possibilité de tri par colonne et une pagination.

Dans Ishtar, la première colonne est systématiquement une icône permettant d'accéder à la fiche associé à l'élément de cette ligne du tableau.

En tant qu'administrateur, sur certains tableaux, des actions rapides en haut à droite permettant des actions sur les éléments actuellement sélectionnés.

En bas du tableau, sur la gauche un bouton permet d'afficher le tableau en pleine page pour une meilleure lisibilité.

À la suite de ce bouton différents boutons d'export en CSV du tableau courant sont disponibles. Ces exports peuvent être configurés en administration.

Fiches¶

En s'ouvrant, les fiches se placent au-dessus de la page courante (généralement au dessus d'un tableau).

Entête¶

Une fiche se compose tout d'abord d'une entête. Cette entête est composée de :

un titre : ce titre reprend la dénomination précise de l'élément. En cliquant sur ce titre, la fiche se replie.
de flèches de navigations (si pertinent) : dans le cadre d'une fiche ouverte depuis un tableau, ces flèches permettent de naviguer entre éléments du tableau. Il n'est possible pour l'instant que de naviguer parmi les éléments actuellement affichés dans le tableau.
d'une flèche de fermeture de la fiche.

Barre d'outil¶

Juste en dessous de l'entête une barre d'outil est présente.

Tout à gauche, lorsque plusieurs versions d'une même fiche sont disponibles, il est possible de naviguer parmi les différentes versions de cette fiche.

Ensuite sur la droite, différentes actions sont disponibles. Ces actions dépendent du type d'élément sélectionné. Généralement on y trouve :

une icône « épingle » : elle permet d'épingler l'élément de la fiche (cf. épinglage).
une icône « crayon » : si l'on dispose des droits adéquats, elle permet d'éditer cette fiche. On accède au premier volet des pages d'assistants dédié à l'édition de ce type d'élément.
des icônes « + » : ces icônes permettent d'associer facilement un type particulier d'élément à l'élément de la fiche courante. Par exemple « + doc./image » permet d'associer un document/une image à l'élément de la fiche.
un menu « exporter » : les éléments de ce menu permettent un export dans différement format de la fiche actuelle.

Contenu de la fiche¶

Les fiches présentent globalement les informations relatives à un élément.

Lorsque ces informations sont en relations avec d'autres éléments qui disposent eux aussi des fiches une icône « i » d'information est affiché à côté permettant ainsi de sauter de fiche en fiche.

Page d'assistant logiciel (wizard)¶

Dans Ishtar, pour la plupart des éléments complexes, les pages d'édition se présentent sous la forme d'« assistant logiciel ». Un assistant logiciel, découpe la saisie en plusieurs pages. Ces pages permettent une structuration logique de l'information. Ainsi en fonction des modules activés et des informations renseignées le contenu et l'affichage des panneaux est dynamique.

Exemple : les panneaux disponibles lors de la saisie d'une opération préventive, d'une opération programmée, d'une saisie judiciaire, les panneaux affichés sont différents.

Les panneaux enchaînent les formulaires jusqu'au dernier panneau de récapitulatif qui demandera confirmation des changements opérés. Tant que la validation finale n'est pas faite aucune donnée n'est enregistrée en base de données.

Jusqu'à la validation finale, les données de formulaire sont enregistrées dans la session de l'utilisateur. L'utilisateur peut tout à fait avoir plusieurs saisies d'éléments de nature différente en parallèle. Attention à la déconnexion ou à expiration de la session ces données de formulaires sont effacées.

Fil d'Ariane¶

Tout en haut des pages d'assistant logiciel, un fil d'Ariane est affiché. Celui-ci permet de naviguer rapidement entre les différents panneaux. En modification la navigation est libre. En saisie, certains panneaux requérant des informations obligatoires ne peuvent pas être passés : le fil d'Ariane s'adapte automatiquement et affiche les étapes jusqu'au prochain panneau obligatoire.

Tableau / Zone de formulaire¶

En saisie, en général, deux types de panneau sont disponibles : un type « tableau » et un type « zone de formulaire ».

Les types de page « tableau » permettent de sélectionner un élément tout en profitant des possibilités de recherche, filtre, tri évoqués précédemment. Ces types de pages permettent de sélectionner l'élément que l'on souhaite modifier ou l'élément parent de l'élément que l'on souhaite créer.

Les types de page « zone de formulaire » sont des formulaires web classiques. Ils offrent quelques facilitées tel que la saisie de dates en cliquant dans un calendrier, des conversions d'unités dynamiques, etc. Certains contrôles de formulaire sont réalisés de manière dynamique (par exemple une saisie textuelle dans un champ qui attend un chiffre), d'autres sont réalisés après envoi au serveur (par exemple, utilisation d'un index déjà utilisé par ailleurs).

Zone de validation¶

La zone de validation se situe tout en bas de la page. Les boutons « Valider » et « Annuler » sont toujours disponibles.

« Valider » permet de valider le panneau en cours et de passer au panneau suivant. Si c'est le dernier panneau, le panneau de récapitulatif, la création/modification/suppression est validée. En création/modification, l'utilisateur est redirigé vers la fiche de l'élément qui vient d'être créé/modifié.

« Annuler » permet d'annuler toute la saisie en cours : les données de session seront effacées.

« Valider et confirmer » (qui s'insère entre « Valider » et « Annuler ») permet de valider le panneau actuel et d'aller directement au panneau récapitulatif.

Utilisation avancée¶

Paniers¶

Les paniers sont un autre type de sélection d'éléments. Contrairement aux marques-pages, ils concernent une liste d'éléments fixe.

Pour effectuer certaines actions, il est nécessaire de préalablement constituer un panier (notamment pour ce qui concerne les traitements).

Ce regroupement virtuel peut être aussi un outil de travail, par exemple en constituant une liste d'éléments « à traiter ». Un marque-page (voire une alerte) pouvant être faite sur le contenu d'un panier, cela permet de conserver sous la main cette sélection d'éléments.

Pour l'heure les paniers ne concernent que le mobilier.

Éléments épinglés¶

Les éléments épinglés constituent les éléments « par défaut » en terme de recherche. L'épinglage d'élément est un outil de travail permettant de travailler dans un contexte de travail donné.

Exemple : je souhaite travailler sur le mobilier d'une opération précise. En épinglant cette opération, par défaut, toutes les recherches de mobilier se feront sur cette opération.

L'épinglage est disponible directement dans la barre d'outil des fiches. L'épinglage est aussi disponible au niveau de la barre de recherche (cette recherche épinglée ne concerne que le tableau d'éléments en cours sans gestion hiérarchique). Si celui-ci est activé dans son profil, l'épinglage est aussi disponible dans le menu de gestion des sélections épinglées (à droite de la zone 4 sur l'image de l'interface générale). Si on a activé cette option dans son profil, un élément créé ou modifié est automatiquement épinglé.

Une gestion hiérarchique des épingles est faite : le fait d'épingler un élément épingle automatiquement ses parents directs.

Exemple : le fait d'épingler un mobilier épingle automatiquement l'Unité d'Enregistrement et l'opération archéologique associée à ce mobilier.

Menu de gestion des sélections épinglées¶

Ce menu n'est visible que s'il est activé dans son profil. Il propose de sélectionner les éléments que l'on souhaite épingler. Différentes versions de ce menu sont disponibles :

« simple » : des menus déroulants permettent d'épingler les éléments qui sont directement rattachés à notre compte utilisateur (en particulier les éléments que l'on a créé) ;
« avancé - mes éléments » : on épingle ici seulement les éléments rattachés à notre compte utilisateur mais avec des champs fonctionnant en autocomplétion ;
« avancé - tous les éléments » : on peut épingler tous les éléments avec des champs en autocomplétion.

Sur chaque menu, il est possible d'accéder aux fiches des différents éléments épinglés (icône « i ») et de détacher l'épingle sur ces éléments (croix rouge).

Action rapide¶

Pour les administrateurs, des actions rapides sont directement accessibles depuis les tableaux. Ces actions se situent en haut à droite du tableau. Elles concernent les éléments actuellement sélectionnés dans le tableau. Les icônes d'action rapide ne sont actives que lorsque cela est pertinent : si une action n'est applicable qu'à un seul élément, en sélectionner aucun ou plusieurs désactive l'icône de l'action en question.

Ces actions rapides permettent notamment de faire de l'édition de groupe, de l'empaquetage, etc.

Configuration de l'instance Ishtar¶

Auteur:	Étienne Loks
Date:	2018-12-04
Copyright:	CC-BY 3.0

La configuration d'Ishtar se fait essentiellement par le biais de « l'interface d'administration ». Cette interface propose une vue brute des tables en base de données. Même si cette interface propose une ergonomie simple et pratique, utiliser cette interface peut nécessiter d'avoir connaissance de notions de base d'une base de données pour pouvoir opérer des choix pertinents.

L'interface d'administration nécessite d'avoir un compte administrateur pour y accéder. Les utilisateurs disposant de ce droit ont une icône « roue dentée » sur la barre de menu à l'extrémité droite. Sauf configuration spécifique, cette interface est aussi disponible via l'adresse « https://monsite-ishtar.net/admin/ » (ajouter /admin/ à l'adresse de base).

L'interface d'administration présente la liste des différentes tables par ordre alphabétique regroupées par application.

Avertissement

Pour des questions de performance, Ishtar utilise intensément un système de cache. Il arrive parfois que celui-ci tarde à se mettre à jour. Il peut arriver que des modifications en administration prennent plusieurs minutes à être prises en compte.

Listes de types¶

Ishtar fournit par défaut des données pour chaque liste de choix. Chacune de ces listes est paramétrable en administration.

Dans les pages d'administration, les listes de types se retrouvent sous les dénominations « Types de ... », rangées par application :

Ishtar - Commun : contient les listes de types transversales utilisées par plusieurs types d'éléments ;
Ishtar - Opération : contient les listes de types concernant les opérations et les entités archéologiques/sites ;
Ishtar - Unités d'enregistrement : contient les listes de types relatives aux Unités d'enregistrement et aux datations ;
Ishtar - Mobilier : contient les listes de types relatives au mobilier et aux traitements ;
Ishtar - Lieu de conservation : contient les listes de types relatives aux lieux de conservation et aux contenants ;
Ishtar - Dossier : contient les listes de types relatives aux dossiers administratifs.

Dans Ishtar, chaque type est défini au minimum par les champs suivants :

Dénomination
Identifiant textuel : L'identifiant textuel est une version standardisée du nom. Il ne contient que des lettres en minuscules non accentuées, des nombres et des tirets (-). Chaque identifiant textuel doit être unique dans la liste de types. Ces identifiants sont des clés permettant les échanges entre bases de données et pour des traductions. Ces identifiants peuvent être utilisés dans le code source de l'application. Une fois créés il ne faut a priori pas changer ces identifiants textuels.
Commentaire : Le contenu du commentaire est affiché dans l'aide en ligne sur les formulaires.
Disponibilité : Décocher ce champ rend indisponible ce type dans les formulaires, sans détruire l'information pour ce qui est déjà présent en base ; l'information est toujours visible dans les fiches.
Ordre : Dans les listes les champs sont ordonnés par ce numéro d'ordre et en cas d'égalité par ordre alphabétique.

Certains types permettent de mettre en place une hiérarchie. Pour cela le champ parent est disponible. Pour chaque type enfant, ce champ est renseigné avec le type parent adéquat.

Certains types disposent aussi d'autres champs spécifiques ; ceux-ci sont explicites ou disposent d'une aide en ligne.

Note

Pour travailler sur ces listes de types ou les transmettre à des tiers, la possibilité est offerte d'exporter ces listes de types via l'interface d'administration. On sélectionne les éléments à exporter (ou tous les éléments) puis on utilise l'action « Exporter les éléments sélectionnés en fichier CSV ». Le fichier peut alors être édité dans un tableur. Pour une mise à jour, il est important de ne pas modifier les identifiants textuels qui sont la clé de rapprochement pour le ré-import. L'action d'import est disponible en haut à droite : « Import depuis un CSV ».

Champs personnalisés¶

Ishtar propose un certain nombre de champs standards et génériques permettant de disposer dès le départ d'une base solide et aussi pour assurer un certain degré d'inter-opérabilité entre les différentes installations d'Ishtar. Néanmoins nul ne peut prétendre à l'exhaustivité et, notamment dans le cadre d'une utilisation d'Ishtar axée recherche, le besoin se fera probablement sentir d'ajouter des champs.

Dans Ishtar ces champs sont appelés : Champs personnalisés. Le format JSON étant utilisé pour stocker ces données, le nom Données JSON est aussi utilisé.

Ajouter un champ personnalisé se fait via l'interface d'administration au niveau de la rubrique : Ishtar - Commun › Données JSON - Champs.

Les différentes données à rentrer sont :

Nom : Ce nom sera repris dans les formulaires et la fiche.
Type de contenu : Le type d'objet auquel sera rattaché le champ - Opération, Site, Unité d'Enregistrement, Mobilier, ...
Clé : Valeur de la clé dans le format JSON. Cette clé ne doit impérativement comporter que des lettres minuscules, sans accent et des tirets bas « _ » (ne pas commencer la clé par le tiret bas et ne pas mettre plusieurs tirets bas d'affilée dans la clé de base). On peut structurer les données personnalisée de manière hiérarchique. Pour les clés hiérarchiques on utilise « __ » entre les sections. Par exemple pour la clé « ma_sousclef » dans la catégorie « ma_categorie », la clé sera notée : ma_categorie__ma_sousclef.
Type : Les types de données disponibles sont les suivants :
- Texte,
- Texte long : le composant de saisie sera une zone de texte,
- Entier : nombre entier positif ou négatif,
- Nombre à virgule,
- Booléen : case à cocher - Vrai ou Faux,
- Date : un composant permettant le choix de date depuis un calendrier est proposé,
- Choix : un composant en autocomplétion sur les valeurs existantes est proposé. L'utilisateur a la possibilité de rentrer librement de nouvelles valeurs.
Ordre : Le numéro saisi permet d'ordonner par défaut ce champ par rapport aux autres champs.
Section : La section correspond à un titre de section pour présenter ce champ sur la fiche et permettre des regroupements.
Utiliser dans les index de recherche : Si cette case est cochée, la recherche libre indexera le contenu de ce champ.
Afficher : Si cette case n'est pas cochée, ce champ ne sera pas affiché sur la fiche.

Sauf si un champ personnalisé est uniquement destiné à des données importées et à un affichage sur la fiche, un champ personnalisé sera dans la plupart des cas intégré à un formulaire personnalisé.

Formulaires personnalisés¶

La plupart des formulaires peuvent être personnalisés dans Ishtar, notamment tous les formulaires de création/modification ainsi que les formulaires de recherche. À ce jour, il n'est pas encore possible d'ajouter de nouveaux formulaires.

Les formulaires personnalisés permettent deux choses : soustraire de l'affichage du formulaire les champs disponibles par défaut et ajouter des champs JSON dans le formulaire. Chaque formulaire personnalisé peut être mis à disposition pour tous ou seulement certains utilisateurs.

La configuration de ces champs se fait en administration via : Ishtar - Commun › Formulaires personnalisés.

La création se fait en deux temps, d'abord un paramétrage des champs de base puis une définition des champs à exclure et des champs JSON à ajouter.

Le paramétrage de base demande les champs suivants :

Nom : le nom correspondant au formulaire personnalisé. Ce nom ne sera visible qu'en administration mais pour s'y retrouver, il doit à la fois reprendre le nom du formulaire ainsi que le contexte pour lequel il a été défini. Par exemple : « Mobilier - 020 - Général - Tout utilisateur » ou « Mobilier - 030 - Conservation - Saisie terrain ».
Formulaire : le formulaire à personnaliser. Le nom utilisé permet d'identifier assez simplement le formulaire correspondant, car il correspond dans l'ordre (séparé par des tirets) au :
- type d'objet concerné (par exemple : « Mobilier »),
- éventuellement, le numéro d'ordre dans les formulaires successifs,
- nom du formulaire.
À qui s'applique ce formulaire, cela peut être au choix :
- à tous les utilisateurs,
- à certains utilisateurs en particulier,
- à certains types d'utilisateurs.

Une fois ce paramétrage de base enregistré, la configuration précise du formulaire peut se faire :

champs à exclure : chaque champ de base présent dans le formulaire actuel peut être sélectionné dans la liste pour être écarté de la saisie.
champs JSON : tous les champs JSON préalablement paramétrés concernant l'élément courant (mobilier, OA...) peuvent être sélectionnés. La dénomination permet éventuellement de surcharger le nom par défaut du champ JSON. L'ordre permet de placer le champ dans le formulaire. L'aide permet éventuellement d'ajouter un texte pour aider à la saisie.

Avertissement

Sur les formulaires de création, il est impératif de ne pas exclure des champs obligatoires sans quoi la création devient impossible.

Note

En tant qu'administrateur, en modifiant son profil depuis les pages d'administration (Ishtar - Commun › Profils d'utilisateurs) et en cochant « Afficher les numéros des champs », les numéros des champs actuels des formulaires s'affichent sur l'interface, cela permet ainsi de placer plus aisément les champs personnalisés.

Gestion des permissions¶

Gestion des comptes¶

Dans Ishtar, un compte doit être associé à une personne. Si la personne n'existe pas dans la base, il faut l'ajouter via l'interface principale d'Ishtar : Annuaire › Personne › Ajout.

Ensuite on crée un compte associé à cette personne, toujours via l'interface d'Ishtar : Administration › Compte › Ajout/modification. Dans les différents panneaux, il est demandé : l'identifiant du compte, le courriel rattaché, le mot de passe puis le type de profil.

Les types de profil définiront les types de permissions auxquelles aura accès l'utilisateur. Sur ces types de profil, des zones peuvent être définies afin de permettre des règles de rattachement spécifique (cf. permissions dans Ishtar).

Cette interface de création de compte permet aussi de modifier le mot de passe de comptes existants.

Permissions dans Ishtar¶

Les permissions dans Ishtar sont essentiellement gérées par « Type de profil ». Chaque compte a un ou plusieurs « types de profil » associés à son compte. Chaque type de profil donne accès à des actions et des accès sur des types d'objets.

La création/configuration d'un type de profil se fait via : Ishtar - Commun › Types de profil :

dénomination : ce champ doit être explicite, car il va être retrouvé au niveau de l'interface utilisateur.
identifiant textuel : rempli selon les règles habituelles des identifiants textuels.
groupes : listes des groupes auxquels le profil est rattaché.

Chaque groupe correspond à un type de permission pour un élément précis de la base de données :

droit de lecture ;
droit d'ajout ;
droit de modification/suppression.

Chacun de ces droits est décliné en deux modalités :

droits sur tous les éléments ;
droit sur les éléments rattachés.

Un élément est dit « rattaché » à une personne en fonction de règles précises spécifiées dans l'annexe 1 - règles de rattachement à un élément. La notion de rattachement permet de spécifier finement les permissions pour des personnes qui sont directement associées à l'élément. Par exemple cela permet donner les droits de modification du mobilier d'une opération au responsable scientifique de cette opération.

En pratique, globalement, les groupes de droits permettent d'accéder à certaines actions :

le droit de lecture permet une ouverture de la fiche correspondant à l'élément ;
le droit d'ajout permet d'accéder aux actions d'ajout d'un nouvel élément ;
le droit de modification/suppression permet d'accéder aux actions concernant la modification/suppression des éléments.

Dans le détail, il y a certaines actions qui sont ouvertes en fonction d'appartenance à des groupes en particulier. Tout cela est détaillé dans l'annexe 2 - permissions nécessaires pour les actions.

Note

La page Ishtar - Commun › Résumés des types de profil permet d'accéder à un tableau qui reprend et rend explicites toutes les permissions associées aux types de profil.

Permissions dans les pages d'administration¶

Les permissions des pages d'administration sont gérées différemment. Elles utilisent le système de permission du framework Django, framework (cadre de développement logiciel) utilisé par Ishtar. Une fois le compte créé, les droits se spécifient dans les pages d'administration : Authentification et autorisation › Utilisateurs.

L'ouverture de l'accès aux pages d'administration se fait en cochant le « Statut équipe ». Si l'on souhaite n'ouvrir l'accès qu'à certaines pages spécifiques, on ajoute les « Permissions de l'utilisateur » correspondant aux tables que l'on souhaite ouvrir, si l'on souhaite ouvrir l'accès à toutes les tables, il suffit de cocher le « Statut super-utilisateur ».

Patrons de documents¶

Principes de base¶

Ishtar propose une génération automatisée de document. Depuis un patron au format LibreOffice (ODT), les données relatives à un élément (acte administratif, mobilier...) remplacent les variables du patron pour obtenir le document désiré.

On crée le patron au format ODT avec un contenu adapté, puis depuis l'interface d'administration, sous l'entrée Ishtar - Commun › Patrons de document › Document de référence, on créé un patron de document avec ce fichier ODT associé au type d'élément pour lequel il est destiné.

Le document peut alors être généré depuis n'importe quelle fiche de l'élément concerné (en haut à droite sous « Documents »).

Un premier patron¶

Pour créer un patron, la première étape est de récupérer toutes les variables disponibles pour l'élément à partir duquel on veut générer un document. Il existe pour cela un document de référence que l'on peut attacher à l'élément pour lequel on souhaite éditer un nouveau document.

Note

En cas d'indisponibilité du lien pour ce document, ce document est très simple et peut être recréé facilement, il suffit d'insérer : {{VALUES}} dans un document ODT vide et de sauvegarder le document.

Depuis Ishtar - Commun › Patrons de document › Document de référence, on ajoute un nouveau patron de document : « Document de référence » auquel on associe le document de référence téléchargé et le type d'élément pour lequel on souhaite créer un patron de document.

Ensuite, il faut récupérer un document de référence généré depuis la fiche d'un élément contenant tous les champs que l'on souhaite exploiter.

On ouvre ce document sous LibreOffice. Le document produit contient une liste de clé avec la valeur associée concernant l'élément que l'on a choisi.

Les différentes clés vont permettre de constituer un patron répondant à ce qui est attendu. Pour cela reprendre un exemple du document que l'on souhaite générer (toujours au format ODT) et remplacer chaque occurence d'une valeur par la clé en reprenant la syntaxe Jinja (Jinja est le nom de la bibliothèque utilisée). Une fois quelques substitutions faites, on peut l'enregistrer et créer le patron dans l'interface d'administration Ishtar. Ce premier patron est alors disponible depuis la fiche des éléments.

Configuration du profil d'instance Ishtar¶

En cours de rédaction...

Identifiants et index personnalisés¶

Pour chaque type d'élément principal, il est possible de configurer le profil Ishtar pour personnaliser :

l'identifiant externe : c'est un identifiant textuel unique dans la base qui permet de faire des rapprochements de manière non ambiguë. Il est souvent utilisé pour les imports. Par exemple, un identifiant externe pour les unités d'enregistrement peut être "code patriarche de l'opération-identifiant de l'unité d'enregistrement" ou alors "code patriarche de l'opération-section parcelle-numéro parcelle-identifiant de l'unité d'enregistrement". Des identifiants externes sont paramétrés par défaut pour chaque type d'élément principale. Note : l'identifiant externe de l'opération est toujours le code patriarche et n'est pas paramétrable.
l'identifiant complet (optionnel) : cet identifiant est un identifiant de gestion paramétrable. Cet identifiant peut par exemple se distinguer de l'identifiant externe pour incorporer des codes matières.
clés pour index personnalisé : un index personnalisé peut être défini en fonction d'une ou plusieurs clés reprenant les champs. Par exemple une clé opération peut être utilisée pour générer un index numérotant de 1 à n le mobilier sur une opération.

Pour définir identifiant externes et identifiant complet, on utilise des formules. Deux types de syntaxes sont utilisées : une syntaxe simple et une syntaxe Jinja (nom de la bibliothèque utilisée). Ces deux syntaxes utilisent des variables relatives à l'élément. L'utilisation de ces variables est explicitée dans l'annexe technique 3 - variables.

Formules¶

Syntaxe simple¶

Cette syntaxe permet d'utiliser directement les variables en utilisant la notation accolade simple {}. Par exemple :

OA-{code_patriarche}

Cette notation se traduira ainsi par des rendus comme : OA-061234 ou OA-44789.

Syntaxe Jinja¶

Cette syntaxe permet de faire de faire des substitutions de manière plus fine qu'avec la syntaxe simple. Cette syntaxe est utilisée systématiquement pour les patrons de document, un sous-ensemble de cette syntaxe (variables et structures conditionnelles) peut-être utilisée optionnellement pour les identifiants personnalisés.

Variables¶

L'accès aux variables <annexe-technique-3-variables> se fait par la notation double accolade {{ }}. Ainsi par exemple, pour accéder aux variables nom_de_ma_clef_1 et nom_de_ma_clef_2 :

Je, soussigné, {{nom_de_ma_clef_1}}, vous accorde un prêt de {{nom_ma_clef_2}}.

Conditions¶

Des structures conditionnelles peuvent être mises en place. Cela permet notamment de tester si une valeur a été renseignée et de permettre de contextualiser l'affichage en fonction de cela. Exemple :

Ce traitement sous
{% if responsable %}la responsabilité de {{responsable}}
{% else %}une responsabilité à définir
{% endif %} se tiendra...

Les structures conditionnelles se structurent autour des mots clés if, else et endif. On utilise {% et %} autour de ces mots clés. La section else est facultative.

Parcours de liste¶

Certaines clés peuvent parfois renvoyer à des listes d'éléments, chacun ayant des attributs. On peut alors parcourir cette liste d'élément de cette manière :

{% for element in liste_elements %}
   {{element.nom}} - {{element.prenom}}
{% endfor %}

Cela se structure autour des mots clés for, in et endfor. Au lieu de doubles accolades, {% et %} encadrent ces mots clés.

Annexe 1 - Règles de rattachement aux éléments¶

Auteur:	Étienne Loks
Date:	2018-12-04
Copyright:	CC-BY 3.0

Opération

Annexe 2 - Permissions nécessaires pour les actions¶

Auteur:	Étienne Loks
Date:	2018-12-04
Copyright:	CC-BY 3.0

Action1....

Annexe 3 - Exemple de flux opérationnel : prêt pour exposition¶

Auteur:	Étienne Loks
Date:	2018-12-04
Copyright:	CC-BY 3.0

Description¶

Le flux opérationnel « Prêt pour exposition » pourrait par exemple se décomposer suivant ces différentes étapes :

pré-sélection du mobilier pour l'exposition par les gestionnaires de mobilier ;

sélection du mobilier depuis cette pré-selection par la structure emprunteuse ;

édition des documents administratifs : convention de prêt, assurance ;

départ effectif du mobilier concerné ;

gestion du retour du mobilier.

Pré-requis :

les patrons des actes administratifs associés à la demande de prêt ont été créés,

la personne en charge du prêt a un compte Ishtar qui dispose au minimum :

de droits de lecture et modification sur le mobilier éventuellement concerné par la sélection,

d'un droit de création de demande de traitement,

d'un droit de création d'acte administratif.

les gestionnaires de mobilier concernés ont un compte sur Ishtar qui disposent au minimum de droits de lecture sur le mobilier éventuellement concerné par la sélection.

la structure emprunteuse dispose d'un compte Ishtar avec droit de lecture sur le mobilier rattaché.

Pré-sélection du mobilier pour l'exposition par les gestionnaires de mobilier¶

Un des responsables de mobilier créé un panier depuis l'action rapide « Panier » sur les listes de mobilier (par exemple sur Mobilier › Recherche) ou depuis Mobilier › Panier › Ajout.
Il ajoute quelques éléments à ce panier via l'action rapide « Panier » ou Mobilier › Panier › Gestion des éléments.
Ce responsable partage ce panier en lecture/édition avec les autres gestionnaires de mobilier via Mobilier › Panier › Modification.
Les autres gestionnaires peuvent de la même manière ajouter, enlever des éléments à ce panier via l'action rapide « Panier » ou Mobilier › Panier › Gestion des éléments.
Fin d'étape : tous les gestionnaires ont signifié (oralement, par courriel, etc.) que la pré-sélection actuelle convenait.

Sélection du mobilier depuis cette pré-selection par la structure emprunteuse¶

Si l'on souhaite conserver cette pré-sélection avant partage et modification, elle peut être dupliquée depuis la fiche associée au panier (ouverte par exemple depuis : Mobilier › Panier › Recherche ou depuis l'icône « Paniers » sur une des fiches mobilier concernée par ce panier) avec l'icône « Dupliquer ».
Le responsable du prêt partage le panier en lecture/édition avec la structure emprunteuse via Mobilier › Panier › Modification et l'informe que la pré-selection est disponible (via courriel, téléphone).

Note

Un lien direct peut être donné à la structure emprunteuse pour quelle gère son panier, il suffit d'aller sur le panneau de gestion des éléments du panier concerné (Mobilier › Panier › Gestion des éléments) et de recopier l'adresse dans la barre d'adresse. La structure emprunteuse devra préalablement s'identifier avant d'accéder à ce lien.

Avertissement

Si le droit de lecture de mobilier de la structure emprunteuse est basé sur le mobilier rattaché via ce panier, enlever un élément du panier lui retire le droit de consulter cet élément. Une astuce peut être de partager le panier dupliqué : une fois en lecture seule, une fois en lecture/édition, ainsi même si un élément est retiré du panier en lecture/édition, il reste « rattaché » à la structure emprunteuse par le panier en lecture seule. Le panier en lecture simple peut aussi recevoir des éléments disponibles pour prêt mais pas forcément retenu dans la sélection proposée.

La structure emprunteuse retire du panier les éléments qui ne l'intéresse pas.
Fin d'étape : la structure emprunteuse a fini sa sélection et confirme son intérêt pour un prêt (par courriel, ...).

Édition des documents administratifs¶

Le responsable du prêt enleve le partage en modification du panier (Mobilier › Panier › Modification).
Le responsable du prêt crée une demande de traitement « Demande de prêt pour exposition » depuis Demande de traitement › Ajout. Il est important de bien renseigner les différents champs pour que la génération des documents se passe bien. Le panier concerné doit être associé à cette demande de traitement.
Le responsable du prêt crée les actes administratifs correspondant aux documents administratifs attendus, via l'icône « + acte admin. » de la fiche de demande de traitement ou via Demande de traitement › Acte administratif › Ajout.
Un document est généré pour chaque acte administratif depuis Demande de traitement › Acte administratif › Documents. Ceux-ci peuvent alors être transmis à la structure demandeuse.
Fin d'étape : les documents ont été retournés signés. Ils sont éventuellement numérisés et ajoutés en tant que documents à la demande de traitement.

Départ effectif du mobilier concerné¶

Le responsable du prêt crée un traitement « Prêt » depuis la fiche de demande de traitement correspondante avec le bouton « Ajouter le traitement associé ». Un contenant correspondant au lieu d'emprunt doit être spécifié.

Note

Le traitement peut être ajouté depuis la fiche panier ou via Traitement › Traitement simple - Création mais cela demande de re-sélectionner des éléments du panier ou de la demande de traitement associée. Passer par la fiche de demande de traitement correspondante est moins source d'erreur.

Une alerte spécique est créée depuis le listing mobilier pour surveiller le retour du mobilier avec une chaîne de ce type :
```
panier="Exposition Sein 2018" pret="Oui" fin-de-traitement-avant="aujourdhui+30"
```
Avec cette requête, 30 jours avant la date de retour attendue, l'alerte sera affichée.
Fin d'étape : le mobilier a été retourné.

Gestion du retour du mobilier¶

Sur la fiche panier correspondante, sur les fiches contenants correspondants ou sur chaque fiche mobilier par mobilier, un traitement « Retour de prêt » est fait.

Note

Il sera possible d'accéder rapidement aux fiches mobilier ou contenant via le QR-code.

Depuis ces fiches, une demande de traitement « Constat d'état » pourra être ajoutée depuis le bouton « Ajouter une demande de traitement ».

Annexe 4 - Correspondance des champs Ishtar - Normes documentaires¶

Auteur:	Étienne Loks
Date:	2020-05-27
Copyright:	CC-BY 3.0

Ishtar - Dublin Core¶

Issu d'un consensus international et multidisciplinaire, le Dublin Core a été développé pour décrire des documents de manière simple et standardisée.

Ishtar - COinS¶

Le ContextObjects in Spans (COinS) est une méthode pour inclure des métadonnées bibliographiques dans le code HTML de pages web.

L’utilisation de COinS permet à un logiciel de gestion bibliographique de récupérer les méta-données de l’ouvrage de référence.

Annexe technique 1 - Import des regroupements de commune INSEE¶

Auteur:	Étienne Loks
Date:	2020-09-23
Copyright:	CC-BY 3.0

L'INSEE met à disposition un fichier permettant de suivre l'évolution des « communes nouvelles » (procédure de regroupement de communes). Au sein de sa base de données, Ishtar gère ces évolutions permettant à la fois d'insérer de nouvelles données pour ces communes nouvelles mais aussi de conserver voire ajouter des données relatives à des communes anciennes maintenant regroupées. Une page sur le site de l'INSEE permet de télécharger ces données au format CSV : communes nouvelles.

Ce fichier est importable au sein d'Ishtar.

Pour cela, se connecter sur le serveur hébergeant Ishtar, déposer le fichier CSV que l'on a téléchargé, puis se rendre dans le répertoire d'installation de l'instance concernée. Enfin, lancer la commande suivante (en remplaçant <année> et <chemin vers le fichier CSV> par les valeurs adéquates) :

root@ishtar-server:# cd <chemin vers l instance> # exemple : /srv/ishtar/prod_deb
root@ishtar-server:# python3 ./manage.py import_insee_comm_csv --year <année> <chemin vers le fichier CSV>

Note

L'année attendue est celle de l'année de création des communes nouvelles.

Annexe technique 2 - Import des communes IGN¶

Auteur:	Étienne Loks
Date:	2020-09-23
Copyright:	CC-BY 3.0

L'IGN met à disposition sous licence libre (Licence ouverte) les géométries du découpage administratif du territoire métropolitain français avec une réactualisation annuelle. Au sein d'Ishtar, il est opportun de récupérer le découpage des communes avec leur géométrie associée. On réalise cela en deux temps : récupération des données et export au format CSV, puis import au sein d'Ishtar. Il est nécessaire pour faire cet import d'un accès en ligne de commande au serveur sur lequel est hébergé Ishtar.

Récupération des données¶

Le jeu de données qui nous intéresse est distribué sous le nom ADMIN EXPRESS. Ce jeu de données est disponible en ligne directement sur le site de l'IGN : ADMIN EXPRESS.

Une fois le fichier récupéré, il doit être décompressé (il faut disposer d'un utilitaire à même de décompresser les archives 7z). Les fichiers qui nous intéressent concernent le shapefile COMMUNE ou COMMUNE_CARTO (géométrie généralisée - moins précise et de fait moins volumineuse). Celui se trouve dans le répertoire ADMIN-EXPRESS-COG/1_DONNEES_LIVRAISON_<date de livraison>/<zone concernée>/.

Ce shapefile doit ensuite être ouvert dans QGIS puis exporté au format CSV en n'oubliant pas d'inclure la géométrie au format WKT.

_images/annexe-technique-1-export-qgis.png

Import dans Ishtar¶

Il ne reste plus qu'à importer dans Ishtar. Pour cela, se connecter sur le serveur hébergeant Ishtar, déposer le fichier CSV que l'on a généré, puis se rendre dans le répertoire d'installation de l'instance concernée. Enfin, lancer la commande suivante (en remplaçant <année> et <chemin vers le fichier CSV> par les valeurs adéquates) :

root@ishtar-server:# cd <chemin vers l instance> # exemple : /srv/ishtar/prod_deb
root@ishtar-server:# python3 ./manage.py import_geofla_csv --year <année> \
                              --srid <code epsg de la projection> <chemin vers le fichier CSV>
root@ishtar-server:#  # exemple
root@ishtar-server:# python3 ./manage.py import_geofla_csv --year 2019 --srid 4326 /tmp/2019.csv

Avertissement

L'année attendue est celle correspondant à l'année de création pour des communes nouvelles. Le jeu de données d'une année concerne les communes créées l'année précédente ainsi pour le jeu de données 2020, il faut indiquer 2019.

Avertissement

Si l'on souhaite garder un suivi des regroupements de communes, il est important de procéder à l'import des nouvelles communes (cf. Annexe technique 1 - Import des regroupements de commune INSEE) de l'année concernée depuis les sources INSEE avant de faire l'import des géométries depuis les sources IGN.

Annexe technique 3 - Variables¶

Auteurs:	Étienne Loks, Ishtar team
Date:	2022-07-11
Copyright:	CC-BY 3.0
Ishtar Version:	v3.2.2

Ces variables sont utilisées pour les configurations des imports, les patrons de documents et la configuration des identifiants, des index personnalisés.

Ces variables correspondent aux noms des champs utilisés en base de données (exemple : code_patriarche pour accéder au code patriarche d'une opération) ainsi que des « facilitateurs » qui permettent de disposer de champs plus évolués (exemple : get_next_index pour accéder au prochain numéro d'index).

On peut passer d'un élément lié à un autre (par exemple, accéder à l'opération d'une unité d'enregistrement) avec la notation double tiret __ et ensuite accéder aux variables de l'élément lié (exemple : operation__code_patriarche permet d'accéder au code patriarche de l'opération ).

Ci-dessous la liste des variables pour chaque type d'éléments.

..warning:: Cette documentation liste tous les champs en base de données (moins quelques champs de gestion interne). Certains sont des champs historiques obsolètes voués à disparaître, d'autres sont des champs mis en place pour des futures fonctionnalités et peuvent encore faire l'objet de modifications. Tout champ listé ci-dessous qui ne correspond pas à un champ accessible depuis l'interface d'Ishtar ne doit normalement pas être utilisé.

Modèles génériques¶

Champs personnalisés¶

Les éléments principaux (Operation, Unité d'Enregistrement, Mobilier, etc.) permettent d'utiliser des champs personnalisés. Ceux-ci sont accessibles via l'attribut data__. Ainsi on accède à une clé ma_clef via data__ma_clef ou à une autre clé sous une catégorie ma_categorie__ma_sousclef via data__ma_categorie__ma_sousclef.

Champs adresse¶

Les champs adresse sont une liste de variables partagées par plusieurs éléments :

address : Texte - Adresse
address_complement : Texte - Complément d'adresse
alt_address : Texte - Autre adresse : adresse
alt_address_complement : Texte - Autre adresse : complément d'adresse
alt_address_is_prefered : Booléen - L'adresse alternative est préférée
alt_country : Chaîne de caractères (30) - Autre adresse : pays
alt_postal_code : Chaîne de caractères (10) - Autre adresse : code postal
alt_town : Chaîne de caractères (70) - Autre adresse : ville
country : Chaîne de caractères (30) - Pays
email : Courriel (300) - Courriel
mobile_phone : Chaîne de caractères (18) - Téléphone mobile
phone : Chaîne de caractères (18) - Téléphone
phone2 : Chaîne de caractères (18) - Type de téléphone 2
phone3 : Chaîne de caractères (18) - Téléphone 3
phone_desc : Chaîne de caractères (300) - Type de téléphone
phone_desc2 : Chaîne de caractères (300) - Type de téléphone 2
phone_desc3 : Chaîne de caractères (300) - Type de téléphone 3
postal_code : Chaîne de caractères (10) - Code postal
precise_town__ : → Commune (name Nom, numero_insee Code commune (numéro INSEE), cached_label Nom en cache) - Commune (précis)
raw_phone : Texte - Téléphone brut
town : Chaîne de caractères (150) - Commune (saisie libre)

Champs géographiques¶

Les champs géographiques sont une liste de variables partagées par plusieurs éléments :

estimated_error_x : Nombre à virgule - Erreur estimée pour X
estimated_error_y : Nombre à virgule - Erreur estimée pour Y
estimated_error_z : Nombre à virgule - Erreur estimée pour Z
multi_polygon : Multi-polygone - Polygones multi-parties
multi_polygon_source : Chaîne de caractères (1) - Source du multi-polygone
multi_polygon_source_item : Chaîne de caractères (100) - Élément source du multi-polygone
point : Point - Point
point_2d : Point - Point (2D)
point_source : Chaîne de caractères (1) - Source du point
point_source_item : Chaîne de caractères (100) - Élément source du point
spatial_reference_system__ : → Système de référence spatiale (label Dénomination, txt_idx Identifiant textuel, srid SRID, auth_name Registre) - Système de référence spatiale
x : Nombre à virgule - X/Long
y : Nombre à virgule - Y/Lat
z : Nombre à virgule - Z

Le détail du fonctionnement de ces champs est explicité dans « Principes > Notions avancées > Données géographiques ».

Personne¶

Chaque personne dispose des champs adresse, ainsi que des champs suivants :

adminact_operation_in_charge__ : → Actes administratifs (responsable de suivi scientifique)
adminact_scientist__ : → Actes administratifs (responsable d'opération)
attached_to__ : → Organisation - Est rattaché à
author__ : → Auteurs (personne)
cached_label : Texte - Nom en cache
cira_rapporteur__ : → Opérations (rapporteur ctra/cira)
comment : Texte - Commentaire
contact_type : Chaîne de caractères (300) - Type de contact
file_responsability__ : → Dossiers archéologiques (personne responsable)
general_contractor_files__ : → Dossiers archéologiques (aménageur)
manage_treatments__ : → Traitements (responsable de suivi scientifique)
minutes_writer__ : → Opérations (rédacteur du procès verbal)
name : Chaîne de caractères (200) - Nom
old_title : Chaîne de caractères (100) - Titre
operation_collaborator__ : → Opérations (collaborateurs)
operation_monitoring__ : → Opérations (responsable de suivi scientifique)
operation_protagonist__ : → Opérations (nom du protagoniste)
operation_scientist_responsability__ : → Opérations (responsable de suivi scientifique)
person_types__ : → Type de personne (label Dénomination, txt_idx Identifiant textuel) - Types
precise_town__ : → Commune (name Nom, numero_insee Code commune (numéro INSEE), cached_label Nom en cache) - Commune (précis)
raw_name : Chaîne de caractères (300) - Nom brut
responsible_town_planning_service_files__ : → Dossiers archéologiques (responsable pour le service instructeur)
salutation : Chaîne de caractères (200) - Formule d'appel
scientist__ : → Dossiers archéologiques (responsable d'opération)
signatory__ : → Actes administratifs (signataire)
site_collaborator__ : → Entités archéologiques (collaborateurs)
surname : Chaîne de caractères (50) - Prénom - Attention, résidu historique et malheureux dans le code d'une erreur de traduction initiale (surname correspond en anglais au nom de famille, pas au prénom).
title__ : → Type de titre (label Dénomination, txt_idx Identifiant textuel, grammatical_gender Genre grammatical - "M": Masculin ; "F": Féminin ; "N": Neutre, long_title Titre long) - Titre
treatmentfile_applicant__ : → Demandes de traitement (demandeur)
treatmentfile_responsability__ : → Demandes de traitement (personne responsable)
treatments__ : → Traitements (responsable)
warehouse_in_charge__ : → Lieux de conservation (personne responsable)

Auteur¶

author_type__ : → Type d'auteur (label Dénomination, txt_idx Identifiant textuel) - Type d'auteur
cached_label : Texte - Nom en cache
documents__ : → Documents (auteurs)
person__ : → Personne - Personne

Organisation¶

Chaque organisation dispose des champs adresse, ainsi que des champs suivants :

adminact_operator__ : → Actes administratifs (opérateur d'archéologie préventive)
cached_label : Texte - Nom en cache
files__ : → Dossiers archéologiques (organisation)
general_contractor_files__ : → Dossiers archéologiques (organisation de l'aménageur)
grammatical_gender : Chaîne de caractères (1) - Genre grammatical - "M": Masculin ; "F": Féminin ; "N": Neutre
members__ : → Personnes (est rattaché à)
name : Chaîne de caractères (500) - Nom
operation_applicant_authority__ : → Opérations (autorité requérante)
operator__ : → Opérations (opérateur)
organization_type__ : → Type d'organisation (label Dénomination, txt_idx Identifiant textuel, grammatical_gender Genre grammatical - "M": Masculin ; "F": Féminin ; "N": Neutre) - Type
planning_service_files__ : → Dossiers archéologiques (service instructeur)
precise_town__ : → Commune (name Nom, numero_insee Code commune (numéro INSEE), cached_label Nom en cache) - Commune (précis)
publish__ : → Documents (éditions)
treatmentfile_applicant__ : → Demandes de traitement (organisation demandeuse)
treatments__ : → Traitements (organisation)
url : Adresse web (200) - Adresse web
warehouses__ : → Lieux de conservation (organisation)

Documentation¶

additional_information : Texte - Information supplémentaire
administrativeacts__ : → Actes administratifs (documents)
associated_file : Image (255) - Dossier associé - La taille maximale supportée pour le fichier est de 100 Mo.
associated_links : Texte - Liens symboliques
associated_url : Adresse web (1000) - Ressource numérique (adresse web)
authors__ : → Auteur - Auteurs
authors_raw : Chaîne de caractères (250) - Auteurs (brut)
cache_related_label : Texte - Lié - Valeur en cache - ne pas éditer
children__ : → Documents (source)
comment : Texte - Commentaire
complete_identifier : Texte - Identifiant complet
container_id : Entier positif - ID contenant
container_ref_id : Entier positif - ID contenant
containers__ : → Contenants (documents)
context_records__ : → Unité d'Enregistrement (documents)
creation_date : Date - Date de création
custom_index : Entier - Custom index
description : Texte - Description
duplicate : Booléen - Existe en doublon
external_id : Texte - Identifiant
files__ : → Dossiers archéologiques (documents)
finds__ : → Mobilier (documents)
format_type__ : → Type de format (label Dénomination, txt_idx Identifiant textuel) - Format
image : Image (255) - image - La taille maximale supportée pour le fichier est de 100 Mo.
index : Entier - Index
internal_reference : Texte - Réf. interne
isbn : Chaîne de caractères (17) - ISBN
issn : Chaîne de caractères (10) - ISSN
item_number : Entier - Nombre d'éléments
language__ : → Langue (label Dénomination, txt_idx Identifiant textuel) - Langue
licenses__ : → Type de licence (label Dénomination, txt_idx Identifiant textuel) - Licence
main_image_administrativeacts__ : → Actes administratifs (image principale)
main_image_containers__ : → Contenants (image principale)
main_image_context_records__ : → Unité d'Enregistrement (image principale)
main_image_finds__ : → Mobilier (image principale)
main_image_operations__ : → Opérations (image principale)
main_image_sites__ : → Entités archéologiques (image principale)
main_image_treatment_files__ : → Demandes de traitement (image principale)
main_image_treatments__ : → Traitements (image principale)
main_image_warehouses__ : → Lieux de conservation (image principale)
operations__ : → Opérations (documents)
publisher__ : → Organisation - Éditions
publishing_year : Entier positif - Année de publication
qrcode : Image (255) - qrcode
receipt_date : Date - Date de réception
receipt_date_in_documentation : Date - Date de réception en documentation
reference : Texte - Réf.
scale : Chaîne de caractères (30) - Échelle
sites__ : → Entités archéologiques (documents)
source__ : → Document - Source
source_free_input : Chaîne de caractères (500) - Source - saisie libre
source_page_range : Chaîne de caractères (500) - Source - intervalle de pages
source_type__ : → Type de document (label Dénomination, txt_idx Identifiant textuel) - Type
support_type__ : → Type de support (label Dénomination, txt_idx Identifiant textuel) - Support
tags__ : → Mot-clé du document (label Dénomination, txt_idx Identifiant textuel) - Mots-clés
thumbnail : Image (255) - thumbnail - La taille maximale supportée pour le fichier est de 100 Mo.
title : Texte - Titre
treatment_files__ : → Demandes de traitement (documents)
treatments__ : → Traitements (documents)
warehouses__ : → Lieux de conservation (documents)

Acte administratif¶

act_object : Texte - Objet
act_type__ : → Type d'acte (label Dénomination, txt_idx Identifiant textuel) - Type d'acte
associated_file__ : → Dossier archéologique - Dossier archéologique
comment : Texte - Commentaire
departments_label : Texte - Départements - Valeur en cache des départements associés
documents__ : → Document - Documents
in_charge__ : → Personne - Responsable de suivi scientifique
index : Entier - Index
main_image__ : → Document - Image principale
operation__ : → Opération - Opération
operator__ : → Organisation - Opérateur d'archéologie préventive
property__ : → Propriétés (acte administratif)
ref_sra : Chaîne de caractères (15) - Référence SRA
scientist__ : → Personne - Responsable d'opération
signatory__ : → Personne - Signataire
signature_date : Date - Date de signature
towns_label : Texte - Communes - Valeur en cache des communes associées
treatment__ : → Traitement - Traitement
treatment_file__ : → Demande de traitement - Demande de traitement
year : Entier - Année

Parcelle¶

associated_file__ : → Dossier archéologique - Dossier
cached_label : Texte - Nom en cache
context_record__ : → Unité d'Enregistrement (parcelle)
external_id : Chaîne de caractères (100) - Identifiant
operation__ : → Opération - Opération
owners__ : → Propriétaires de parcelle (parcelle)
parcel_number : Chaîne de caractères (6) - Numéro de parcelle
public_domain : Booléen - Domaine public
section : Chaîne de caractères (4) - Section
year : Entier - Année

Datation¶

context_records__ : → Unité d'Enregistrement (datings)
dating_type__ : → Type de datation (label Dénomination, txt_idx Identifiant textuel) - Type de datation
end_date : Entier - Date de fin
find__ : → Mobilier (datation)
period__ : → Type de période (label Dénomination, txt_idx Identifiant textuel) - Période
precise_dating : Texte - Datation précise
quality__ : → Type de qualité de datation (label Dénomination, txt_idx Identifiant textuel) - Qualité
start_date : Entier - Date de début

Modèles des éléments principaux¶

Opération¶

Chaque opération dispose des champs géographiques, du champ data__ ainsi que des champs suivants :

abstract : Texte - Résumé
administrative_act__ : → Actes administratifs (opération)
applicant_authority__ : → Organisation - Autorité requérante
archaeological_sites__ : → Entité archéologique - Entités archéologiques
associated_file__ : → Dossier archéologique - Dossier
cached_label : Chaîne de caractères (500) - Nom en cache - Généré automatiquement - ne pas éditer
cached_periods : Texte - Nom en cache des périodes - Généré automatiquement - ne pas éditer
cached_remains : Texte - Nom en cache des vestiges - Généré automatiquement - ne pas éditer
cached_towns_label : Texte - Nom en cache des communes - Généré automatiquement - ne pas éditer
cira_date : Date - Date avis CTRA/CIRA
cira_rapporteur__ : → Personne - Rapporteur CTRA/CIRA
code_patriarche : Texte - Code PATRIARCHE
collaborators__ : → Personne - Collaborateurs
comment : Texte - Commentaire
common_name : Texte - Nom générique
complete_identifier : Texte - Identifiant complet
containers : Liste des contenants associés - Champ non disponible pour les imports
context_record__ : → Unité d'Enregistrement (opération)
context_records : Liste des unités d'enregistrement associées - Champ non disponible pour les imports
cost : Entier - Coût (euros)
creation_date : Date - Date de création
custom_index : Entier - Custom index
documentation_deadline : Date - Date limite de versement de la documentation
documentation_received : Booléen - Documentation reçue
documents__ : → Document - Documents
drassm_code : Chaîne de caractères (100) - Code DRASSM
eas_number : Chaîne de caractères (20) - Numéro de l'EA
effective_man_days : Entier - Jours-hommes effectifs
end_date : Date - Date de clôture
excavation_end_date : Date - Date de fin de chantier
finds_deadline : Date - Date limite de versement du mobilier
finds_received : Booléen - Mobilier reçu
fnap_cost : Entier - Financement FNAP (€)
fnap_financing : Nombre à virgule - Financement FNAP (%)
geoarchaeological_context_prescription : Booléen - Prescription sur un contexte géoarchéologique
in_charge__ : → Personne - Responsable de suivi scientifique
large_area_prescription : Booléen - Prescription sur une vaste surface
left_relations__ : → Relations entre opérations (right record)
main_image__ : → Document - Image principale
minutes_writer__ : → Personne - Rédacteur du procès verbal
negative_result : Booléen - Résultat considéré comme négatif
official_report_number : Texte - Numéro de procès-verbal ou de saisine
old_code : Chaîne de caractères (200) - Ancien code
operation_code : Entier - Identifiant numérique
operation_type__ : → Type d'opération (label Dénomination, txt_idx Identifiant textuel) - Type d'opération
operationbydepartment__ : → operation by departments (opération)
operator__ : → Organisation - Opérateur
operator_reference : Chaîne de caractères (20) - Référence de l'opérateur
optional_man_days : Entier - Jours-hommes optionnels
parcels__ : → Parcelles (opération)
periods__ : → Type de période (label Dénomination, txt_idx Identifiant textuel) - Périodes
protagonist__ : → Personne - Nom du protagoniste
qrcode : Image (255) - qrcode
record_quality_type__ : → Type de qualité d'enregistrement (label Dénomination, txt_idx Identifiant textuel) - Qualité d'enregistrement
relation_bitmap_image : Image (100) - Image des relations (PNG généré) - La taille maximale supportée pour le fichier est de 100 Mo.
relation_image : Image (100) - Image des relations (SVG généré) - La taille maximale supportée pour le fichier est de 100 Mo.
remains__ : → Type de vestige (label Dénomination, txt_idx Identifiant textuel) - Vestiges
report_delivery_date : Date - Date de livraison du rapport
report_processing__ : → Type d'état de rapport (label Dénomination, txt_idx Identifiant textuel) - Traitement du rapport
right_relations__ : → Relations entre opérations (left record)
scheduled_man_days : Entier - Jours-hommes prévus
scientific_documentation_comment : Texte - Commentaire relatif à la documentation scientifique
scientist__ : → Personne - Responsable de suivi scientifique
seizure_name : Texte - Nom de la saisie
spatial_reference_system__ : → Système de référence spatiale (label Dénomination, txt_idx Identifiant textuel, srid SRID, auth_name Registre) - Système de référence spatiale
start_date : Date - Date de début
surface : Nombre à virgule - Surface (m2)
top_sites__ : → Entité archéologique - Sites pour lesquels cette opération est une opération chapeau
towns__ : → Commune (name Nom, numero_insee Code commune (numéro INSEE), cached_label Nom en cache) - Communes
virtual_operation : Booléen - Opération virtuelle - Si coché, cela signifie que cette opération n'a pas été officiellement enregistrée.
year : Entier - Année
zoning_prescription : Booléen - Prescription sur zonage

Site/Entité archéologique¶

Chaque site/entité archéologique dispose des champs géographiques, du champ data__ ainsi que des champs suivants :

affmar_number : Chaîne de caractères (100) - Numéro AffMar
cached_label : Texte - Nom en cache - Généré automatiquement - ne pas éditer
cached_periods : Texte - Nom en cache des périodes - Généré automatiquement - ne pas éditer
cached_remains : Texte - Nom en cache des vestiges - Généré automatiquement - ne pas éditer
cached_towns_label : Texte - Nom en cache des communes - Généré automatiquement - ne pas éditer
collaborators__ : → Personne - Collaborateurs
comment : Texte - Commentaire
complete_identifier : Texte - Identifiant complet
context_records__ : → Unité d'Enregistrement (entité archéologique)
cultural_attributions__ : → Type d'attribution culturelle (label Dénomination, txt_idx Identifiant textuel) - Attribution culturelle
custom_index : Entier - Custom index
discovery_area : Texte - Zone de découverte
documents__ : → Document - Documents
drassm_number : Chaîne de caractères (100) - Numéro DRASSM
locality_cadastral : Texte - Lieu-dit cadastre
locality_ngi : Texte - Lieu-dit IGN
main_image__ : → Document - Image principale
name : Chaîne de caractères (200) - Nom
oceanographic_service_localisation : Texte - Localisation SHOM
operations__ : → Opérations (entités archéologiques)
other_reference : Texte - Autre référence
periods__ : → Type de période (label Dénomination, txt_idx Identifiant textuel) - Périodes
qrcode : Image (255) - qrcode
reference : Chaîne de caractères (200) - Référence
remains__ : → Type de vestige (label Dénomination, txt_idx Identifiant textuel) - Vestiges
shipwreck_code : Texte - Code épave
shipwreck_name : Texte - Nom de l'épave
sinking_date : Date - Date de naufrage
spatial_reference_system__ : → Système de référence spatiale (label Dénomination, txt_idx Identifiant textuel, srid SRID, auth_name Registre) - Système de référence spatiale
top_operations__ : → Opérations (sites pour lesquels cette opération est une opération chapeau)
towns__ : → Commune (name Nom, numero_insee Code commune (numéro INSEE), cached_label Nom en cache) - Communes

Dossier archéologique¶

Chaque dossier archéologique dispose du champ data__ ainsi que des champs suivants :

administrative_act__ : → Actes administratifs (dossier archéologique)
cached_label : Texte - Nom en cache - Généré automatiquement - ne pas éditer
cira_advised : Booléen - Passage en CIRA
classified_area : Booléen - Au sein d'un site classé
comment : Texte - Commentaire
complete_identifier : Texte - Identifiant complet
corporation_general_contractor__ : → Organisation - Organisation de l'aménageur
creation_date : Date - Date de création
custom_index : Entier - Custom index
departments__ : → Département - Départements
documents__ : → Document - Documents
end_date : Date - Date de fin
equipment_costs__ : → preventive file equipment service costs (file)
execution_report_date : Date - Date du rapport d'exécution
external_id : Chaîne de caractères (120) - Identifiant
file__ : → Dossiers archéologiques (dossier associé)
file_type__ : → Type de dossier archéologique (label Dénomination, txt_idx Identifiant textuel) - Type de dossier
filebydepartment__ : → file by departments (dossier)
general_contractor__ : → Personne - Aménageur
ground_end_date : Date - Date de fin de la fouille
ground_jobs__ : → preventive file ground jobs (file)
ground_start_date : Date - Date de début de la fouille
imported_line : Texte - Ligne importée
in_charge__ : → Personne - Personne responsable
instruction_deadline : Date - Date limite d'instruction
internal_reference : Chaîne de caractères (60) - Référence interne
intervention_period : Chaîne de caractères (200) - Période d'intervention
jobs__ : → preventive file jobs (file)
linear_meter : Entier - Mètre linéaire
locality : Chaîne de caractères (100) - Lieu-dit
main_town__ : → Commune (name Nom, numero_insee Code commune (numéro INSEE), cached_label Nom en cache) - Commune principale
mh_listing : Booléen - Sur Monument Historique inscrit
mh_register : Booléen - Sur Monument Historique classé
name : Texte - Nom
numeric_reference : Entier - Identifiant numérique
operation_type_for_royalties__ : → Type d'opération pour les redevances - France (label Dénomination, txt_idx Identifiant textuel) - Type d'opération pour la redevance
operations__ : → Opérations (dossier)
organization__ : → Organisation - Organisation
parcels__ : → Parcelles (dossier)
permit_reference : Texte - Référence du permis / de l'arrêté
permit_type__ : → Type de permis (label Dénomination, txt_idx Identifiant textuel) - Type de permis
planning_service__ : → Organisation - Service instructeur
planning_service_date : Date - Date du dossier du service instructeur
price_agreement__ : → Contrat tarifaire (label Dénomination, txt_idx Identifiant textuel) - Contrat tarifaire
protected_area : Booléen - Au sein d'un secteur sauvegardé
qrcode : Image (255) - qrcode
raw_general_contractor : Chaîne de caractères (200) - Aménageur (brut)
raw_town_planning_service : Chaîne de caractères (200) - Service instructeur (brut)
reception_date : Date - Date de réception
related_file__ : → Dossier archéologique - Dossier associé
report_due_period : Chaîne de caractères (200) - Période de remise du rapport
requested_operation_type__ : → Type d'opération (label Dénomination, txt_idx Identifiant textuel) - Type d'opération demandée
research_comment : Texte - Commentaire relatif à l'archéologie programmée
responsible_town_planning_service__ : → Personne - Responsable pour le service instructeur
saisine_type__ : → Type de saisine (label Dénomination, txt_idx Identifiant textuel) - Type de saisine
scientist__ : → Personne - Responsable d'opération
start_date : Date - Date de début
study_period : Chaîne de caractères (200) - Période d'étude
total_developed_surface : Nombre à virgule - Surface totale aménagée (m2)
total_surface : Nombre à virgule - Surface totale (m2)
towns__ : → Commune (name Nom, numero_insee Code commune (numéro INSEE), cached_label Nom en cache) - Communes
type_of_agreement__ : → Type de convention - France (label Dénomination, txt_idx Identifiant textuel) - Type de convention
year : Entier - Année

Unité d'enregistrement¶

Chaque unité d'enregistrement dispose des champs géographiques, du champ data__ ainsi que des champs suivants :

activity__ : → Type d'activité (label Dénomination, txt_idx Identifiant textuel) - Activité
archaeological_site__ : → Entité archéologique - Entité archéologique
base_finds : Liste du mobilier de base associé - Champ non disponible pour les imports
base_finds__ : → Mobilier d'origine (unité d'enregistrement)
cached_label : Texte - Nom en cache
cached_periods : Texte - Nom en cache des périodes - Généré automatiquement - ne pas éditer
cached_related_context_records : Texte - Nom en cache des unités d'enregistrements liées - Généré automatiquement - ne pas éditer
closing_date : Date - Date de clôture
comment : Texte - Commentaire général
complete_identifier : Texte - Identifiant complet
context_record_tree_child__ : → context record trees (unité d'enregistrement parente)
context_record_tree_parent__ : → context record trees (unité d'enregistrement)
contextrecord__ : → Unité d'Enregistrement (related context records)
custom_index : Entier - Custom index
datings__ : → Datation - datings
datings_comment : Texte - Commentaire relatif aux datations
depth : Nombre à virgule - Profondeur (m)
depth_of_appearance : Nombre à virgule - Profondeur d'apparition (m)
description : Texte - Description
diameter : Nombre à virgule - Diamètre (m)
documentations__ : → Type de documentation (label Dénomination, txt_idx Identifiant textuel) - documentations
documents__ : → Document - Documents
excavation_technic__ : → Type de méthode de fouille (label Dénomination, txt_idx Identifiant textuel) - Méthode de fouille
external_id : Texte - Identifiant
filling : Texte - Remplissage
identification__ : → Type d'identification (label Dénomination, txt_idx Identifiant textuel) - Identification
interpretation : Texte - Interprétation
label : Chaîne de caractères (200) - Identifiant
left_relations__ : → Relations entre Unités d'Enregistrement (right record)
length : Nombre à virgule - Taille (m)
location : Texte - Localisation - Une courte description de la localisation de l'Unité d'Enregistrement
main_image__ : → Document - Image principale
opening_date : Date - Date d'ouverture
operation__ : → Opération - Opération
parcel__ : → Parcelle - Parcelle
qrcode : Image (255) - qrcode
related_context_records__ : → Unité d'Enregistrement - related context records
relation_bitmap_image : Image (100) - Image des relations (PNG généré) - La taille maximale supportée pour le fichier est de 100 Mo.
relation_image : Image (100) - Image des relations (SVG généré) - La taille maximale supportée pour le fichier est de 100 Mo.
right_relations__ : → Relations entre Unités d'Enregistrement (left record)
spatial_reference_system__ : → Système de référence spatiale (label Dénomination, txt_idx Identifiant textuel, srid SRID, auth_name Registre) - Système de référence spatiale
surface : Nombre à virgule - Surface (m2)
taq : Entier - TAQ - « Terminus Ante Quem ». L'Unité d'Enregistrement ne peut avoir été créée après cette date
taq_estimated : Entier - TAQ estimé - Estimation d'un « Terminus Ante Quem »
thickness : Nombre à virgule - Épaisseur (m)
tpq : Entier - TPQ - « Terminus Post Quem ». L'Unité d'Enregistrement ne peut avoir été créée avant cette date
tpq_estimated : Entier - TPQ estimé - Estimation d'un « Terminus Post Quem »
unit__ : → Type d'Unité d'Enregistrement (label Dénomination, txt_idx Identifiant textuel) - Type d'Unité d'Enregistrement
width : Nombre à virgule - Largeur (m)

Mobilier d'origine¶

Chaque mobilier d'origine dispose des champs géographiques, du champ data__ ainsi que des champs suivants :

batch__ : → Type de lot (label Dénomination, txt_idx Identifiant textuel) - Lot/objet
cache_complete_id : Texte - Identifiant complet - Valeur en cache - ne pas éditer
cache_short_id : Texte - Identifiant court - Valeur en cache - ne pas éditer
comment : Texte - Commentaire
complete_identifier : Texte - Identifiant complet
context_record__ : → Unité d'Enregistrement - Unité d'Enregistrement
custom_index : Entier - Custom index
description : Texte - Description
discovery_date : Date - Date de découverte (exacte ou TPQ)
discovery_date_taq : Date - Date de découverte (TAQ)
excavation_id : Texte - Identifiant fouille
external_id : Texte - Identifiant
find__ : → Mobilier (mobilier d'origine)
index : Entier - Index
label : Texte - Identifiant libre
line : Ligne - Ligne
material_index : Entier - Index matériel
material_type_label : Concaténation des types de matériaux associés - Champ non disponible pour les imports
qrcode : Image (255) - qrcode
spatial_reference_system__ : → Système de référence spatiale (label Dénomination, txt_idx Identifiant textuel, srid SRID, auth_name Registre) - Système de référence spatiale
special_interest : Chaîne de caractères (120) - Intérêt spécifique
topographic_localisation : Chaîne de caractères (120) - Point topographique

Mobilier¶

Chaque élément mobilier dispose du champ data__ ainsi que des champs suivants :

alteration_causes__ : → Type de cause d'altération (label Dénomination, txt_idx Identifiant textuel) - Cause d'altération
alterations__ : → Type d'altération (label Dénomination, txt_idx Identifiant textuel) - Altération
appraisal_date : Date - Date d'évaluation
base_finds : Liste du mobilier de base associé - Champ non disponible pour les imports
base_finds__ : → Mobilier d'origine - Mobilier d'origine
basket__ : → Paniers (items)
cached_label : Texte - Nom en cache - Généré automatiquement - ne pas éditer
cached_materials : Texte - Nom en cache des types de matériaux - Généré automatiquement - ne pas éditer
cached_object_types : Texte - Nom en cache des types d'objet - Généré automatiquement - ne pas éditer
cached_periods : Texte - Nom en cache des périodes - Généré automatiquement - ne pas éditer
check_date : Date - Date de vérification
checked_type__ : → Type de vérification (label Dénomination, txt_idx Identifiant textuel) - Vérification
circumference : Nombre à virgule - Circonférence (cm)
clutter_height : Nombre à virgule - Encombrement - hauteur (cm)
clutter_long_side : Nombre à virgule - Encombrement - grand côté (cm)
clutter_short_side : Nombre à virgule - Encombrement - petit côté (cm)
collection__ : → Lieu de conservation - Collection - Ne pas utiliser - Nécessite des évolutions
comment : Texte - Commentaire
communicabilities__ : → Type de communicabilité (label Dénomination, txt_idx Identifiant textuel) - Communicabilité
complete_id : Identifiant complet du mobilier d'origine associé - Champ non disponible pour les imports
complete_identifier : Texte - Identifiant complet
conservatory_comment : Texte - Commentaire relatif à la conservation
conservatory_state__ : → Type d'état de conservation (label Dénomination, txt_idx Identifiant textuel) - État de conservation
container__ : → Contenant - Contenant
container_ref__ : → Contenant - Contenant de référence
context_record_label : Dénomination des unités d'enregistrement associées - Champ non disponible pour les imports
cultural_attributions__ : → Type d'attribution culturelle (label Dénomination, txt_idx Identifiant textuel) - Attribution culturelle
custom_index : Entier - Custom index
dating_comment : Texte - Commentaire relatif aux datations
datings__ : → Datation - Datation
decoration : Texte - Décor
denomination : Texte - Dénomination
description : Texte - Description
diameter : Nombre à virgule - Diamètre (cm)
dimensions_comment : Texte - Commentaire relatif aux dimensions
documents__ : → Document - Documents
downstream_treatment__ : → Traitement - Traitement aval
estimated_value : Nombre à virgule - Valeur estimée
external_id : Texte - Identifiant
find_number : Entier - Mobilier (en nombre)
finddownstreamtreatments_related__ : → find downstream treatmentss (mobilier)
findnonmodiftreatments_related__ : → find non modif treatmentss (mobilier)
findtreatments_related__ : → find treatmentss (mobilier)
findupstreamtreatments_related__ : → find upstream treatmentss (mobilier)
functional_areas__ : → Domaine fonctionnel (label Dénomination, txt_idx Identifiant textuel) - Domaine fonctionnel
height : Nombre à virgule - Hauteur (cm)
index : Entier - Index
inscription : Texte - Inscription
inside_container__ : → find inside container (mobilier)
insurance_value : Nombre à virgule - Valeur d'assurance
integrities__ : → Type d'intégrité / intérêt (label Dénomination, txt_idx Identifiant textuel) - Intégrité / intérêt
is_complete : Booléen - Est complet ?
label : Texte - Identifiant libre
laboratory_id : Texte - Numéro de laboratoire
length : Nombre à virgule - Longueur (cm)
main_image__ : → Document - Image principale
manufacturing_place : Texte - Lieu de fabrication
mark : Texte - Marquage
material_comment : Texte - Commentaire relatif au matériau
material_type_quality__ : → Type de qualité du type de matériaux (label Dénomination, txt_idx Identifiant textuel) - Qualité du type de matériaux
material_types__ : → Type de matériau (label Dénomination, txt_idx Identifiant textuel) - Types de matériau
material_types_code : Code des types de matériau - Champ non disponible pour les imports
material_types_label : Chaîne de caractère des types de matériau - Champ non disponible pour les imports
material_types_recommendations : Chaîne de caractères - recommandations pour le matériau - Champ non disponible pour les imports
min_number_of_individuals : Entier - Nombre minimum d'individus (NMI)
museum_id : Texte - Identifiant musée
object_type_quality__ : → Type de qualité du type d'objet (label Dénomination, txt_idx Identifiant textuel) - Qualité du type d'objet
object_types__ : → Type d'objet (label Dénomination, txt_idx Identifiant textuel) - Types d'objet
order : Entier - Ordre
preservation_to_considers__ : → Type de traitement (label Dénomination, txt_idx Identifiant textuel) - Traitements recommandés
previous_id : Texte - Identifiant précédent
property__ : → Propriétés (mobilier)
public_description : Texte - Description publique
qrcode : Image (255) - qrcode
remarkabilities__ : → Type de remarquabilité (label Dénomination, txt_idx Identifiant textuel) - Remarquabilité
seal_number : Texte - Numéro de scellé
thickness : Nombre à virgule - Épaisseur (cm)
treatment_emergency__ : → Type d'urgence de traitement (label Dénomination, txt_idx Identifiant textuel) - Urgence du traitement
treatments__ : → Traitement - Traitements - Traitements associés quand il n'y a pas de création de nouveau mobilier
upstream_treatment__ : → Traitement - Traitement amont
volume : Nombre à virgule - Volume (l)
weight : Nombre à virgule - Poids
weight_unit : Chaîne de caractères (4) - Unité de poids
width : Nombre à virgule - Largeur (cm)

Traitement¶

Chaque traitement dispose du champ data__ ainsi que des champs suivants :

administrative_act__ : → Actes administratifs (traitement)
cached_label : Texte - Nom en cache
comment : Texte - Commentaire
container__ : → Contenant - Contenant
creation_date : Date/heure - creation date
description : Texte - Description
documents__ : → Document - Documents
downstream__ : → Mobilier (traitement amont)
end_date : Date - Date de clôture
estimated_cost : Nombre à virgule - Coût estimé
executed : Booléen - Le traitement a été réalisé
external_id : Chaîne de caractères (200) - Identifiant
file__ : → Demande de traitement - Demande associée
finddownstreamtreatments__ : → find downstream treatments (traitement)
findnonmodiftreatments__ : → find non modif treatments (traitement)
finds__ : → Mobilier (traitements)
findtreatments__ : → find treatments (traitement)
findupstreamtreatments__ : → find upstream treatments (traitement)
goal : Texte - But
image : Image (255) - image - La taille maximale supportée pour le fichier est de 100 Mo.
index : Entier - Index
insurance_cost : Nombre à virgule - Coût d'assurance
label : Chaîne de caractères (200) - Dénomination
location__ : → Lieu de conservation - Localisation - Endroit où le traitement est réalisé. Renseignez le lieu de conservation de destination pour un déplacement.
main_image__ : → Document - Image principale
organization__ : → Organisation - Organisation
other_reference : Chaîne de caractères (200) - Autre réf.
person__ : → Personne - Responsable
quoted_cost : Nombre à virgule - Coût devisé
realized_cost : Nombre à virgule - Coût réalisé
scientific_monitoring_manager__ : → Personne - Responsable de suivi scientifique
start_date : Date - Date de début
thumbnail : Image (255) - thumbnail - La taille maximale supportée pour le fichier est de 100 Mo.
treatment_state__ : → Type d'état de traitement (label Dénomination, txt_idx Identifiant textuel) - État
treatment_types__ : → Type de traitement (label Dénomination, txt_idx Identifiant textuel) - Type de traitement
upstream__ : → Mobilier (traitement aval)
year : Entier - Année

Demande de traitement¶

Chaque demande de traitement dispose du champ data__ ainsi que des champs suivants :

administrative_act__ : → Actes administratifs (demande de traitement)
applicant__ : → Personne - Demandeur
applicant_organisation__ : → Organisation - Organisation demandeuse
associated_basket__ : → Panier - associated basket
cached_label : Texte - Nom en cache
comment : Texte - Commentaire
creation_date : Date - Date de création
documents__ : → Document - Documents
end_date : Date - Date de clôture
exhibition_end_date : Date - Date de fin de l'exposition
exhibition_name : Texte - Nom d'exposition
exhibition_start_date : Date - Date de commencement de l'exposition
external_id : Chaîne de caractères (200) - Identifiant
in_charge__ : → Personne - Personne responsable
index : Entier - Index
internal_reference : Chaîne de caractères (200) - Référence interne
main_image__ : → Document - Image principale
name : Texte - Nom
reception_date : Date - Date de réception
treatments__ : → Traitements (demande associée)
type__ : → Type de demande de traitement (label Dénomination, txt_idx Identifiant textuel) - Type de demande de traitement
year : Entier - Année

Dépot¶

Chaque dépot dispose des champs adresse, des champs géographiques, du champ data__ ainsi que des champs suivants :

associated_divisions__ : → Type de division de lieu de conservation (label Dénomination, txt_idx Identifiant textuel) - Divisions
comment : Texte - Commentaire
complete_identifier : Texte - Identifiant complet
containers__ : → Contenants (lieu de conservation)
custom_index : Entier - Custom index
divisions__ : → warehouse division links (warehouse)
documents__ : → Document - Documents
external_id : Texte - Identifiant
finds__ : → Mobilier (collection)
main_image__ : → Document - Image principale
max_division_number : Entier - Nombre maximum de divisions - Généré automatiquement
name : Chaîne de caractères (200) - Nom
organization__ : → Organisation - Organisation
owned_containers__ : → Contenants (lieu de conservation responsable)
person_in_charge__ : → Personne - Personne responsable
precise_town__ : → Commune (name Nom, numero_insee Code commune (numéro INSEE), cached_label Nom en cache) - Commune (précis)
qrcode : Image (255) - qrcode
responsibilities__ : → Contenants (responsabilité)
spatial_reference_system__ : → Système de référence spatiale (label Dénomination, txt_idx Identifiant textuel, srid SRID, auth_name Registre) - Système de référence spatiale
treatment__ : → Traitements (localisation)
warehouse_type__ : → Type de lieu de conservation (label Dénomination, txt_idx Identifiant textuel) - Type de lieu de conservation

Contenant¶

Chaque contenant dispose des champs géographiques, du champ data__ ainsi que des champs suivants :

cached_division : Texte - Division mise en cache
cached_label : Texte - Localisation
cached_location : Texte - Localisation - en cache
cached_weight : Nombre à virgule - Poids mis en cache (g) - Poids saisi si disponible sinon poids calculé.
calculated_weight : Nombre à virgule - Poids calculé (g)
children__ : → Contenants (contenant parent)
comment : Texte - Commentaire
complete_identifier : Texte - Identifiant complet
container_content__ : → find inside containers (contenant)
container_tree_child__ : → container tree (contenant)
container_tree_parent__ : → container trees (contenant parent)
container_type__ : → Type de contenant (label Dénomination, txt_idx Identifiant textuel) - Type de contenant
context_record_ : Unité d'Enregistrement associée - à utiliser avec précaution seule la première unité d'enregistrement trouvée est retournée - Champ non disponible pour les imports
custom_index : Entier - Custom index
division__ : → Localisations de contenant (contenant)
documents__ : → Document - Documents
external_id : Texte - Identifiant
finds : Liste du mobilier associé - Champ non disponible pour les imports
finds__ : → Mobilier (contenant)
finds_ref__ : → Mobilier (contenant de référence)
index : Entier - ID contenant
location__ : → Lieu de conservation - Lieu de conservation
main_image__ : → Document - Image principale
material_types : Types de matériaux dans le contenant - chaîne de caractères - Champ non disponible pour les imports
material_types_code : Code des types de matériau - chaîne de caractères - Champ non disponible pour les imports
old_reference : Texte - Ancienne référence
operation_ : Opération associée - à utiliser avec précaution seule la première opération trouvée est retournée - Champ non disponible pour les imports
parent__ : → Contenant - Contenant parent
qrcode : Image (255) - qrcode
reference : Texte - Réf. du contenant
responsibility__ : → Lieu de conservation - Responsabilité - Lieu de conservation auquel le contenant appartient
responsible__ : → Lieu de conservation - Lieu de conservation responsable - Obsolète - ne pas utiliser
spatial_reference_system__ : → Système de référence spatiale (label Dénomination, txt_idx Identifiant textuel, srid SRID, auth_name Registre) - Système de référence spatiale
treatment__ : → Traitements (contenant)
weight : Nombre à virgule - Poids mesuré (g)

Annexe technique 4 - Filtres pour les patrons de documents¶

Auteurs:	Étienne Loks, Valérie-Emma Leroux
Date:	2022-03-08
Copyright:	CC-BY 3.0
Ishtar Version:	v3.1.0

Les patrons de documents permettent d'utiliser des filtres sur les données de la base de données. Cela permet essentiellement de mettre en forme les champs. Certains de ces filtres sont directement disponibles via la bibliothèque Jinja utilisée dans Ishtar, d'autres ont été développés au sein d'Ishtar.

Pour utiliser un filtre, à la suite de la variable, il faut utiliser le caractère |, par exemple : {{variable|capfirst}}.

Note

Les filtres peuvent se chaîner. On peut donc écrire : {{variable|human_date|capitalize}}.

Pour les différents exemples nous utilisons directement une chaîne de caractères pour illustrer, en utilisation réelle on utilise un nom de variable.

La bibliothèque logicielle Jinja utilisée pour la génération des patrons met à disposition nativement un certain nombre de filtres : documentation des filtres de base (anglais).

Ishtar met a disposition des filtres supplémentaires :

Formatage des chaînes de caractères¶

capfirt

Ce filtre met la première lettre en majuscule et ne touche pas au reste de la chaîne.

{{"saint georges d'oléron"|capfisrt}} -> Saint georges d'oléron

lowerfirst

Ce filtre met la première lettre en minuscule et ne touche pas au reste de la chaîne

{{"SAINT-GEORGES-D'OLÉRON"|lowerfirst}} -> sAINT-GEORGES-D'OLÉRON

capitalize

Ce filtre met la première lettre de chaque mot en majuscule et le reste de la chaîne en minuscule.

{{"SAINT-GEORGES-D'OLÉRON"|capitalize}} -> Saint-Georges-d'Oléron

human_date

Ce filtre permet d'afficher une date en toutes lettres.

{{"2020-03-03"|human_date}} -> 3 mars 2020

int

Pour afficher un nombre sans décimales.

{{"600.0"|int}} -> 600

Manipulation des chaînes de caractères¶

splitpart

Ce filtre permet d'extraire un élément depuis une chaîne de caractères en prenant en compte un séparateur. Par exemple depuis la chaîne "2,3,10", accéder au troisième élément : "10".

Ce filtre nécessite au minimum un argument, le numéro de l'élément souhaité (en commençant le compte à 0) : pour avoir le second élément, il faut indiquer en argument "1".

Le second argument correspond à la borne de fin non incluse (en commençant le compte à 0) : ainsi pour avoir jusqu'au deuxième élément il faut indiquer en argument "2". Si l'on ne souhaite avoir qu'un seul élément, on indique "0".

Par défaut le séparateur "," est utilisé si l'on souhaite un autre séparateur, on spécifie celui-ci en troisème argument.

On peut associer un dernier argument qui permet de spécifier le(s) caractère(s) de concaténation que l'on souhaite utiliser pour la chaîne en retour.

{{"9,2,10"|splitpart(1)}} -> 2

{{"chaise;bureau;papier;paragraphe"|splitpart(0,0,";")}} -> chaise

{{"182025_C001"|splitpart(1,0,"_")}} -> C001

{{"chaise;bureau;papier;paragraphe"|splitpart(1,3,";")}} -> bureau;papier

{{"chaise;bureau;papier;paragraphe"|splitpart(1,4,";","|")}} -> bureau|papier|paragraphe

Annexe technique 5 - Commandes de gestion en CLI¶

Auteurs:	Étienne Loks
Date:	2021-06-21
Copyright:	CC-BY 3.0
Ishtar Version:	v3.1.0

Les commandes de gestion en CLI nécessite un accès en ligne de commande au serveur. Une fois connecté en SSH à celui-ci, on se rend dans le répertoire de l'instance sur laquelle on souhaite intervenir (par défaut : /srv/ishtar/<nom-de-l'instance>) et l'on lance la commande souhaité via un appel au de ce répertoire manage.py suivi du nom de la commande. Exemple :

root@ishtar-server:# cd /srv/ishtar/prod_deb
root@ishtar-server:# python3 ./manage.py relations_update_cache_tables

import_geofla_csv¶

Import des communes depuis les données IGN (cf. Annexe technique 2).

import_insee_comm_csv¶

Import des communes depuis les données INSEE (cf. Annexe technique 1).

relations_update_cache_tables¶

Cette commande met à jour les tables de cache des relations. Cette commande doit être impérativement lancée lorsque l'on change le type de gestion des relations depuis le profil afin de mettre à jour les tables correpondantes.

Bienvenue dans la documentation d'Ishtar !¶

Installation¶

Installation sur poste Debian Buster¶

Initialisation de la base de données¶

Initialisation des paramètres de base¶

Initialisation des communes¶

Principes¶

Présentation¶

Présentation générale¶

Fonctionnalités¶

Module administratif¶

Module lieux de conservation¶

Modules / configuration¶

Structure de la base de données¶

Opération archéologique¶

Site/entité archéologique¶

Parcelle¶

Unité d'enregistrement¶

Mobilier - Traitement¶

Mobilier - Demande de traitement¶

Contenant¶

Document¶

Les flux de données¶

Import¶

Mode opératoire¶

Atouts¶

Inconvénients¶

Cas d'utilisation¶

Ajout/modification par formulaire¶

Mode opératoire¶

Atouts¶

Inconvénients¶

Cas d'utilisation¶

Modification par lot¶

Mode opératoire¶

Atouts¶

Inconvénients¶

Cas d'utilisation¶

Notions avancées¶

Données géographiques¶

Interface utilisateur¶

Interface générale¶

Zone de profil¶

Menu d'actions¶

Zone centrale¶

Zone d'alerte et de sélection épinglée¶

Page de recherche¶

Recherche textuelle et par critères¶

Recherche libre¶

Recherche par critère¶

Marques-pages et alertes¶

Tableaux¶

Fiches¶

Entête¶

Barre d'outil¶

Contenu de la fiche¶

Navigation entre fiches¶

Page d'assistant logiciel (wizard)¶

Fil d'Ariane¶

Tableau / Zone de formulaire¶

Zone de validation¶

Utilisation avancée¶

Paniers¶

Éléments épinglés¶

Menu de gestion des sélections épinglées¶

Action rapide¶

Configuration de l'instance Ishtar¶

Listes de types¶

Champs personnalisés¶

Formulaires personnalisés¶

Gestion des permissions¶

Gestion des comptes¶

Permissions dans Ishtar¶

Permissions dans les pages d'administration¶

Patrons de documents¶

Principes de base¶

Un premier patron¶

Configuration du profil d'instance Ishtar¶

Identifiants et index personnalisés¶

Formules¶