From 4097191a4b7f91037ed06f5f07bbea7293734777 Mon Sep 17 00:00:00 2001 From: Étienne Loks Date: Tue, 4 Dec 2018 13:35:17 +0100 Subject: Doc-fr: JSON field - Custom form --- docs/fr/source/interface-administrateur.rst | 84 ++++++++++++++++++++++++++++- 1 file changed, 82 insertions(+), 2 deletions(-) (limited to 'docs') diff --git a/docs/fr/source/interface-administrateur.rst b/docs/fr/source/interface-administrateur.rst index 8e8506b6d..53a7f66a6 100644 --- a/docs/fr/source/interface-administrateur.rst +++ b/docs/fr/source/interface-administrateur.rst @@ -5,13 +5,93 @@ Interface administrateur ======================== :Auteur: Étienne Loks -:Date: 2018-10-02 +:Date: 2018-12-04 :Copyright: CC-BY 3.0 .. _configuration-instance-ishtar: Configuration de l'instance Ishtar ----------------------------------- +================================== + +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. + + +Champs personnalisés +-------------------- + +Ishtar propose un certain nombre de champ 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 reprit dans les formulaires et la fiche. + * **Type de contenu** : Le type d'objet auquel sera rattaché le champ - Opération, Site, Unité d'Enregistrement et Mobilier. + * **Clé** : Valeur de la clé dans le format JSON. Cette clé ne doit impérativement comporter que des lettres minuscules, sans accent ou un tiret bas « _ » (ne pas commencer la clé par le tiret bas et ne pas mettre plusieurs tiret 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: + +Formulaires personnalisés +------------------------- + +La plupart des formulaires peuvent être personnalisés dans Ishtar, notamment tous les formulaires des wizards 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 : enlever les champs disponibles de base dans le formulaire 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 le wizard, + * 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 : + + * champ à 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 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. + + +Profil d'instance Ishtar +------------------------ WIP -- cgit v1.2.3 From e18e0359c47fcec6e1a23a36a4d50c93b93a5f6d Mon Sep 17 00:00:00 2001 From: Étienne Loks Date: Tue, 4 Dec 2018 17:40:10 +0100 Subject: Doc-fr: permissions --- docs/fr/source/annexe-1-rattachement.rst | 23 +++++++++ docs/fr/source/annexe-2-permission-action.rst | 17 +++++++ docs/fr/source/index.rst | 2 + docs/fr/source/interface-administrateur.rst | 73 +++++++++++++++++++++++---- docs/fr/source/interface-utilisateur.rst | 3 ++ 5 files changed, 107 insertions(+), 11 deletions(-) create mode 100644 docs/fr/source/annexe-1-rattachement.rst create mode 100644 docs/fr/source/annexe-2-permission-action.rst (limited to 'docs') 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/index.rst b/docs/fr/source/index.rst index 91ef3e740..bf0ef5936 100644 --- a/docs/fr/source/index.rst +++ b/docs/fr/source/index.rst @@ -14,4 +14,6 @@ Contents: principes interface-utilisateur interface-administrateur + annexe-1-rattachement + annexe-2-permission-action installation diff --git a/docs/fr/source/interface-administrateur.rst b/docs/fr/source/interface-administrateur.rst index 53a7f66a6..36fc00a63 100644 --- a/docs/fr/source/interface-administrateur.rst +++ b/docs/fr/source/interface-administrateur.rst @@ -1,18 +1,14 @@ .. -*- coding: utf-8 -*- -======================== -Interface administrateur -======================== +================================== +Configuration de l'instance Ishtar +================================== :Auteur: Étienne Loks :Date: 2018-12-04 :Copyright: CC-BY 3.0 - -.. _configuration-instance-ishtar: - -Configuration de l'instance Ishtar -================================== +---------------------------------- 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. @@ -91,7 +87,62 @@ Une fois ce paramétrage de base enregistré, la configuration précise du formu .. 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. -Profil d'instance Ishtar ------------------------- +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éé 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é, mot de passe puis le type de profil. + +Les types de profil définiront les types de permissions auquel 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`). + +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 `. La notion de rattachement permet de spécifier finement les permissions pour des personnes qui sont directement associé à 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 `. + +.. note:: La page *Ishtar - Commun › Résumés des types de profil* permet d'accéder à un tableau qui reprend 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 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 ». + -WIP +.. + TODO: Profil d'instance Ishtar diff --git a/docs/fr/source/interface-utilisateur.rst b/docs/fr/source/interface-utilisateur.rst index ce8b5b82f..37de185d3 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 ================== -- cgit v1.2.3 From 7705e3c9a7b807ce62a24f0162e4f5af130feacd Mon Sep 17 00:00:00 2001 From: Étienne Loks Date: Tue, 4 Dec 2018 20:12:17 +0100 Subject: Docs-fr: example of workflow --- docs/fr/source/annexe-3-ex-flux-ope.rst | 90 +++++++++++++++++++++++++++++ docs/fr/source/index.rst | 3 +- docs/fr/source/interface-administrateur.rst | 18 +++--- 3 files changed, 101 insertions(+), 10 deletions(-) create mode 100644 docs/fr/source/annexe-3-ex-flux-ope.rst (limited to 'docs') 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..3a497700f --- /dev/null +++ b/docs/fr/source/annexe-3-ex-flux-ope.rst @@ -0,0 +1,90 @@ +.. -*- 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 » se décompose en 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 éventuellement 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 cette pré-sélection veut être conservée avant partage, 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 « rataché » à la structure emprunteuse par la panier en lecture seule. + +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éer les actes administratifs correspondants aux document 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. + + +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élection 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. 3O jours avant la date de retour attendue, l'alerte sera affichée. + + +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:: Les fiches mobilier ou contenant peuvent être accédés 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 bf0ef5936..a22a62ce0 100644 --- a/docs/fr/source/index.rst +++ b/docs/fr/source/index.rst @@ -14,6 +14,7 @@ Contents: principes interface-utilisateur interface-administrateur + installation annexe-1-rattachement annexe-2-permission-action - installation + annexe-3-ex-flux-ope diff --git a/docs/fr/source/interface-administrateur.rst b/docs/fr/source/interface-administrateur.rst index 36fc00a63..59e3710d5 100644 --- a/docs/fr/source/interface-administrateur.rst +++ b/docs/fr/source/interface-administrateur.rst @@ -65,13 +65,13 @@ La création se fait en deux temps, d'abord un paramétrage des champs de base p 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 : + * **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 le wizard, * nom du formulaire. - * À qui s'applique ce formulaire, cela peut être au choix : + * **À qui s'applique ce formulaire**, cela peut être au choix : * à tous les utilisateurs, * à certains utilisateurs en particulier, @@ -79,8 +79,8 @@ Le paramétrage de base demande les champs suivants : Une fois ce paramétrage de base enregistré, la configuration précise du formulaire peut se faire : - * champ à 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 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. + * **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 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. @@ -95,7 +95,7 @@ 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éé 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é, mot de passe puis le type de profil. +Ensuite on créé 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 auquel 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`). @@ -108,9 +108,9 @@ Les permissions dans Ishtar sont essentiellement gérées par « Type de profil 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é. + - **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 : -- cgit v1.2.3 From 0a1c58cfb0c70df78b5379238ec1fc36fb961edb Mon Sep 17 00:00:00 2001 From: Étienne Loks Date: Tue, 4 Dec 2018 23:38:52 +0100 Subject: Docs-fr: type lists. --- docs/fr/source/annexe-3-ex-flux-ope.rst | 6 +- docs/fr/source/interface-administrateur.rst | 100 ++++++++++++++++++---------- 2 files changed, 68 insertions(+), 38 deletions(-) (limited to 'docs') diff --git a/docs/fr/source/annexe-3-ex-flux-ope.rst b/docs/fr/source/annexe-3-ex-flux-ope.rst index 3a497700f..94aca453c 100644 --- a/docs/fr/source/annexe-3-ex-flux-ope.rst +++ b/docs/fr/source/annexe-3-ex-flux-ope.rst @@ -25,6 +25,7 @@ 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. @@ -50,7 +51,7 @@ Sélection du mobilier depuis cette pré-selection par la structure emprunteuse .. 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 « rataché » à la structure emprunteuse par la panier en lecture seule. +.. 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 « rataché » à la structure emprunteuse par la 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, ...). @@ -77,7 +78,8 @@ Départ effectif du mobilier concerné panier="Exposition Sein 2018" pret="Oui" fin-de-traitement-avant="aujourdhui+30" -3. 3O jours avant la date de retour attendue, l'alerte sera affichée. +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 diff --git a/docs/fr/source/interface-administrateur.rst b/docs/fr/source/interface-administrateur.rst index 59e3710d5..c0d2b26c7 100644 --- a/docs/fr/source/interface-administrateur.rst +++ b/docs/fr/source/interface-administrateur.rst @@ -18,6 +18,34 @@ L'interface d'administration présente la liste des différentes tables par ordr .. 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 au 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, des nombres et des tirets (-). Chaque identifiant textuel doit être unique dans la liste de type. 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. +- **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. Chaque « sous-type » renseigne ce champ avec le « sur-type » adéquat. + +Certains types disposent aussi d'autres champs spécifiques ils 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 -------------------- @@ -30,23 +58,23 @@ Ajouter un champ personnalisé se fait via l'interface d'administration au nivea Les différentes données à rentrer sont : - * **Nom** : Ce nom sera reprit dans les formulaires et la fiche. - * **Type de contenu** : Le type d'objet auquel sera rattaché le champ - Opération, Site, Unité d'Enregistrement et Mobilier. - * **Clé** : Valeur de la clé dans le format JSON. Cette clé ne doit impérativement comporter que des lettres minuscules, sans accent ou un tiret bas « _ » (ne pas commencer la clé par le tiret bas et ne pas mettre plusieurs tiret 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 : +* **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 et Mobilier. +* **Clé** : Valeur de la clé dans le format JSON. Cette clé ne doit impérativement comporter que des lettres minuscules, sans accent ou un tiret bas « _ » (ne pas commencer la clé par le tiret bas et ne pas mettre plusieurs tiret 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. + * 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. +* **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é `. @@ -66,21 +94,21 @@ La création se fait en deux temps, d'abord un paramétrage des champs de base p 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 : +* **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 le wizard, - * nom du formulaire. - * **À qui s'applique ce formulaire**, cela peut être au choix : + * type d'objet concerné (par exemple : « Mobilier »), + * éventuellement, le numéro d'ordre dans le wizard, + * nom du formulaire. +* **À qui s'applique ce formulaire**, cela peut être au choix : - * à tous les utilisateurs, - * à certains utilisateurs en particulier, - * à certains types d'utilisateurs. + * à 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 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. +* **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 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. @@ -108,28 +136,28 @@ Les permissions dans Ishtar sont essentiellement gérées par « Type de profil 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é. +- **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. +- 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. +- 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 `. La notion de rattachement permet de spécifier finement les permissions pour des personnes qui sont directement associé à 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. +- 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 `. -- cgit v1.2.3 From cfc3615cb3ceb1bcbddd09a3a1fc77d93bd17d81 Mon Sep 17 00:00:00 2001 From: Étienne Loks Date: Wed, 5 Dec 2018 10:00:35 +0100 Subject: Docs-fr: doc template --- docs/fr/source/interface-administrateur.rst | 67 +++++++++++++++++++++++++++++ 1 file changed, 67 insertions(+) (limited to 'docs') diff --git a/docs/fr/source/interface-administrateur.rst b/docs/fr/source/interface-administrateur.rst index c0d2b26c7..44cb86f29 100644 --- a/docs/fr/source/interface-administrateur.rst +++ b/docs/fr/source/interface-administrateur.rst @@ -172,5 +172,72 @@ Une fois le compte créé, les droits se spécifient dans les pages d'administra 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 +**************** + +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. + +Conditions +++++++++++ + +{% if already_paid %}YOU ALREADY PAID{% else %}YOU HAVEN'T PAID{% endif %} + + +Images +++++++ + +Secretary allows you to use placeholder images in templates that will be replaced when rendering the final document. To create a placeholder image on your template: + + Insert an image into the document as normal. This image will be replaced when rendering the final document. + Change the name of the recently added image to a Jinja2 print tag (the ones with double curly braces). The variable should call the image filter, i.e.: Suppose you have a client record (passed to template as client object), and a picture of him is stored in the picture field. To print the client's picture into a document set the image name to {{ client.picture|image }}. + + To change image name, right click under image, select "Picture..." from the popup menu and navigate to "Options" tab. + + + + + .. TODO: Profil d'instance Ishtar -- cgit v1.2.3 From 77ebf402e92bf39ff0df90d38ea3052654316755 Mon Sep 17 00:00:00 2001 From: Étienne Loks Date: Wed, 5 Dec 2018 12:58:56 +0100 Subject: Docs-fr: doc template - 2 --- docs/fr/source/interface-administrateur.rst | 26 +++++++++++++++++--------- 1 file changed, 17 insertions(+), 9 deletions(-) (limited to 'docs') diff --git a/docs/fr/source/interface-administrateur.rst b/docs/fr/source/interface-administrateur.rst index 44cb86f29..73e790441 100644 --- a/docs/fr/source/interface-administrateur.rst +++ b/docs/fr/source/interface-administrateur.rst @@ -208,6 +208,12 @@ Une fois quelques substitutions faites, on peut l'enregistrer et créer le patro Notions avancées **************** +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 +++++++++++++++++ @@ -217,23 +223,25 @@ Certaines clés peuvent parfois renvoyer à des listes d'éléments, chacun ayan {{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. +Cela se structure autour des mots clés ``for``, ``in`` et ``endfor``. Au lieu de doubles accolades, ``{%`` et ``%}`` encadrent ces mots clés. Conditions ++++++++++ -{% if already_paid %}YOU ALREADY PAID{% else %}YOU HAVEN'T PAID{% endif %} +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... -Images -++++++ +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. -Secretary allows you to use placeholder images in templates that will be replaced when rendering the final document. To create a placeholder image on your template: - - Insert an image into the document as normal. This image will be replaced when rendering the final document. - Change the name of the recently added image to a Jinja2 print tag (the ones with double curly braces). The variable should call the image filter, i.e.: Suppose you have a client record (passed to template as client object), and a picture of him is stored in the picture field. To print the client's picture into a document set the image name to {{ client.picture|image }}. +.. + Images + ++++++ - To change image name, right click under image, select "Picture..." from the popup menu and navigate to "Options" tab. + 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 -- cgit v1.2.3 From ed111729132d8c7e21d82d940e95b034a2a4f599 Mon Sep 17 00:00:00 2001 From: Étienne Loks Date: Wed, 5 Dec 2018 14:21:37 +0100 Subject: Document generation: no more specific action -> available on the sheet --- archaeological_files/ishtar_menu.py | 4 --- archaeological_finds/ishtar_menu.py | 8 ------ .../templates/ishtar/blocks/window_find_nav.html | 6 ++-- archaeological_operations/ishtar_menu.py | 5 ---- archaeological_operations/models.py | 10 +++++++ archaeological_operations/views.py | 6 ++-- docs/fr/source/interface-administrateur.rst | 24 ++++++++-------- .../templates/ishtar/blocks/window_nav.html | 32 +++++++++++++++++----- ishtar_common/templatetags/window_header.py | 7 ++++- ishtar_common/views.py | 2 ++ 10 files changed, 61 insertions(+), 43 deletions(-) (limited to 'docs') diff --git a/archaeological_files/ishtar_menu.py b/archaeological_files/ishtar_menu.py index 21e59a6af..bd41f3782 100644 --- a/archaeological_files/ishtar_menu.py +++ b/archaeological_files/ishtar_menu.py @@ -73,10 +73,6 @@ MENU_SECTIONS = [ _(u"Deletion"), model=AdministrativeAct, access_controls=['change_administrativeact']), - MenuItem('file_administrativeact_document', - _(u"Documents"), - model=AdministrativeAct, - access_controls=['change_administrativeact']), ],)]),), (100, SectionItem( diff --git a/archaeological_finds/ishtar_menu.py b/archaeological_finds/ishtar_menu.py index 48e12c79d..21a582a18 100644 --- a/archaeological_finds/ishtar_menu.py +++ b/archaeological_finds/ishtar_menu.py @@ -134,10 +134,6 @@ MENU_SECTIONS = [ _(u"Deletion"), model=AdministrativeAct, access_controls=['change_administrativeact']), - MenuItem('treatmentfle_administrativeact_document', - _(u"Documents"), - model=AdministrativeAct, - access_controls=['change_administrativeact']), ] ), ] @@ -197,10 +193,6 @@ MENU_SECTIONS = [ _(u"Deletion"), model=AdministrativeAct, access_controls=['change_administrativeact']), - MenuItem('treatment_administrativeact_document', - _(u"Documents"), - model=AdministrativeAct, - access_controls=['change_administrativeact']), ]), ] )), diff --git a/archaeological_finds/templates/ishtar/blocks/window_find_nav.html b/archaeological_finds/templates/ishtar/blocks/window_find_nav.html index 5ecaa35f0..74c6858a1 100644 --- a/archaeological_finds/templates/ishtar/blocks/window_find_nav.html +++ b/archaeological_finds/templates/ishtar/blocks/window_find_nav.html @@ -3,10 +3,12 @@ {% block post_pin %}{% if baskets %}
-
+
{% for basket_id, lbl in baskets %} diff --git a/archaeological_operations/ishtar_menu.py b/archaeological_operations/ishtar_menu.py index 4baf14295..bfc027573 100644 --- a/archaeological_operations/ishtar_menu.py +++ b/archaeological_operations/ishtar_menu.py @@ -82,11 +82,6 @@ MENU_SECTIONS = [ _(u"Deletion"), model=models.AdministrativeAct, access_controls=['change_administrativeact']), - MenuItem( - 'operation_administrativeact_document', - _(u"Documents"), - model=models.AdministrativeAct, - access_controls=['change_administrativeact']), ],), ]), ), diff --git a/archaeological_operations/models.py b/archaeological_operations/models.py index a0d0ba30b..d1a8b5875 100644 --- a/archaeological_operations/models.py +++ b/archaeological_operations/models.py @@ -1866,6 +1866,16 @@ class AdministrativeAct(BaseHistorizedItem, OwnPerms, ValueGetter): if self.treatment_file: return self.treatment_file + def get_extra_templates(self, request): + templates = [] + for template in self.act_type.associated_template.all(): + urlname = "generatedoc-administrativeactop" + templates.append( + (template.name, reverse( + urlname, args=[self.pk, template.pk])) + ) + return templates + def get_filename(self): filename = self.related_item.associated_filename filename = u"-".join(filename.split('-')[:-1]) # remove date diff --git a/archaeological_operations/views.py b/archaeological_operations/views.py index 48d7c4a4f..5ece22073 100644 --- a/archaeological_operations/views.py +++ b/archaeological_operations/views.py @@ -467,10 +467,8 @@ administrativact_register_wizard = SearchWizard.as_view([ def generatedoc_administrativeactop(request, pk, template_pk=None): - if (not request.user.has_perm( - 'ishtar_common.view_operation', models.Operation) - and not request.user.has_perm( - 'ishtar_common.view_own_operation', models.Operation)): + if not request.user.has_perm('view_administrativeact', + models.AdministrativeAct): return HttpResponse(content_type='text/plain') try: act_file = models.AdministrativeAct.objects.get(pk=pk) diff --git a/docs/fr/source/interface-administrateur.rst b/docs/fr/source/interface-administrateur.rst index 73e790441..a77ff605d 100644 --- a/docs/fr/source/interface-administrateur.rst +++ b/docs/fr/source/interface-administrateur.rst @@ -208,6 +208,18 @@ Une fois quelques substitutions faites, on peut l'enregistrer et créer le patro 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 +++++++++ @@ -225,18 +237,6 @@ Certaines clés peuvent parfois renvoyer à des listes d'éléments, chacun ayan Cela se structure autour des mots clés ``for``, ``in`` et ``endfor``. Au lieu de doubles accolades, ``{%`` et ``%}`` encadrent ces mots clés. -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. - .. Images ++++++ diff --git a/ishtar_common/templates/ishtar/blocks/window_nav.html b/ishtar_common/templates/ishtar/blocks/window_nav.html index 90d58d605..62caff142 100644 --- a/ishtar_common/templates/ishtar/blocks/window_nav.html +++ b/ishtar_common/templates/ishtar/blocks/window_nav.html @@ -57,15 +57,33 @@ {% endfor %}
+
- - ODT - - PDF - +
+ +
+ + ODT + + + PDF + {% for template_name, template_url in extra_templates %} + + {{template_name}} + {% endfor %} +
+
+ +
diff --git a/ishtar_common/templatetags/window_header.py b/ishtar_common/templatetags/window_header.py index e6325d3fb..bbd923d41 100644 --- a/ishtar_common/templatetags/window_header.py +++ b/ishtar_common/templatetags/window_header.py @@ -10,6 +10,9 @@ def window_nav(context, item, window_id, show_url, modify_url='', histo_url='', extra_actions = [] if hasattr(item, 'get_extra_actions'): extra_actions = item.get_extra_actions(context['request']) + extra_templates = [] + if hasattr(item, 'get_extra_templates'): + extra_templates = item.get_extra_templates(context['request']) slug = None if hasattr(item, "LONG_SLUG"): @@ -29,7 +32,9 @@ def window_nav(context, item, window_id, show_url, modify_url='', histo_url='', 'previous': previous, 'next': nxt, 'extra_actions': extra_actions, - 'pin_action': pin_action} + 'pin_action': pin_action, + 'extra_templates': extra_templates, + } @register.inclusion_tag('ishtar/blocks/window_find_nav.html', diff --git a/ishtar_common/views.py b/ishtar_common/views.py index bc9c9432a..f23116d21 100644 --- a/ishtar_common/views.py +++ b/ishtar_common/views.py @@ -2001,3 +2001,5 @@ class QAItemEditForm(QAItemForm): def form_save(self, form): form.save(self.items, self.request.user) return HttpResponseRedirect(reverse("success")) + + -- cgit v1.2.3 From 94350f454d52e249fd8f181b4cf52046cc58575e Mon Sep 17 00:00:00 2001 From: Étienne Loks Date: Wed, 5 Dec 2018 14:42:15 +0100 Subject: Docs-fr: fixes --- docs/fr/source/annexe-3-ex-flux-ope.rst | 16 +++++++-------- docs/fr/source/interface-administrateur.rst | 32 ++++++++++++++--------------- 2 files changed, 24 insertions(+), 24 deletions(-) (limited to 'docs') diff --git a/docs/fr/source/annexe-3-ex-flux-ope.rst b/docs/fr/source/annexe-3-ex-flux-ope.rst index 94aca453c..462b961c1 100644 --- a/docs/fr/source/annexe-3-ex-flux-ope.rst +++ b/docs/fr/source/annexe-3-ex-flux-ope.rst @@ -13,7 +13,7 @@ Annexe 3 - Exemple de flux opérationnel : prêt pour exposition Description =========== -Le flux opérationnel « Prêt pour exposition » se décompose en différentes étapes : +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 ; @@ -37,7 +37,7 @@ 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 éventuellement quelques éléments à ce panier via l'action rapide « Panier » ou *Mobilier › Panier › Gestion des éléments*. +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. @@ -46,12 +46,12 @@ 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 ----------------------------------------------------------------------------- -1. Si cette pré-sélection veut être conservée avant partage, 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 ». +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 « rataché » à la structure emprunteuse par la 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. +.. 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, ...). @@ -62,9 +62,9 @@ Sélection du mobilier depuis cette pré-selection par la structure emprunteuse 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éer les actes administratifs correspondants aux document administratifs attendus, via l'icône « + acte admin. » de la fiche de demande de traitement ou via *Demande de traitement › Acte administratif › Ajout*. +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. +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é @@ -72,7 +72,7 @@ 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élection 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. +.. 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 : :: @@ -87,6 +87,6 @@ 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:: Les fiches mobilier ou contenant peuvent être accédés via le QR-code. +.. 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/interface-administrateur.rst b/docs/fr/source/interface-administrateur.rst index a77ff605d..32aac1045 100644 --- a/docs/fr/source/interface-administrateur.rst +++ b/docs/fr/source/interface-administrateur.rst @@ -28,21 +28,21 @@ Dans les pages d'administration, les listes de types se retrouvent sous les dén - **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 au traitements ; +- **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, des nombres et des tirets (-). Chaque identifiant textuel doit être unique dans la liste de type. 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. +- **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. +- **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. Chaque « sous-type » renseigne ce champ avec le « sur-type » adéquat. +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 ils sont explicites ou disposent d'une aide en ligne. +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 ». @@ -50,7 +50,7 @@ Certains types disposent aussi d'autres champs spécifiques ils sont explicites Champs personnalisés -------------------- -Ishtar propose un certain nombre de champ 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. +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é. @@ -59,8 +59,8 @@ Ajouter un champ personnalisé se fait via l'interface d'administration au nivea 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 et Mobilier. -* **Clé** : Valeur de la clé dans le format JSON. Cette clé ne doit impérativement comporter que des lettres minuscules, sans accent ou un tiret bas « _ » (ne pas commencer la clé par le tiret bas et ne pas mettre plusieurs tiret 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 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, @@ -83,9 +83,9 @@ Sauf si un champ personnalisé est uniquement destiné à des données importée Formulaires personnalisés ------------------------- -La plupart des formulaires peuvent être personnalisés dans Ishtar, notamment tous les formulaires des wizards ainsi que les formulaires de recherche. À ce jour, il n'est pas encore possible d'ajouter de nouveaux formulaires. +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 : enlever les champs disponibles de base dans le formulaire et ajouter des champs JSON dans le formulaire. Chaque formulaire personnalisé peut être mis à disposition pour tous ou seulement certains utilisateurs. +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*. @@ -97,7 +97,7 @@ Le paramétrage de base demande les champs suivants : * **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 le wizard, + * éventuellement, le numéro d'ordre dans les formulaires successifs, * nom du formulaire. * **À qui s'applique ce formulaire**, cela peut être au choix : @@ -108,7 +108,7 @@ Le paramétrage de base demande les champs suivants : 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 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. +* **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. @@ -125,7 +125,7 @@ Dans Ishtar, un compte doit être associé à une personne. Si la personne n'exi Ensuite on créé 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 auquel 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`). +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`). Cette interface de création de compte permet aussi de modifier le mot de passe de comptes existants. @@ -151,7 +151,7 @@ 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 `. La notion de rattachement permet de spécifier finement les permissions pour des personnes qui sont directement associé à 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. +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 `. 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 : @@ -161,12 +161,12 @@ En pratique, globalement, les groupes de droits permettent d'accéder à certain 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 `. -.. note:: La page *Ishtar - Commun › Résumés des types de profil* permet d'accéder à un tableau qui reprend toutes les permissions associées aux types de profil. +.. 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 utilisé par Ishtar. +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 ». -- cgit v1.2.3 From 78b28667790ef4d880d2cfe33db471729d1fc245 Mon Sep 17 00:00:00 2001 From: Valérie-Emma Leroux Date: Mon, 10 Dec 2018 12:47:31 +0100 Subject: Documentation update --- docs/fr/source/interface-administrateur.rst | 2 +- docs/fr/source/principes.rst | 8 ++++---- 2 files changed, 5 insertions(+), 5 deletions(-) (limited to 'docs') diff --git a/docs/fr/source/interface-administrateur.rst b/docs/fr/source/interface-administrateur.rst index 32aac1045..651111826 100644 --- a/docs/fr/source/interface-administrateur.rst +++ b/docs/fr/source/interface-administrateur.rst @@ -123,7 +123,7 @@ 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éé 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. +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`). 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 ---------------------- -- cgit v1.2.3 From 352d19db5a946471319e9f722e99167261b69ff5 Mon Sep 17 00:00:00 2001 From: Étienne Loks Date: Tue, 11 Dec 2018 19:00:58 +0100 Subject: Update doc --- docs/fr/source/_static/interface-generale.png | Bin 89216 -> 89012 bytes docs/fr/source/interface-utilisateur.rst | 12 +++++++----- docs/fr/source/media-src/interface-generale.xcf | Bin 278527 -> 276491 bytes 3 files changed, 7 insertions(+), 5 deletions(-) (limited to 'docs') diff --git a/docs/fr/source/_static/interface-generale.png b/docs/fr/source/_static/interface-generale.png index f9c9bac22..fb054a075 100644 Binary files a/docs/fr/source/_static/interface-generale.png and b/docs/fr/source/_static/interface-generale.png differ diff --git a/docs/fr/source/interface-utilisateur.rst b/docs/fr/source/interface-utilisateur.rst index 37de185d3..a7ab19a8c 100644 --- a/docs/fr/source/interface-utilisateur.rst +++ b/docs/fr/source/interface-utilisateur.rst @@ -58,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 `), mise en place par l'utilisateur ainsi que les éléments actuellement épinglés (cf. :ref:`Utilisation avancée > Éléments épinglés `). +Cette zone reprend les éventuelles alertes (cf. :ref:`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. :ref:`Utilisation avancée > Éléments épinglés `). .. _page-de-recherche: @@ -76,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). @@ -182,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 `). - 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 +++++++++++++++++++ @@ -262,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. @@ -272,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 index bb585bd09..f3158a233 100644 Binary files a/docs/fr/source/media-src/interface-generale.xcf and b/docs/fr/source/media-src/interface-generale.xcf differ -- cgit v1.2.3