diff options
Diffstat (limited to 'docs/fr/source')
| -rw-r--r-- | docs/fr/source/_static/interface-generale.png | bin | 89216 -> 89012 bytes | |||
| -rw-r--r-- | docs/fr/source/annexe-1-rattachement.rst | 23 | ||||
| -rw-r--r-- | docs/fr/source/annexe-2-permission-action.rst | 17 | ||||
| -rw-r--r-- | docs/fr/source/annexe-3-ex-flux-ope.rst | 92 | ||||
| -rw-r--r-- | docs/fr/source/index.rst | 3 | ||||
| -rw-r--r-- | docs/fr/source/interface-administrateur.rst | 250 | ||||
| -rw-r--r-- | docs/fr/source/interface-utilisateur.rst | 15 | ||||
| -rw-r--r-- | docs/fr/source/media-src/interface-generale.xcf | bin | 278527 -> 276491 bytes | |||
| -rw-r--r-- | docs/fr/source/principes.rst | 8 |
9 files changed, 391 insertions, 17 deletions
diff --git a/docs/fr/source/_static/interface-generale.png b/docs/fr/source/_static/interface-generale.png Binary files differindex f9c9bac22..fb054a075 100644 --- a/docs/fr/source/_static/interface-generale.png +++ b/docs/fr/source/_static/interface-generale.png diff --git a/docs/fr/source/annexe-1-rattachement.rst b/docs/fr/source/annexe-1-rattachement.rst new file mode 100644 index 000000000..2a8f041b4 --- /dev/null +++ b/docs/fr/source/annexe-1-rattachement.rst @@ -0,0 +1,23 @@ +.. -*- coding: utf-8 -*- + +.. _annexe-1-rattachement: + +============================================== +Annexe 1 - Règles de rattachement aux éléments +============================================== + +:Auteur: Étienne Loks +:Date: 2018-12-04 +:Copyright: CC-BY 3.0 + +---------------------------------- + + + + - Opération + + + +.. + TODO: Penser aux zones... + diff --git a/docs/fr/source/annexe-2-permission-action.rst b/docs/fr/source/annexe-2-permission-action.rst new file mode 100644 index 000000000..134237b81 --- /dev/null +++ b/docs/fr/source/annexe-2-permission-action.rst @@ -0,0 +1,17 @@ +.. -*- coding: utf-8 -*- + +.. _annexe-2-permission-action: + +=================================================== +Annexe 2 - Permissions nécessaires pour les actions +=================================================== + +:Auteur: Étienne Loks +:Date: 2018-12-04 +:Copyright: CC-BY 3.0 + +---------------------------------- + + + - Action1.... + diff --git a/docs/fr/source/annexe-3-ex-flux-ope.rst b/docs/fr/source/annexe-3-ex-flux-ope.rst new file mode 100644 index 000000000..462b961c1 --- /dev/null +++ b/docs/fr/source/annexe-3-ex-flux-ope.rst @@ -0,0 +1,92 @@ +.. -*- coding: utf-8 -*- + +============================================================== +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 +----------------------------------------------------------------------------- + +1. 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*. +2. Il ajoute quelques éléments à ce panier via l'action rapide « Panier » ou *Mobilier › Panier › Gestion des éléments*. +3. Ce responsable partage ce panier en lecture/édition avec les autres gestionnaires de mobilier via *Mobilier › Panier › Modification*. +4. 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*. +5. 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 +----------------------------------------------------------------------------- + +1. 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 ». +2. 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. + +.. warning:: 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. + +3. La structure emprunteuse retire du panier les éléments qui ne l'intéresse pas. +4. 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 +------------------------------------ + +1. Le responsable du prêt enleve le partage en modification du panier (*Mobilier › Panier › Modification*). +2. 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. +3. 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*. +4. 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. +5. 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é +------------------------------------ + +1. 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. + +2. 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" + +3. Avec cette requête, 30 jours avant la date de retour attendue, l'alerte sera affichée. +4. Fin d'étape : le mobilier a été retourné. + + +Gestion du retour du mobilier +----------------------------- + +1. 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. + +2. Depuis ces fiches, une demande de traitement « Constat d'état » pourra être ajoutée depuis le bouton « Ajouter une demande de traitement ». diff --git a/docs/fr/source/index.rst b/docs/fr/source/index.rst index 91ef3e740..a22a62ce0 100644 --- a/docs/fr/source/index.rst +++ b/docs/fr/source/index.rst @@ -15,3 +15,6 @@ Contents: interface-utilisateur interface-administrateur installation + annexe-1-rattachement + annexe-2-permission-action + annexe-3-ex-flux-ope diff --git a/docs/fr/source/interface-administrateur.rst b/docs/fr/source/interface-administrateur.rst index 8e8506b6d..651111826 100644 --- a/docs/fr/source/interface-administrateur.rst +++ b/docs/fr/source/interface-administrateur.rst @@ -1,17 +1,251 @@ .. -*- coding: utf-8 -*- -======================== -Interface administrateur -======================== +================================== +Configuration de l'instance Ishtar +================================== :Auteur: Étienne Loks -:Date: 2018-10-02 +: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. + +.. warning:: 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 minuscule 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 saisie 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 :ref:`formulaire personnalisé <formulaire-personnalise>`. + +.. _formulaire-personnalise: + +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. + +.. warning:: 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. :ref:`permissions dans Ishtar<permissions-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 droit 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':ref:`annexe 1 - règles de rattachement à un élément <annexe-1-rattachement>`. 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':ref:`annexe 2 - permissions nécessaires pour les actions <annexe-2-permission-action>`. + +.. 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éé 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. + +.. _document de référence: https://gitlab.com/iggdrasil/ishtar/raw/master/archaeological_operations/tests/document_reference.odt + +.. 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é entourée de deux acccolades, exemple : :: + + Je, sousigné, {{nom_de_ma_clef_1}}, vous accorde un prêt de {{nom_ma_clef_2}}. + +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. + +Notions avancées +**************** + +Conditions +++++++++++ + +Des structures conditionnelles peuvent être mise 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. + +Attributs ++++++++++ + +Les valeurs utilisées dans les patrons peuvent avoir des attributs correspondant aux noms des colonnes des tables d'éléments utilisés en base de données. Ces attributs sont accédés avec la notation ``.`` . Par exemple, si l'élément a un attribut ``nom``, on accède à la valeur de cet élément avec ``{{element.nom}}``. + + +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. + +.. + Images + ++++++ + + Il est possible d'utiliser des images dans les patrons. Pour cela il faut placer une image dans le document du patron et modifier son attribut nom sous LibreOffice (clic droit sur l'image, « Propriétés... » et l'onglet « Options ») par une chaîne sous la forme ``{{ mon_image|image }}``. ``mon_image`` correspond au champ image + + -.. _configuration-instance-ishtar: -Configuration de l'instance Ishtar ----------------------------------- -WIP +.. + TODO: Profil d'instance Ishtar diff --git a/docs/fr/source/interface-utilisateur.rst b/docs/fr/source/interface-utilisateur.rst index ce8b5b82f..a7ab19a8c 100644 --- a/docs/fr/source/interface-utilisateur.rst +++ b/docs/fr/source/interface-utilisateur.rst @@ -9,6 +9,9 @@ Interface utilisateur :Copyright: CC-BY 3.0 +---------------------------- + + Interface générale ================== @@ -55,7 +58,7 @@ La zone centrale est totalement contextuelle. Néanmoins si certaines pages d'ac Zone d'alerte et de sélection épinglée -------------------------------------- -Cette zone reprend les éventuelles alertes (cf. :ref:`Page de recherche > Marques-pages et alertes <bookmarks>`), mise en place par l'utilisateur ainsi que les éléments actuellement épinglés (cf. :ref:`Utilisation avancée > Éléments épinglés <pinned>`). +Cette zone reprend les éventuelles alertes (cf. :ref:`Page de recherche > Marques-pages et alertes <bookmarks>`), mise en place par l'utilisateur ainsi que (si l'affichage de ceux-ci est activé) les éléments actuellement épinglés (cf. :ref:`Utilisation avancée > Éléments épinglés <pinned>`). .. _page-de-recherche: @@ -73,6 +76,7 @@ La barre de recherche est composée d'une zone de saisie et d'une série d'icôn - icône « loupe » : lancer la recherche, - icône « engrenage » : accéder à la recherche par facette, - 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). @@ -179,7 +183,7 @@ Ensuite sur la droite, différentes actions sont disponibles. Ces actions dépen - une icône « épingle » : elle permet d'épingler l'élément de la fiche (cf. :ref:`épinglage <pinned>`). - 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. -- les icônes « ODT », « PDF » : ces icônes permettent un export ODT ou PDF de la fiche actuelle. +- un menu « exporter » : les éléments de ce menu permettent un export dans différement format de la fiche actuelle. Contenu de la fiche +++++++++++++++++++ @@ -259,8 +263,9 @@ L'épinglage d'élément est un outil de travail permettant de travailler dans u **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 dans le menu de gestion des sélections épinglées (à droite de la zone 4 sur l'image de l'interface générale). -Un élément créé ou modifié est automatiquement épinglé. +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 faites : le fait d'épingler un élément épingle automatiquement ses parents directs. @@ -269,7 +274,7 @@ Une gestion hiérarchique des épingles est faites : le fait d'épingler un élà Menu de gestion des sélections épinglées ++++++++++++++++++++++++++++++++++++++++ -Ce menu propose de sélectionner les éléments que l'on souhaite épingler. Différentes versions de ce menu sont disponible : +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 disponible : - « 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 autocompletion ; diff --git a/docs/fr/source/media-src/interface-generale.xcf b/docs/fr/source/media-src/interface-generale.xcf Binary files differindex bb585bd09..f3158a233 100644 --- a/docs/fr/source/media-src/interface-generale.xcf +++ b/docs/fr/source/media-src/interface-generale.xcf diff --git a/docs/fr/source/principes.rst b/docs/fr/source/principes.rst index 5cfd6de3f..32313f990 100644 --- a/docs/fr/source/principes.rst +++ b/docs/fr/source/principes.rst @@ -107,20 +107,20 @@ 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 ------------------------- -L'opération archéologique a été préférée au site ou l'entité archéologique comme centre des données dans Ishtar parce que les sites/entités sont 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. - -Malgré cela, 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. +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. +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 ---------------------- |
