Quick Start

Dynacase Platform 3.2

Anakeen Labs <labs@anakeen.com>

Table des matières

Chapitre 1 Introduction

1.1 Présentation et objectif

Ce document est le tutoriel de la plateforme Dynacase.

Il contient un projet fictif mettant en œuvre les principales fonctionnalités de la plateforme.

Une fois le tutoriel complété, vous saurez :

Anakeen propose des prestations de formation à l'utilisation de la plateforme Dynacase.
Ces formations, d'une durée de 5 jours en standard, permettent d'aborder les points de ce tutoriel.
Elles peuvent aussi être adaptées pour aborder des thèmes non présentés dans ce document. Elles alternent parties théoriques et applications pratiques. Les parties pratiques s'appuient sur un projet standard ou peuvent être basées sur votre propre projet.
Elles se déroulent en inter entreprise sur Paris ou Toulouse ou en intra sur votre site.

1.2 Organisation

Ce tutoriel est organisé en 5 chapitres principaux :

Il permet d'avoir une vue d'ensemble des fonctionnalités de Dynacase.

Chaque chapitre est composé de sous chapitres. Un sous chapitre est écrit pour pouvoir être parcouru et compris en 2 heures.

L'annexe résume quelques points clefs.

1.4 Contexte Fonctionnel

Vous êtes nouvellement embauché au sein du service informatique de la société COGIP.

Dans le cadre de son activité la COGIP a mis en place une démarche qualité.
Cette démarche consiste en l'expertise annuelle de ses différents sites de production par une équipe d'auditeurs internes dans le but de vérifier que les processus qualité sont bien appliqués.

L'année précédente la COGIP a connu une très forte croissance qui a abouti à l'ouverture de 42 nouvelles usines de production en complément des 48 existantes.
La mise en place et le suivi des audits qualité est devenu une tâche plus importante et plus complexe que précédemment. L'équipe du service qualité est arrivée au constat que l'espace partagé contenant quelques tableaux Excel et l'envoi de mail ne permettent plus de suivre efficacement le déroulement des audits. Le responsable du service qualité a donc demandé à la DSI de mettre en place rapidement une solution permettant de planifier et de suivre le déroulement de la phase d'audit.

Suite à une phase d'analyse menée conjointement par la DSI et le service qualité, plusieurs éléments sont apparus :

La DSI a donc comparé quelques outils existants sur le marché et a décidé d'utiliser Dynacase pour développer en interne la logique métier propre au service qualité.

Votre responsable hiérarchique vous a donc confié ce développement. Vous avez 1 mois pour réaliser et mettre en production l'outil.

Chapitre 2 Préparation de l'environnement

Pour la suite du tutoriel nous allons utiliser deux environnements distincts :

Ce chapitre aborde la mise en place de ces environnements.

2.1 Mise en place de l'environnement d'exécution

Ce chapitre va vous permettre de mettre en place la machine hébergeant Dynacase et initialiser le contexte d'exécution.

2.1.1 Objectifs

2.1.2 Partie théorique

Dynacase utilise un outil d'installation et de gestion de contexte dédié dénommé Dynacase Control. Cet outil utilise les notions suivantes :

NB : Par défaut, Anakeen fournit un dépôt contenant les modules open source de Dynacase.

2.1.3 Mise en place de l'environnement

La plateforme Dynacase fonctionne dans un environnement Linux et a pour principales dépendances PHP et Postgresql.

Ce tutoriel n'a pas vocation à détailler toute la procédure de mise en place des dépendances et d'installation de Dynacase Control, pour ce faire nous vous proposons deux solutions :

2.1.4 Installation du contexte

Une fois votre machine prête à être utilisée, vous allez paramétrer votre contexte Dynacase recevant votre application.

Pour ce faire, vous devez utiliser un navigateur pour aller sur Dynacase Control, l'url d'accès est : http://<nomDeDomaine>/dynacase-control/.

Si vous utilisez la machine virtuelle mise à votre disposition, l'url est rappelée lors de l'invite de connexion.

Le login est admin et le mot de passe dynacase.

Vous arrivez sur la page ci-dessous :

Control

Figure 2. Control

Cette page présente les grandes fonctionnalités de control, sur la droite vous retrouvez :

Vous allez créer un nouveau contexte utilisant le dépôt open source, pour cela il vous faut cliquer sur Create Context.

Create context

Figure 3. Create context

Il vous faut saisir les données suivantes :

Create context

Figure 4. Create context

Cliquez ensuite sur Create, l'interface suivante doit s'ouvrir :

Create context

Figure 5. Create context

Cette interface présente les différents modules installés (section "Installed") sur un contexte et permet d'en installer de nouveaux (section "Available").

Il est nécessaire d'installer le module dynacase-core : ce paquet représente le cœur de Dynacase platform. Il contient la gestion documentaire, le moteur de cycle de vie et la gestion applicative.

Create context

Figure 6. Create context

Et ensuite cliquez sur Install Selection, le système résout les dépendances et vous propose la liste des paquets qu'il va installer. Pour poursuivre l'installation, cliquer sur ok.

Le système télécharge ensuite les paquets et commence l'installation. Il vous pose une question sur les paramètres de Dynacase Core.

Create context

Figure 7. Create context

Veuillez saisir comme client name : COGIP.

Si vous avez installé vous même votre machine, vous devez aussi renseigner le service de base données. Vous devez ensuite cliquer sur OK

L'installeur vous propose ensuite de valider les licences et les emplacements des dépendances.

Félicitations ! Vous avez installé votre contexte.

2.1.5 Conclusion

Vous allez maintenant pouvoir vous connecter à votre contexte. Pour ce faire, rendez vous sur l'URL correspondant à votre contexte, dans la machine virtuelle celle-ci correspond à la racine de la machine http://<nomDeDomaine>/dynacase/.

Vous arrivez sur cette page de login :

Login

Figure 8. Login

Les identifiants par défaut sont : admin / anakeen

Une fois identifié, vous arrivez sur l'interface suivante :

Contexte vide

Figure 9. Contexte vide

Il n'y a pour l'instant que l'application par défaut de recherche et l'application une famille.

Vous pouvez aussi consulter l'interface d'administration en cliquant sur la roue à côté du bouton de déconnexion.

Administration

Figure 10. Administration

2.2 Mise en place de l'environnement de développement

Ce chapitre va vous permettre d'initialiser le module contenant le code source de votre application Dynacase.

2.2.1 Objectifs

2.2.2 Partie théorique

Comme nous l'avons vu au chapitre précédent, Dynacase Control utilise le concept de module pour gérer les différents éléments constituants un contexte.

Un module est composé de :

Dynacase Control utilise des modules au format webinst. Ce format permet de transporter le module sous la forme d'un seul fichier. Ce fichier, nommé paquet, est composé de la manière suivante :

Une fois le module fourni à Dynacase Control, celui-ci lit le fichier info.xml, décompresse le contenu du content.tar.gz dans le contexte et exécute les éventuelles instructions d'installation ou mise à jour.

2.2.3 Mise en place

Il vous faut tout d'abord télécharger le developer toolkit, cet outil vous permet :

L'installation du toolkit et de ses dépendances est décrite dans la documentation correspondante

Le developer toolkit est téléchargeable depuis notre site :

L'exécution des devtools diffère si vous êtes sous un système Linux ou Windows :

L'initialisation du module se fait au moyen de la commande :

<devtool> createModule

L'invite vous proposer les choix suivants :

You need to set the name of the application -n or --name
You need to set the output path for the file -o or --output
Usage: /usr/local/bin/devtool [options] [operands]
Options:
  -o, --output <arg>      output Path (needed)
  -n, --name <arg>        name of the module (needed)
  -a, --application <arg> associated application (list of app name separeted by ,)
  -l, --lang <arg>        list of locale (list of locale separeted by ,) default (fr,en)
  -x, --external          with external file
  -s, --style             with style directory
  -p, --api               with api directory
  -i, --images            with images directory
  -e, --enclosure [<arg>] enclosure of the CSV generated (default : " )
  -d, --delimiter <arg>   delimiter of the CSV generated (default : ; )
  -h, --help              show the usage message

Cette commande va initialiser pour vous une structure de module Dynacase type, pré-paramétrée.

Dans notre cas, vous rentrez les options suivantes :

<devtool> createModule  -o . -n cogip-audit -a COGIP_AUDIT -xspi -e

Cela crée, dans le répertoire courant, la structure de fichiers suivante :

┊
├─ API/
├─ COGIP_AUDIT
│  ├─ COGIP_AUDIT.app
│  ├─ COGIP_AUDIT_init.php
│  ├─ Images/
│  └─ Layout/
├─ EXTERNALS/
├─ STYLE/
├─ locale/
├─ Images/
├─ build.json
├─ info.xml
┊

La structure générée contient les éléments suivants :

Ouvrez le fichier COGIP_AUDIT/COGIP_AUDIT.app

$app_desc = array(
    "name" => "COGIP_AUDIT",
    "short_name" => N_("COGIP_AUDIT:COGIP_AUDIT"),
    "description" => N_("COGIP_AUDIT:COGIP_AUDIT"),
    "icon" => "COGIP_AUDIT.png",
    "displayable" => "N",
    "childof" => ""
);

Nous voyons que par défaut une référence est ajoutée vers un fichier COGIP_AUDIT.png ce fichier est à déposer dans le répertoire Images à la racine du module. Cette image est utilisée pour représenter l'application dans les différentes interfaces Dynacase -menus, administration, etc-.

Toutes les chaînes de caractères qui sont inclues dans les fonction _ et N_ sont traduisibles, ce qui est ici le cas pour short_name et description.

Vous pouvez ajouter l'image au répertoire, toutes les images du tutoriel peuvent-être trouvées ici.

2.2.4 Traduction

Vous allez lancer la procédure permettant l'extraction des clefs de traduction et compléter celles-ci.

Une première version des fichiers de traductions a été initialisée lors de la création du module.

La commande pour rafraîchir les po est :

<devtool> extractPo -s .

Le -s indique le path où se trouve les sources, dans l'exemple ci-dessus elles sont dans le path courant.

Les po sont dans la structure suivante.

┊
├─┬─ locale
┊ ├─ en
  │  └─ LC_MESSAGES
  │     └─ src
  │        └─ COGIP_AUDIT_en.po
  └─ fr
      └─ LC_MESSAGES
         └─ src
            └─ COGIP_AUDIT_fr.po

Ces fichiers sont les dictionnaires de traductions et ils contiennent les clefs que nous avons identifiées ci-dessus ainsi que leurs traductions.

Il est créé les fichiers PO suivants :

Le fichier COGIP_AUDIT_fr.po contient :

# French translations for PACKAGE package.
# Copyright (C) 2014 THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# Automatically generated, 2014.
#
msgid ""
msgstr ""
"Project-Id-Version: COGIP_AUDIT_fr\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2014-09-22 12:08+0200\n"
"PO-Revision-Date: 2014-09-22 11:44+0200\n"
"Last-Translator: Automatically generated\n"
"Language-Team: none\n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"
 
msgid "COGIP_AUDIT:COGIP_AUDIT"
msgstr ""

Vous allez compléter la clef Cogip_audit, ceci peut-être fait à l'aide votre IDE ou d'un logiciel spécialisé tel que poedit (téléchargement).

Complétez avec Application d'audit de la cogip.

Ce qui donne :

[...]
msgid "COGIP_AUDIT:COGIP_AUDIT"
msgstr "Application d'audit de la cogip"

Une fois les modifications faites, vous obtenez le fichier suivant :

# French translations for PACKAGE package.
# Copyright (C) 2014 THE PACKAGE'S COPYRIGHT HOLDER
# This file is distributed under the same license as the PACKAGE package.
# Automatically generated, 2014.
#
msgid ""
msgstr ""
"Project-Id-Version: COGIP_AUDIT_fr\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2014-09-22 12:08+0200\n"
"PO-Revision-Date: 2014-09-22 11:44+0200\n"
"Last-Translator: Automatically generated\n"
"Language-Team: none\n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"
 
msgid "COGIP_AUDIT:COGIP_AUDIT"
msgstr "Application d'audit de la cogip"

2.2.5 Production du paquet

Vous allez maintenant conclure ce chapitre en produisant le fichier contenant le paquet et en le déployant à l'aide de l'interface web.

Exécutez la commande :

<devtool> generateWebinst -s .

Un paquet cogip-audit-1.0.0-0.webinst est alors produit dans le répertoire des sources.

Vous devez ensuite accéder à Dynacase control pour le déployer.

Deploy webinst

Figure 11. Deploy webinst

Veuillez cliquer sur le bouton Import Module et à l'aide du sélecteur de fichier sélectionnez le paquet cogip-audit-1.0.0-0.webinst.

L'installeur vous demande le scénario que vous souhaitez utiliser.

Deploy webinst

Figure 12. Deploy webinst

Le module n'ayant pas encore été installé, veuillez cliquer sur Install.

Dynacase control vous indique les différentes actions qu'il va exécuter.

Deploy webinst

Figure 13. Deploy webinst

Veuillez valider, l’installation se déroule et votre application est en place.

Vous pouvez ensuite vérifier que celle-ci est bien installée et que la traduction est en place. Pour cela, allez sur http://<nomDeDomaine>/dynacase/admin.php dans la catégorie Gestion des applications, Les applications.

Show application

Figure 14. Show application

Vous pouvez retrouver votre application dans la liste. En outre, la traduction que nous avons faite apparaît dans la colonne description.

2.2.6 Déploiement automatisé de paquet

Chaque fois que vous souhaiterez déployer vos développements sur le serveur de production, il faudra, comme indiqué ci-dessus :

Afin de simplifier cette succession d'étapes, les devtool fournissent la commande deploy.

Il faut préciser tous les paramètres de déploiement :

soit :

<devtool> deploy -s . --url http://admin:anakeen@<nomDeDomaine>/dynacase-control/ --port <port> --context dynacase

2.2.7 Conclusion

Vous connaissez maintenant la structure des sources Dynacase, vous savez construire et déployer un module et avez abordé les principes des traductions.

2.2.8 Voir aussi

Chapitre 3 Gestion des dépendances

Dans les chapitres suivants, vous allez utiliser des fonctionnalités fournies par d'autres modules.

Afin de s'assurer que ces fonctionnalités sont disponibles, on va exprimer des dépendances entre les modules.

Lors de l'installation ou de la mise à jour d'un module, ses dépendances sont également installées.

Si au moins l'une des dépendances ne peut pas être satisfaite, alors l'installation ou la mise à jour ne peuvent être effectuées.

3.1 Ajout d'une dépendance

Les dépendances s'expriment dans le fichier info.xml au moyen de la section requires. Chaque dépendance est exprimée sous la forme d'une balise module.

Dans les chapitres suivants, plusieurs fonctionnalités seront utilisées. Afin que les modules correspondants soient installés, dans le fichier info.xml, remplacer la section requires par :

<requires>
    <module comp="ge" name="dynacase-core" version="3.2"/>
    <module name="dynacase-onefam" comp="ge" version="3.2"/>
    <module name="dynacase-admin-uis" comp="ge" version="1.0"/>
    <module name="dynacase-app-switcher" comp="ge" version="1.0"/>
</requires>

Le fichier xml complété peut-être consulté ici.

Cela exprime les dépendances suivantes :

3.2 Mise en place des modifications

Vous allez maintenant déployer vos modifications :

<devtool> deploy -s . --url http://admin:anakeen@<nomDeDomaine>/dynacase-control/ --port <port> --context dynacase

En vous rendant sur dynacase-control (http://<nomDeDomaine>/dynacase-control/), vous pouvez constater que les modules exprimés en dépendance ont été installés.

Chapitre 4 La gestion des utilisateurs

Dans Dynacase, la gestion des utilisateurs utilise la notion de compte (account dans la documentation de référence). Les comptes se répartissent en trois catégories :

Les utilisateurs
ce type de compte identifie une personne et permet à celle-ci de se connecter sur la plateforme.
Les groupes

un groupe est un ensemble d'utilisateurs.

  • Il peut contenir d'autres groupes
  • Il peut être contenu dans d'autres groupes,
  • La liste des utilisateurs d'un groupe est de deux natures :
    • les utilisateurs directement contenus dans le groupe,
    • les utilisateurs contenus dans le groupe et ses sous groupes.
les rôles

un rôle a pour but de faire le lien entre les utilisateurs et les droits :

  • les droits sont posés sur les rôles
  • les rôles sont ensuite affectés directement aux utilisateurs, ou par l'intermédiaire des groupes.

Il est à noter que dans le cas de projets intégrés au sein d'un système d'information, Dynacase peut utiliser un LDAP/AD comme base de référence pour les utilisateurs et un SSO comme système d'authentification des utilisateurs. Ce point n'est pas abordé dans ce tutoriel.

Dans ce chapitre, vous allez apprendre à créer, initialiser et associer les différents comptes utilisateurs.

4.1 Initialisation des comptes

4.1.1 Objectifs

4.1.2 Cadre

Lors de la phase de spécification, les éléments suivants ont été identifiés. L'application nécessite :

De plus, une bonne pratique est de faire le lien entre les utilisateurs et les rôles au travers des groupes. Nous allons donc également créer les groupes suivants :

Enfin, l'application doit être initialisée avec les utilisateurs suivants :

Les arborescences de rôles, groupes et utilisateurs définis sont les suivants :

Nous avons choisi de respecter les bonnes pratiques et de ne donner aucun rôle directement à un utilisateur. Ainsi, les rôles des utilisateurs sont obtenus par leurs groupes d'appartenance (directs et indirects). L'administrateur n'a donc pas à se demander de quels droits dispose un nouvel utilisateur, il suffit de mettre l'utilisateur dans le(s) groupe(s) métier qui lui correspondent.

4.1.3 Interface de gestion des utilisateurs

Pour initialiser les différents types de comptes, vous pouvez utiliser l'interface web. Veuillez vous rendre sur l'interface d'administration : http://<nomDeDomaine>/dynacase/admin.php, puis cliquer sur Gestion des utilisateurs.

Création d'utilisateur

Figure 15. Création d'utilisateur

Cette interface permet de créer des utilisateurs, des groupes et des rôles.

Vous pouvez replier la partie gauche de l'interface en cliquant sur le bouton tout en haut à gauche.

4.1.4 Initialisation des comptes

Vous allez dans un premier temps créer un rôle, un groupe, puis un utilisateur depuis l'interface. la création se fera dans cet ordre car :

Dans un second temps, les documents ainsi créés seront exportés.

Enfin, vous utiliserez les formats d'import et d'export pour créer les autres rôles, groupes et utilisateurs.

Tous les éléments nécessaires au paramétrage de l'application doivent être importés pour permettre les installations et mises à jour de l'application dans divers environnements (développement, pré-production, production).

4.1.4.1 Initialisation du premier rôle

Pour créer un rôle, veuillez vous rendre dans l'interface de gestion des utilisateurs, puis cliquer sur tous les rôles.

Rôle : liste des rôles

Figure 16. Rôle : liste des rôles

Appuyez ensuite sur Créer un rôle, un formulaire est affiché. Vous devez compléter le champ obligatoire :

Appuyez ensuite sur le bouton Créer.

Le rôle nouvellement créé s'affiche :

Rôle : Création

Figure 17. Rôle : Création

4.1.4.2 Initialisation du premier groupe

Pour créer un groupe, veuillez vous rendre dans l'interface de gestion des utilisateurs, puis cliquer sur tous les groupes.

Groupe : liste des groupes

Figure 18. Groupe : liste des groupes

Appuyez ensuite sur Créer un groupe d'utilisateur, un formulaire est affiché. Vous devez compléter les deux champs obligatoires :

Appuyez ensuite sur le bouton Créer.

Le groupe nouvellement créé s'affiche :

Groupe : Création

Figure 19. Groupe : Création

Vous allez maintenant indiquer que ce groupe est un sous-groupe du groupe Utilisateurs. Pour cela, utilisez le menu Modifier la hiérarchie et cliquez sur Utilisateurs dans la nouvelle fenêtre :

Groupe : Modification de la hiérarchie

Figure 20. Groupe : Modification de la hiérarchie

Puis cliquez sur le menu sauver.

4.1.4.3 Initialisation du premier utilisateur

Pour créer un utilisateur, veuillez cliquer sur le bouton Créer un utilisateur, l'interface de création apparaît :

Utilisateur : création

Figure 21. Utilisateur : création

Veuillez compléter le formulaire en fournissant les nom, prénom, login, mail et mot de passe de l'utilisateur :

Ensuite cliquez sur le bouton Créer.

Votre utilisateur est ajouté et est affiché.

Utilisateur : création

Figure 22. Utilisateur : création

Les utilisateurs ont quelques spécificités, vous pouvez :

Vous allez maintenant indiquer que l'utilisateur est membre du groupe Utilisateurs COGIP. Pour cela, utilisez le menu Gestion du compte> Changer de groupes et cliquez sur Utilisateurs dans la nouvelle fenêtre pour le désélectionner, puis cliquez sur Utilisateurs COGIP pour le sélectionner :

Utilisateur : Modification de la hiérarchie

Figure 23. Utilisateur : Modification de la hiérarchie

Utilisateurs est en bleu, alors que Utilisateurs COGIP est en vert. Cela signifie que l'utilisateur est membre direct du groupe Utilisateurs COGIP, alors qu'il est membre indirect du groupe Utilisateurs (en effet, il est membre d'un de ses sous-groupes).

Puis cliquez sur le menu sauver.

4.1.4.4 Export des comptes

Vous allez maintenant exporter les comptes créés. Veuillez fermer la fiche utilisateur, et utiliser les filtres dans la grille pour ne voir que cet utilisateur dans la liste.

Utilisateur : export

Figure 24. Utilisateur : export

Cliquez ensuite sur le bouton Exporter les utilisateurs. La fenêtre suivante s'ouvre :

Utilisateur : export

Figure 25. Utilisateur : export

Cette fenêtre affiche les options d'export, ainsi que la liste des groupes qui seront exportés (dans notre cas, il est indiqué Sélection : Tous les groupes, Identifiant : cogip, ce qui correspond à notre filtrage).

Choisissez les options suivantes :

Puis cliquez sur exporter les comptes.

Vous obtenez un fichier zip contenant :

4.1.5 Ajout des nouveaux comptes dans le fichier d'import

4.1.5.1 Format d'import / export

Le format du xml est défini dans le manuel de référence.

4.1.5.2 Ajout des instructions d'import

Il vous reste à ajouter l'instruction d'import du fichier dans le fichier info.xml.

Ce fichier déclare les actions réalisées lors de l'installation ou la mise à jour du paquet. Vous allez donc ajouter la ligne suivante pour demander l'import des utilisateurs :

<process command='./wsh.php --api=importAccounts --file=COGIP_AUDIT/accounts.xml'/>

Le fichier xml complété peut-être consulté ici.

4.1.5.3 Ajout des autres comptes

4.1.5.3.1 Paramétrage de la xsd

En ouvrant le fichier COGIP_AUDIT/accounts.xml, vous pouvez constater qu'il référence le schéma accounts.xsd (xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="XSD/accounts.xsd"). Toutefois, puisque nous avons déposé le répertoire XSD à la racine du contexte, nous pouvons redéfinir son emplacement en remplaçant la ligne précédente par

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../XSD/accounts.xsd"

cette étape n'est pas obligatoire. Toutefois, si votre IDE supporte les xsd, le xml sera validé au fur et à mesure de sa complétion, et l'IDE pourra même vous proposer de l'auto-completion.

4.1.5.3.2 renommage du rôle

Vous remarquez que le rôle qui a été créé via l'interface contient une référence aléatoire. Étant donné que la référence sera utilisée dans le profilage, vous allez remplacer cette référence. Toutefois, la référence servant de clé d'identification du rôle, l'import d'un rôle avec le même libellé (displayName), mais une référence différente ne fera pas une mise à jour, mais va créer un nouveau rôle. il faut donc :

4.1.5.3.3 Ajout des rôles

Dans la section <roles/>, nous allons ajouter les 2 rôles manquants :

Le bloc <roles></roles> a donc le contenu suivant :

<roles>
  <role id="13">
    <reference>role_utilisateurs_cogip</reference>
    <displayName>Utilisateur COGIP</displayName>
    <document family="ROLE">
      <role title="Utilisateur COGIP" revision="0" modification-date="2016-04-20T13:42:00" version="" state=""/>
    </document>
  </role>
  <role>
    <reference>role_responsable_audit</reference>
    <displayName>Responsable des audits</displayName>
    <document family="ROLE">
      <role title="Responsable des audits"/>
    </document>
  </role>
  <role>
    <reference>role_auditeur</reference>
    <displayName>Auditeur</displayName>
    <document family="ROLE">
      <role title="Auditeur"/>
    </document>
  </role>
  <role>
    <reference>role_admin_fonc</reference>
    <displayName>Administrateur fonctionnel</displayName>
    <document family="ROLE">
      <role title="Administrateur fonctionnel"/>
    </document>
  </role>
</roles>

4.1.5.3.4 Ajout des groupes

Dans la section <groups/>, nous allons ajouter les 3 groupes manquants :

Le bloc <groups></groups> a donc le contenu suivant :

<groups>
  <group id="2">
    <reference>all</reference>
    <displayName>Utilisateurs</displayName>
    <document family="IGROUP">
      <igroup name="GDEFAULT" title="Utilisateurs" revision="0" modification-date="2016-04-20T14:09:04" version="" state=""/>
    </document>
  </group>
  <group id="12">
    <reference>grp_user_cogip</reference>
    <displayName>Utilisateurs COGIP</displayName>
    <associatedRoles reset="false">
      <associatedRole reference="role_utilisateurs_cogip"/>
    </associatedRoles>
    <parentGroups reset="false">
      <parentGroup reference="all"/>
    </parentGroups>
    <document family="IGROUP">
      <igroup title="Utilisateurs COGIP" revision="0" modification-date="2016-04-20T14:40:10" version="" state=""/>
    </document>
  </group>
  <group>
    <reference>grp_dsi</reference>
    <displayName>DSI</displayName>
    <associatedRoles reset="false">
    </associatedRoles>
    <parentGroups reset="false">
      <parentGroup reference="grp_user_cogip"/>
    </parentGroups>
    <document family="IGROUP">
      <igroup title="DSI"/>
    </document>
  </group>
  <group>
    <reference>grp_auditeurs</reference>
    <displayName>Auditeurs</displayName>
    <associatedRoles reset="false">
      <associatedRole reference="role_auditeur"/>
    </associatedRoles>
    <parentGroups reset="false">
      <parentGroup reference="grp_user_cogip"/>
    </parentGroups>
    <document family="IGROUP">
      <igroup title="Auditeurs"/>
    </document>
  </group>
  <group>
    <reference>grp_admin_fonc</reference>
    <displayName>Administrateurs fonctionnels</displayName>
    <associatedRoles reset="false">
      <associatedRole reference="role_admin_fonc"/>
    </associatedRoles>
    <parentGroups reset="false">
      <parentGroup reference="grp_user_cogip"/>
    </parentGroups>
    <document family="IGROUP">
      <igroup title="Administrateurs Fonctionnels"/>
    </document>
  </group>
  <group>
    <reference>grp_responsable_audit</reference>
    <displayName>Responsables des audits</displayName>
    <associatedRoles reset="false">
      <associatedRole reference="role_responsable_audit"/>
    </associatedRoles>
    <parentGroups reset="false">
      <parentGroup reference="grp_auditeurs"/>
    </parentGroups>
    <document family="IGROUP">
      <igroup title="Responsables des audits"/>
    </document>
  </group>
  <group>
    <reference>grp_section_risque_operationnel_qualite</reference>
    <displayName>Section Risque Opérationnel et Qualité</displayName>
    <associatedRoles reset="false">
    </associatedRoles>
    <parentGroups reset="false">
      <parentGroup reference="grp_auditeurs"/>
    </parentGroups>
    <document family="IGROUP">
      <igroup title="Section Risque Opérationnel et Qualité"/>
    </document>
  </group>
</groups>

4.1.5.3.5 Ajout des utilisateurs

Dans la section <users/>, nous allons ajouter les utilisateurs manquants :

Le bloc <users></users> a donc le contenu suivant :

<users>
  <user id="11">
    <login>martin.jean</login>
    <firstname>Jean</firstname>
    <lastname>Martin</lastname>
    <mail>martin.jean@quickstartcogip.com</mail>
    <status activated="true"/>
    <password crypted="true">$5$W5l3wgIyC3wKO6ML$Vl875jOLPfxZO8iM/Pvfc/NvV2CjoqGSfOPNUXBUM6B</password>
    <parentGroups reset="false">
      <parentGroup reference="grp_section_risque_operationnel_qualite"/>
    </parentGroups>
    <document family="IUSER">
      <iuser title="Martin Jean" revision="0" modification-date="2016-04-20T14:40:10" version="" state=""/>
    </document>
  </user>
  <user>
    <login>arthaud.priscilla</login>
    <firstname>Priscilla</firstname>
    <lastname>Arthaud</lastname>
    <mail>arthaud.priscilla@quickstartcogip.com</mail>
    <status activated="true"/>
    <password crypted="true">$5$W5l3wgIyC3wKO6ML$Vl875jOLPfxZO8iM/Pvfc/NvV2CjoqGSfOPNUXBUM6B</password>
    <parentGroups reset="false">
      <parentGroup reference="grp_section_risque_operationnel_qualite"/>
    </parentGroups>
    <document family="IUSER">
      <iuser title="Arthaud Priscilla"/>
    </document>
  </user>
  <user>
    <login>luc.arnaud</login>
    <firstname>Arnaud</firstname>
    <lastname>Luc</lastname>
    <mail>luc.arnaud@quickstartcogip.com</mail>
    <status activated="true"/>
    <password crypted="true">$5$W5l3wgIyC3wKO6ML$Vl875jOLPfxZO8iM/Pvfc/NvV2CjoqGSfOPNUXBUM6B</password>
    <parentGroups reset="false">
      <parentGroup reference="grp_section_risque_operationnel_qualite"/>
    </parentGroups>
    <document family="IUSER">
      <iuser title="Luc Arnaud"/>
    </document>
  </user>
  <user>
    <login>marthe.karine</login>
    <firstname>Karine</firstname>
    <lastname>Marthe</lastname>
    <mail>marthe.karine@quickstartcogip.com</mail>
    <status activated="true"/>
    <password crypted="true">$5$W5l3wgIyC3wKO6ML$Vl875jOLPfxZO8iM/Pvfc/NvV2CjoqGSfOPNUXBUM6B</password>
    <parentGroups reset="false">
      <parentGroup reference="grp_section_risque_operationnel_qualite"/>
      <parentGroup reference="grp_responsable_audit"/>
      <parentGroup reference="grp_admin_fonc"/>
    </parentGroups>
    <document family="IUSER">
      <iuser title="Marthe Karine"/>
    </document>
  </user>
  <user>
    <login>arnic.marina</login>
    <firstname>Marina</firstname>
    <lastname>Arnic</lastname>
    <mail>arnic.marina@quickstartcogip.com</mail>
    <status activated="true"/>
    <password crypted="true">$5$W5l3wgIyC3wKO6ML$Vl875jOLPfxZO8iM/Pvfc/NvV2CjoqGSfOPNUXBUM6B</password>
    <parentGroups reset="false">
      <parentGroup reference="grp_dsi"/>
      <parentGroup reference="grp_admin_fonc"/>
    </parentGroups>
    <document family="IUSER">
      <iuser title="Arnic Marina"/>
    </document>
  </user>
</users>

et de changer le groupe parent de Jean Martin par grp_section_risque_operationnel_qualite

4.1.6 Mise en place des modifications

Vous allez maintenant déployer vos modifications :

<devtool> deploy -s . --url http://admin:anakeen@<nomDeDomaine>/dynacase-control/ --port <port> --context dynacase

Vous pouvez maintenant vous rendre dans la gestion des utilisateurs :

Importation : résultat

Figure 26. Importation : résultat

Vous pouvez voir que les groupes ont été ajoutés, l'arborescence respectée et les différents rôles associés.

Le recalcul de l'arborescence des groupes et des droits est asynchrone, il peut y avoir un décalage de quelques minutes entre l'installation du paquet et la visualisation des données sur le contexte.

4.1.7 Conclusion

Dans ce chapitre, vous avez parcouru l'ensemble des techniques pour créer, associer et importer les différents éléments nécessaires à la gestion des comptes Dynacase.

Ces éléments vous serviront dans toutes les autres phases de vos projets pour fixer les droits, définir des vues particulières, etc.

4.1.8 Pour aller plus loin

Vous pouvez consulter les chapitres suivants de la documentation :

Chapitre 5 Familles et documents

Les notions de famille et, celle associée, de document sont fondamentales dans Dynacase.

Les familles et les documents sont le système utilisé par Dynacase pour produire des formulaire intuitifs et une solution de persistance évolutives.

Dans ce chapitre, vous allez apprendre à créer vos familles, mettre en forme les documents produits, gérer la sécurité, traduire les formulaire, etc.

5.1 Théorie

La construction d'une famille est réalisée par la mise en place :

de la structure
elle est définie par ses attributs propres et éventuellement par les attributs de la famille dont elle hérite,
du paramétrage
le paramétrage de la famille consiste à ajouter des éléments de représentation (titre, icône, etc.), son contenu (valeur par défaut, etc.) et le code métier associé,
de la sécurité
la sécurité permet de définir qui peut faire les différentes étapes du CRUD (Create : Créer, Read : Voir, Update : Mettre à jour, Delete : Supprimer), ainsi que quelle représentation est utilisée pour quel utilisateur,
des vues
les différentes représentations du document sont définies.

Une famille peut produire des documents. Un document est une instance d'une famille (de la même manière qu'un objet est une instance d'une classe). Dans Dynacase, le document est matérialisé par :

5.1.1 Voir aussi

5.2 Mise en place des structures

Ce chapitre va vous permettre d'initialiser vos premières familles.

5.2.1 Objectifs

5.2.2 Cadre

L'analyse des besoins a montré que votre application nécessite les familles suivantes :

Référentiel qualité

elle représente un référentiel qualité et contient :

  • la désignation d'un référentiel qualité.
Chapitre de référentiel

elle représente un chapitre et contient :

  • un lien à un référentiel,
  • un titre.
Audit

elle représente un audit et contient :

  • le titre de l'audit,
  • sa date de début,
  • sa durée en jours,
  • sa date de fin,
  • le site audité,
  • un champ descriptif,
  • le responsable de l'audit,
  • la liste des auditeurs,
  • une liste de référentiels,
  • une liste de points forts, avec pour chacun :
    • un encart de texte,
  • une liste de points faibles, avec pour chacun :
    • un encart de texte,
  • une liste de fiches de non-conformité,
  • une liste de fichiers associés.
Fiche de non-conformité

elle représente une non-conformité et contient :

  • le titre de la non-conformité,
  • un lien vers la fiche d'audit,
  • un rédacteur,
  • une liste de liens vers des chapitres de référentiel, avec pour chacun :
    • un lien vers le référentiel,
    • un lien vers le chapitre,
    • un texte explicitant le manquement,
  • une liste d'actions, avec pour chacune :
    • un descriptif,
    • un responsable,
    • une date de prise en compte.

5.2.3 Partie théorique

5.2.3.1 Structure de famille

La structure d'une famille est définie par deux éléments :

le fichier de structure
il contient la liste des attributs (type de données) que les documents de la famille contiennent,
l'héritage
si une famille hérite d'une autre, elle hérite de manière dynamique de tous les éléments de ses familles parentes.

La structure de la famille est utilisée en interne par Dynacase pour :

5.2.4 Création de votre première famille : Famille de base

À la liste des familles identifiées de manière fonctionnelle, nous allons ajouter une famille dite de base, dont toutes les familles de l'application hériteront. Cette méthode est une bonne pratique pour débuter un projet Dynacase. Ceci permet de propager plus facilement des comportements spécifiques entre toutes les familles d'un projet.

Par exemple, si vous souhaitez empêcher la duplication de tous les documents au sein de votre projet, vous pouvez le spécifier au niveau de la famille mère et le comportement est transmis à toutes les familles filles.
De même, comme nous le verrons plus tard, cela permet de mettre en place une vue commune à toutes ces familles.

Ouvrez une console et rendez vous dans le répertoire de votre application et lancez la commande suivante :

<devtool> createFamily -s . -n COGIP_AUDIT_BASE -m COGIP -a COGIP_AUDIT

La commande createFamily permet de créer des familles Dynacase. La liste de ses options est accessibles avec l'option --help.

Les options utilisées ci dessus sont :

Les fichiers suivants sont générés :

├ COGIP_AUDIT
  ├─ COGIP_AUDIT_BASE__CLASS.php
  ├─ COGIP_AUDIT_BASE__PARAM.csv
  └─ COGIP_AUDIT_BASE__STRUCT.csv

Les fichiers ci-dessus sont pré-remplis et prêts à être utilisés. Leur nomenclature est explicitée dans l'annexe.

Vous devez maintenant indiquer dans le fichier info.xml que cette famille doit être importée lors de l'initialisation et la mise à jour. Vous allez ajouter les lignes suivantes :

<process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COPGIP_AUDIT_BASE__STRUCT.csv --csv-separator=&apos;;&apos; '/>
<process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COPGIP_AUDIT_BASE__PARAM.csv --csv-separator=&apos;;&apos; '/>

Ces deux lignes vous sont retournées par la commande de création des fichiers.

à 2 endroits :

Vous devez avoir un fichier info.xml semblable à :

<post-install>
    <process command="programs/record_application COGIP_AUDIT" />
    <process command='./wsh.php --api=importDocuments  --file=./COGIP_AUDIT/ROLE__INIT_DATA.csv --csv-separator=&apos;;&apos;'/>
    <process command='./wsh.php --api=importDocuments  --file=./COGIP_AUDIT/IGROUP__INIT_DATA.csv --csv-separator=&apos;;&apos;'/>
    <process command='./wsh.php --api=importDocuments  --file=./COGIP_AUDIT/IUSER__INIT_DATA.csv --csv-separator=&apos;;&apos;'/>
    <process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COPGIP_AUDIT_BASE__STRUCT.csv --csv-separator=&apos;;&apos; '/>
    <process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COPGIP_AUDIT_BASE__PARAM.csv --csv-separator=&apos;;&apos;'/>
    <process command="programs/update_catalog" />
</post-install>
 
<post-upgrade>
    <process command="programs/pre_migration COGIP_AUDIT" />
    <process command="programs/record_application COGIP_AUDIT" />
    <process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COPGIP_AUDIT_BASE__STRUCT.csv --csv-separator=&apos;;&apos; '/>
    <process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COPGIP_AUDIT_BASE__PARAM.csv --csv-separator=&apos;;&apos;'/>
    <process command="programs/post_migration COGIP_AUDIT" />
    <process command="programs/update_catalog" />
</post-upgrade>

5.2.5 Création des fichiers de familles

Vous allez maintenant créer les autres familles, reprenez la ligne de commande ci-dessus pour chacune des familles présentées ci-dessous.

Vous avez créé l'ensemble des fichiers qui vont définir vos familles.

Il faut maintenant les référencer dans le fichier info.xml. Pour ce faire, vous devez respecter l'ordre de l'héritage et importer les familles mères puis les familles filles. Si vous ne suivez pas un ordre adéquat, l'installeur refusera d'installer le paquet et vous indiquera le problème.

Votre info.xml contient les lignes suivantes :

<post-install>
    <process command="programs/record_application COGIP_AUDIT"/>
    <process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/ROLE__INIT_DATA.csv --csv-separator=&apos;;&apos;'/>
    <process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/IGROUP__INIT_DATA.csv --csv-separator=&apos;;&apos;'/>
    <process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/IUSER__INIT_DATA.csv --csv-separator=&apos;;&apos;'/>
    <process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_BASE__STRUCT.csv --csv-separator=&apos;;&apos; '/>
    <process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_BASE__PARAM.csv --csv-separator=&apos;;&apos;'/>
    <process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_REFERENTIEL__STRUCT.csv --csv-separator=&apos;;&apos; '/>
    <process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_REFERENTIEL__PARAM.csv --csv-separator=&apos;;&apos; '/>
    <process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_CHAPITRE__STRUCT.csv --csv-separator=&apos;;&apos; '/>
    <process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_CHAPITRE__PARAM.csv --csv-separator=&apos;;&apos; '/>
    <process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_AUDIT__STRUCT.csv --csv-separator=&apos;;&apos; '/>
    <process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_AUDIT__PARAM.csv --csv-separator=&apos;;&apos; '/>
    <process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_FNC__STRUCT.csv --csv-separator=&apos;;&apos; '/>
    <process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_FNC__PARAM.csv --csv-separator=&apos;;&apos; '/>
    <process command="programs/update_catalog"/>
</post-install>
<post-upgrade>
    <process command="programs/pre_migration COGIP_AUDIT"/>
    <process command="programs/record_application COGIP_AUDIT"/>
    <process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_BASE__STRUCT.csv --csv-separator=&apos;;&apos; '/>
    <process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_BASE__PARAM.csv --csv-separator=&apos;;&apos;'/>
    <process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_REFERENTIEL__STRUCT.csv --csv-separator=&apos;;&apos; '/>
    <process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_REFERENTIEL__PARAM.csv --csv-separator=&apos;;&apos; '/>
    <process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_CHAPITRE__STRUCT.csv --csv-separator=&apos;;&apos; '/>
    <process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_CHAPITRE__PARAM.csv --csv-separator=&apos;;&apos; '/>
    <process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_AUDIT__STRUCT.csv --csv-separator=&apos;;&apos; '/>
    <process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_AUDIT__PARAM.csv --csv-separator=&apos;;&apos; '/>
    <process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_FNC__STRUCT.csv --csv-separator=&apos;;&apos; '/>
    <process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_FNC__PARAM.csv --csv-separator=&apos;;&apos; '/>
    <process command="programs/post_migration COGIP_AUDIT"/>
    <process command="programs/update_catalog"/>
</post-upgrade>

Vous pouvez retrouver l'ensemble de ces fichiers initialisés dans les sources du chapitre complété.

5.2.6 Ajout des attributs

Vous allez maintenant définir les attributs contenus dans vos familles.

5.2.6.1 Référentiel qualité

Vous allez commencer par la famille Référentiel qualité. Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_REFERENTIEL__STRUCT.csv.

Le fichier se présente sous cette forme :

Contenu structure site

Figure 27. Contenu structure site

Dans cette capture d'écran, vous remarquez que le fichier est coloré. Vous pouvez obtenir ce comportement (ainsi que d'autres aides) en suivant l'annexe. Dans la suite du tutoriel, ces scripts sont considérés comme installés.

Attention : un attribut non-structurant (texte, relation, numérique, …) doit obligatoirement être contenu dans un attribut structurant frame ou array.

Pour définir un attribut, vous devez saisir :

  1. dans la colonne A : le mot clef ATTR ;
  2. dans la colonne B : l'identifiant unique de l'attribut, celui-ci est alphanumérique et écrit de préférence en minuscules ;
  3. dans la colonne C : l'attribut encadrant de l'attribut en cours (cet élément est nécessaire pour les attributs non-structurants, c'est à dire les attributs qui contiennent des données, text, int, etc.) ;
  4. dans la colonne D : la valeur de traduction par défaut du label de l'attribut,
  5. dans la colonne E : Y ou N selon que l'attribut est utilisé pour composer le titre ou non
  6. dans la colonne G : le type de l'attribut,
  7. dans la colonne H : l'ordre d'affichage des attributs. Cet élément est utile dans le cas d'héritage entre famille, il permet de dire dans quel ordre doivent être affichés les attributs ;
  8. dans la colonne I : la visibilité par défaut de l'attribut.

Dans le cas des Référentiel qualité, vous devez obtenir une structure similaire à :

Contenu structure référentiel

Figure 28. Contenu structure référentiel

Quelques astuces pour faciliter l'écriture des familles :

Vous pouvez voir ci-dessous un exemple de construction sur la famille chapitre.

Exemple de construction

Figure 29. Exemple de construction

Vous pouvez retrouver le fichier complété dans les sources.

5.2.6.2 Chapitre

Vous allez maintenant compléter la famille chapitre. Cette famille contient un lien vers son référentiel, de manière a pouvoir retrouver facilement tous les chapitres d'un référentiel.

Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_CHAPITRE__STRUCT.csv, et complétez-le pour obtenir une structure similaire à :

Contenu structure Chapitre

Figure 30. Contenu structure Chapitre

Vous pouvez remarquer la présence d'un nouveau type d'attribut docid. Ce type d'attribut référence un document et permet de créer des liens entre les fiches. Il est présenté :

Dans la définition du docid, la référence à la famille Référentiel indique la nature du lien, et permet de n'afficher en édition que les documents issus de cette famille.

Vous pouvez retrouver le fichier complété dans les sources.

5.2.6.3 Fiche de non-conformité

Vous allez maintenant compléter la Fiche de non-conformité.

Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_FNC__STRUCT.csv, et complétez le pour obtenir une structure similaire à :

Contenu structure FNC

Figure 31. Contenu structure FNC

Vous pouvez remarquer la présence de deux nouveaux éléments structurants :

Vous pouvez retrouver le fichier complété dans les sources.

5.2.6.4 Audit

Vous allez maintenant compléter votre dernière famille, la Fiche d'audit.

Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_AUDIT__STRUCT.csv, et complétez le pour obtenir une structure similaire à :

Contenu structure Audit

Figure 32. Contenu structure Audit

Attention : Dans la spécification, il est indiqué que l'audit porte plusieurs référentiels. Vous devez donc ajouter dans la colonnes options (P), l'option multiple=yes.

Vous pouvez retrouver le fichier complété dans les sources.

Bravo ! Vous avez initialisé l'ensemble des familles.

5.2.7 Génération des stubs

Vous allez maintenant produire les stubs. Ce sont des fichiers PHP qui sont générés pour aider au développement de l'application.

Si vous ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_AUDIT__CLASS.php, vous avez le contenu suivant :

namespace Cogip;
use \Dcp\AttributeIdentifiers\COGIP_AUDIT_AUDIT as MyAttributes;
 
Class COGIP_AUDIT_AUDIT extends \Dcp\Family\COGIP_AUDIT_BASE
{
}

Les deux classes référencées dans ce fichier n'existent pas encore : elles sont générées automatiquement sur le serveur lors de l'importation des familles.

Vous pouvez générer des classes de référence, les stubs, qui permettent d'utiliser la complétion sur votre IDE. Ces classes ne contiennent que les éléments qui vous seront utiles lors du développement et ne sont pas tout à fait semblables à celles générées sur le serveur.

Ouvrez une console et rendez vous dans le répertoire de votre application et lancez la commande suivante :

<devtool> generateStub -s . -o ./stubs/

L'outil a généré les stubs dans le nouveau sous-répertoire stubs dans le répertoire de vos sources :

├ stubs
  ├─ cogip_audit_audit__STUB.php
  ├─ cogip_audit_base__STUB.php
  ├─ cogip_audit_chapitre__STUB.php
  ├─ cogip_audit_fnc__STUB.php
  └─ cogip_audit_referentiel__STUB.php

Les fichiers stubs contiennent :

Vous pouvez retrouver les stubs sur github.

Exemple de complétion d'attribut à l'aide des stubs :

Complétion d'attribut

Figure 33. Complétion d'attribut

5.2.8 Internationalisation

Vous allez maintenant extraire les clefs permettant de traduire vos familles.

Ouvrez une console et rendez vous dans le répertoire de votre application et lancez la commande suivante :

<devtool> extractPo -s .

Des nouveaux fichiers de po sont ajoutés, il en existe un par famille et par langue.

./locale
├── en
│   └── LC_MESSAGES
│       └── src
│           ├── COGIP_AUDIT_AUDIT_en.po
│           ├── COGIP_AUDIT_BASE_en.po
│           ├── COGIP_AUDIT_CHAPITRE_en.po
│           ├── COGIP_AUDIT_en.po
│           ├── COGIP_AUDIT_FNC_en.po
│           └── COGIP_AUDIT_REFERENTIEL_en.po
└── fr
    └── LC_MESSAGES
        └── src
            ├── COGIP_AUDIT_AUDIT_fr.po
            ├── COGIP_AUDIT_BASE_fr.po
            ├── COGIP_AUDIT_CHAPITRE_fr.po
            ├── COGIP_AUDIT_FNC_fr.po
            ├── COGIP_AUDIT_fr.po
            └── COGIP_AUDIT_REFERENTIEL_fr.po

Chacun de ces fichiers contient l'ensemble des clefs permettant de traduire les labels des attributs et des énumérés de la famille qu'il référence.

Pour chaque attribut est généré le bloc suivant :

#: COGIP_AUDIT/COGIP_AUDIT_AUDIT__STRUCT.csv
#, fuzzy
msgid "COGIP_AUDIT_AUDIT#caa_titre"
msgstr "Titre"

La traduction présente est celle que vous avez notée dans le fichier CSV.
La notation fuzzy indique que la traduction est une proposition pour aider le traducteur.

#: COGIP_AUDIT/COGIP_AUDIT_AUDIT__STRUCT.csv
msgid "COGIP_AUDIT_AUDIT#caa_titre"
msgstr "Titre"

Pour le fichier fr, vous pouvez enlever les fuzzy car les propositions sont correctes, par contre il vous faudra traduire fichier en.

5.2.9 Mise en place des modifications

Vous allez maintenant déployer vos modifications :

<devtool> deploy -s . --url http://admin:anakeen@<nomDeDomaine>/dynacase-control/ --port <port> --context dynacase

vous n'avez plus besoin de préciser les paramètres de déploiement car ils ont été automatiquement mémorisés pour la target quickstart lors du déploiement du chapitre précédent. N'hésitez pas à consulter les instruction de déploiement pour plus d'explications.

Le script de déploiement choisit automatiquement le scénario upgrade car vous avez fait l'initialisation dans le chapitre précédent. L'initialisation apporte l'import des comptes (utilisateurs, groupes, rôles), or ceux-ci sont déjà importés, il est donc inutile (et coûteux en temps) de le faire à nouveau.

Vos familles sont installées sur le contexte, vous allez pouvoir consulter vos premiers formulaires.

5.2.10 Consultation des familles

Vous pouvez consulter les familles en utilisant l'interface open source de consultation par défaut OneFam.
Cette interface est un exemple d'interface possible de consultation/création de documents. Elle est simple à configurer et permet d'accéder à la création de rapport et de recherche.

Pour accéder à cette interface, connectez vous sur le contexte.

Vous arrivez sur l'interface suivante :

AppSwitcher

Figure 34. AppSwitcher

Utilisez le menu en haut à gauche et sélectionnez l'application Une famille. Vous arrivez sur l'interface suivante :

Onefam

Figure 35. Onefam

Les deux boutons + vous permettent de choisir les familles présentées :

Cliquez sur le deuxième bouton et vous obtenez l'interface suivante :

Choisissez vos familles

Figure 36. Choisissez vos familles

Veuillez sélectionner la famille COGIP_AUDIT.

Choisissez vos familles

Figure 37. Choisissez vos familles

Cliquez sur valider et confirmez.

Vous obtenez l'interface suivante :

Onefam

Figure 38. Onefam

Pour l'instant toutes les familles sont semblables car vous n'avez pas configuré les icônes, vous pouvez les identifier en survolant l'icône.

Vous pouvez créer quelques formulaires en utilisant l'interface.

  1. Cliquez sur une des icônes,
  2. Cliquez sur création > ...nom de la famille....
Onefam

Figure 39. Onefam

5.2.11 Conclusion

Vous savez maintenant créer des familles, paramétrer la structure et les traduire.

Dans les autres tutoriaux de ce chapitre vous allez apprendre à les paramétrer, en paramétrer la sécurité, en modifier les interfaces.

5.2.12 Voir aussi

5.3 Paramétrage

Dans ce chapitre, vous allez paramétrer les familles que vous avez créées dans le chapitre précédent, "Mise en place des structures".

5.3.1 Objectifs

5.3.2 Cadre

Lors de la phase de spécification, les éléments suivants ont été identifiés. Votre application nécessite les comportements suivants :

5.3.3 Théorie et fichiers mis en œuvre

Le paramétrage des familles de Dynacase comprend tout ce qui est lié à la personnalisation du fonctionnement des familles. Les différents éléments paramétrables sont :

Il vous est rappelé qu'à chaque modification de votre paquet, vous devez reconstruire celui-ci et le déployer pour voir les modifications s'appliquer sur votre environnement d'exécution (VM). De plus :

Les annexes contiennent un chapitre développement rapide qui résume quelques techniques permettant d'accélérer le développement en évitant de déployer à chaque modification.

5.3.4 Propriétés des familles

Commencez par les propriétés des familles.

Une famille peut contenir un certain nombre de propriétés, elles sont décrites dans la documentation.

Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_REFERENTIEL__PARAM.csv, celui-ci contient les lignes suivantes :

Paramètre de la famille référentiel

Figure 40. Paramètre de la famille référentiel

Deux paramètres ont été remplis par le developper tool :

5.3.4.1 Icône

L'image de l’icône doit être ajoutée dans le répertoire Images à la racine du contexte. Vous devez donc créer dans vos sources un répertoire Images et ajouter une image.

Vous obtenez la structure de fichiers suivantes :

├ Images
├── cogip_audit_audit.png
├── cogip_audit_base.png
├── cogip_audit_chapitre.png
├── cogip_audit_fnc.png
├── COGIP_AUDIT.png
└── cogip_audit_referentiel.png

Vous pouvez retrouver l'ensemble des images de l'application sur github.

Famille avec icônes

Figure 41. Famille avec icônes

5.3.4.2 Titre de famille

Le titre de la famille se paramètre via les traductions. Ouvrez le fichier locale/fr/LC_MESSAGES/src/COGIP_AUDIT_AUDIT.po et modifiez le bloc suivant :

msgid "COGIP_AUDIT_AUDIT#title"
msgstr ""

en

msgid "COGIP_AUDIT_AUDIT#title"
msgstr "Audit"

Complétez les différents fichiers .po avec les traductions suivantes :

Famille avec titre

Figure 42. Famille avec titre

Attention si jamais votre bloc de traduction porte la mention fuzzy, cette mention doit être supprimée pour que la traduction soit prise en compte.

Vous pouvez retrouver les po complétés sur github.

5.3.4.3 Valeur par défaut

Dans les fiches de non-conformité, le rédacteur est le créateur de la fiche.

Pour obtenir ce comportement, vous allez utiliser la notion de valeur par défaut.

La valeur par défaut est donnée par une méthode de la classe associée à famille. Cette méthode est appelée lors de la création d'un document et retourne une valeur qui complète la valeur d'un attribut.

Pour indiquer la valeur par défaut, ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_FNC__PARAM.csv et ajoutez une ligne juste avant le END avec pour les colonnes les valeurs :

Ce qui donne :

Valeur par défaut

Figure 43. Valeur par défaut

Vous pouvez retrouver le fichier complété dans les sources.

De plus, cette valeur n'étant pas modifiable par les utilisateurs, vous allez modifier la visibilité par défaut de l'attribut correspondant pour le rendre non modifiable.

Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_FNC__STRUCT.csv et modifiez la ligne correspondant à l'attribut caf_redacteur pour mettre S dans la colonne I. Cela indique que l'attribut est statique et donc non modifiable :

Attribut en S

Figure 44. Attribut en S

Vous pouvez retrouver le fichier complété dans les sources.

5.3.5 Attribut obligatoire

Votre spécification indique que certains attributs sont obligatoires.

Pour indiquer qu'un attribut est obligatoire, sa définition est modifiée dans le fichier __STRUCT.csv.

Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_REFERENTIEL__STRUCT.csv et modifiez la colonne J sur la ligne de l'attribut car_titre en y ajoutant la lettre Y. Le fichier doit être similaire à :

Attribut obligatoire

Figure 45. Attribut obligatoire

Une fois le fichier importé, le formulaire en édition indique que l'attribut est obligatoire (passage en gras du label). L'enregistrement n'est pas permis sans mettre une valeur dans cet attribut.

Complétez ensuite les autres familles :

Vous pouvez retrouver les familles complétées dans les sources.

5.3.6 Calcul des titres des documents

Il existe deux moyens de spécifier les règles de calcul de titre d'un document :

5.3.6.1 Composition du titre par paramétrage de la structure

Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_REFERENTIEL__STRUCT.csv et modifiez le pour qu'il soit similaire à :

Attribut titre

Figure 46. Attribut titre

Ce qui donne après la création du document :

Document avec le calcul du titre

Figure 47. Document avec le calcul du titre

Vous pouvez retrouver le fichier complété dans les sources.

5.3.6.2 Composition du titre en utilisant getCustomTitle

Pour les autres familles, vous ne pouvez pas utiliser la même méthode car soit le titre contient un lien vers un attribut, soit il est composé avec des éléments qui ne sont pas directement dans le document.

Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_CHAPITRE__CLASS.php et surchargez la méthode getCustomTitle :

/**
 * Compute the title of the chapter family
 *
 * @return string
 */
public function getCustomTitle() {
    //Get the attr cac_titre value
    $title = $this->getAttributeValue(MyAttributes::cac_titre);
    //Get the title of the referenced referentiel
    $chapterTitle = $this->getTitle($this->getAttributeValue(MyAttributes::cac_ref));
    // Compose the title
    return sprintf("%s : %s", $chapterTitle, $title);
}

Ce qui donne après la création du document :

Document avec le calcul du titre

Figure 48. Document avec le calcul du titre

Vous pouvez retrouver le fichier complété dans les sources.

Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_FNC__CLASS.php et surchargez la méthode getCustomTitle :

/**
 * Compute the title of the FNC family
 *
 * @return string
 */
public function getCustomTitle()
{
    //Get the attr caf_titre value
    $title = $this->getAttributeValue(MyAttributes::caf_titre);
    //Get the title of the referenced audit
    $chapterTitle = $this->getTitle($this->getAttributeValue(MyAttributes::caf_audit));
    // Compose the title
    return sprintf("%s : %s", $chapterTitle, $title);
}

Vous pouvez retrouver le fichier complété dans les sources.

5.3.6.3 Paramètre de famille

Vous allez maintenant construire le titre pour la famille audit. Ce titre est composé de deux parties :

Vous allez ajouter un paramètre à la famille audit. Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_AUDIT__PARAM.csv et modifiez le pour qu'il soit similaire à :

Paramètre de famille

Figure 49. Paramètre de famille

Les paramètres de familles se définissent de la même manière que les attributs (voir la documentation d'importation).

À la prochaine importation, le paramètre sera associé à cette famille. Sa valeur est modifiable dans les interfaces d'administration sans nouveau déploiement des sources.

Vous pouvez retrouver les sources complétées dans les sources.

5.3.6.4 Composition du titre avec un paramètre de famille

Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_AUDIT__CLASS.php et surchargez la méthode getCustomTitle :

/**
 * Compute the title of the audit family
 *
 * @return string
 */
public function getCustomTitle()
{
    //Get the attr cac_titre value
    $title = $this->getAttributeValue(MyAttributes::caa_titre);
    //Get the prefix
    $prefixe = $this->getFamilyParameterValue("caa_p_title_prefix");
    // Compose the title
    return sprintf("%s_%s", $prefixe, $title);
}

Ce qui donne, après déploiement :

Titre : famille audit

Figure 50. Titre : famille audit

Bravo ! Vous avez mis en place le calcul des titres des documents.

5.3.7 Mise en place des contraintes

Vous allez maintenant paramétrer la contrainte nécessaire à votre projet.

Une contrainte permet de vérifier qu'une condition est valide lors de l'enregistrement d'un document.

Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_AUDIT__CLASS.php et veuillez ajouter la fonction suivante :

/**
 * Check if the date is inferior to today
 * 
 * @param string $date iso date
 * @return string|null
 */
public function checkBeginningDate($date) {
    if (!empty($date) && $date <= date("c")) {
        return _("coa:The date must be after today");
    }
    return null;
}

Quelques remarques sur la fonction ci-dessus :

Pensez à relancer l'extraction des traductions et à traduire la chaîne dans le fichier .po de l'application (COGIP_AUDIT_fr.po).

Vous pouvez retrouver la contrainte complétée dans les sources.

Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_AUDIT__STRUCT.csv et modifiez la colonne O de la ligne de l'attribut caa_date_debut pour y ajouter la référence à la fonction définie ci-dessus. Vous devez obtenir une ligne similaire à :

Définition contrainte : Structure

Figure 51. Définition contrainte : Structure

La cellule contient :

Une fois le module déployé, le formulaire possède une nouvelle fonctionnalité, qui s'affiche de cette manière :

Définition contrainte : résultat

Figure 52. Définition contrainte : résultat

Vous pouvez retrouver la contrainte complétée dans les sources.

Les contraintes permettent aussi de suggérer des valeurs. Si vous souhaitez implémenter ce comportement, veuillez consulter la documentation.

Pour l'instant cette contrainte est très limitante, en effet elle s’exécute à chaque sauvegarde du document. Donc :

  1. vous créez l'audit le 12 juin pour un audit commençant le 15 juin et durant 5 jours,
  2. vous le modifiez le 16 juin la contrainte vous indique que la date de début est dépassée et vous empêche de sauvegarder.

Vous verrez dans le chapitre sur les cycles de vie différents moyens d'améliorer cette contrainte.

5.3.8 Configuration des aides à la saisie

Vous allez maintenant configurer une aide à la saisie.
La spécification indique que dans une fiche de non-conformité les référentiels accessibles sont ceux référencés par l'audit associé à la fiche.

Une aide à la saisie est dans un fichier autonome car elle peut-être utilisée au sein de plusieurs famille différentes.

5.3.8.1 Fonction

Ajoutez un fichier helper_audit.php dans le répertoire EXTERNALS et ajoutez dans celui-ci la fonction selectReferentiel comme ci-dessous :

<?php
 
function selectReferentiel($caf_audit, $userInput = "") {
 
    $return = array();
    // Get the audit doc with the id
    $audit = new_Doc("", $caf_audit, true);
    if (!$audit->isAlive()) {
        return _("coa:You need to select an audit before");
    }
    // Get the referentiel doc
    $auditReferentiel = $audit->getAttributeValue(\Dcp\AttributeIdentifiers\COGIP_AUDIT_AUDIT::caa_ref);
 
    if (is_array($auditReferentiel)) {
        $auditReferentiel = implode(",", $auditReferentiel);
    }
 
    // Search the associated referentiel
    $searchDoc = new \SearchDoc("", "COGIP_AUDIT_REFERENTIEL");
    $searchDoc->setObjectReturn();
    /* @var $auditReferentiel \COGIP\COGIP_AUDIT_AUDIT */
    //Add a filter to select only the referentiel in the audit
    $searchDoc->addFilter("id in (%s)", $auditReferentiel);
    //Add a filter on the title that take the userInput
    if (!empty($userInput)) {
        $searchDoc->addFilter("title ~* '%s'", preg_quote($userInput));
    }
 
    $htmlUserInput = htmlentities($userInput);
    foreach($searchDoc->getDocumentList() as $currentRef) {
        /* @var $currentRef \COGIP\COGIP_AUDIT_AUDIT */
        $enhancedTitle = $currentRef->getHTMLTitle();
        if (!empty($userInput)) {
            //Enhance the title to emphasize the userInput
            $enhancedTitle = str_replace($userInput, "<strong>$htmlUserInput</strong>", $currentRef->getHTMLTitle());
        }
        //Set the return value
        $return[] = array(
            $enhancedTitle,
            $currentRef->getPropertyValue("initid"),
            $currentRef->getTitle()
        );
    }
 
    return $return;
 }

Cette fonction permet de sélectionner uniquement les référentiels cités dans l'audit associé à la fiche de non-conformité. Vous pouvez remarquer les points suivants :

id et initid : dans l'aide à la saisie la propriété renvoyée est l'initid du document. Tout document possède plusieurs moyens d'être identifié :

Vous pouvez retrouver les aides à la saisie complétées dans les sources.

5.3.8.2 Paramétrage

Vous allez maintenant référencer cette aide à la saisie dans la famille. Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_FNC__STRUCT.csv et ajoutez dans les colonnes L et M les valeurs suivantes :

Aide à la saisie : struct

Figure 53. Aide à la saisie : struct

Vous remarquez qu'il y a un décalage d'une valeur entre le nombre de retour de la fonction d'aide à la saisie (3 éléments par valeur possible) et la définition de l'aide à la saisie (2 éléments uniquement).
En effet, le premier élément du retour de l'aide à la saisie est utilisé pour construire la liste de suggestion présentée à l'utilisateur.

Vous pouvez retrouver le paramétrage complété dans les sources.

5.3.8.3 Résultat

Aide à la saisie : résultat

Figure 54. Aide à la saisie : résultat

5.3.8.4 Exemple

Ci-dessous, un autre exemple d'aide à la saisie. Il concerne toujours les Fiche de non-conformité, les chapitres présentés doivent être ceux du référentiels en cours.

La fonction suivante est à ajouter dans helper_audit.php :

function selectChapter($caf_referentiel, $userInput = "")
{
    if (empty($caf_referentiel)) {
        return _("coa:You need to select a referentiel");
    }
 
    $return = array();
 
    // Search the associated referentiel
    $searchDoc = new \SearchDoc("", "COGIP_AUDIT_CHAPITRE");
    $searchDoc->setObjectReturn();
    /* @var $auditReferentiel \COGIP\COGIP_AUDIT_CHAPITRE */
    //Add a filter to select only the referentiel in the audit
    $searchDoc->addFilter("cac_ref = '%s'", $caf_referentiel);
    //Add a filter on the title that take the userInput
    if (!empty($userInput)) {
        $searchDoc->addFilter("title ~* '%s'", preg_quote($userInput));
    }
 
    $htmlUserInput = htmlentities($userInput);
    foreach ($searchDoc->getDocumentList() as $currentRef) {
        /* @var $currentRef \COGIP\COGIP_AUDIT_CHAPITRE */
        $enhancedTitle = $currentRef->getHTMLTitle();
        if (!empty($userInput)) {
            //Enhance the title to emphasize the userInput
            $enhancedTitle = str_replace($userInput, "<strong>$htmlUserInput</strong>", $currentRef->getHTMLTitle());
        }
        //Set the return value
        $return[] = array(
            $enhancedTitle,
            $currentRef->getPropertyValue("initid"),
            $currentRef->getTitle()
        );
    }
 
    return $return;
}

Vous pouvez retrouver les aides à la saisie complétées dans les sources.

Et complétez le fichier ./COGIP_AUDIT/COGIP_AUDIT_FNC__STRUCT.csv :

Aide à la saisie : struct

Figure 55. Aide à la saisie : struct

Vous pouvez retrouver les sources complétées dans les sources.

5.3.9 Attributs calculés

Pour finir ce chapitre, vous allez mettre en place un attribut calculé. La date de fin de l'audit doit être calculée en fonction de sa date de début et de sa durée.

Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_AUDIT__CLASS.php et ajoutez la fonction ci-dessous :

/**
 * Compute end date
 * 
 * @param string $dateDebut iso
 * @param int $duree nb days
 * @return string
 */
public function computeDateFin($dateDebut, $duree) {
    if (!empty($dateDebut) && !empty($duree)) {
        $date = new \DateTime($dateDebut);
        $interval = \DateInterval::createFromDateString(sprintf('%d day', $duree));
        $date->add($interval);
        return $date->format("o-m-d");
    }
    return " ";
}

Le retour de l'attribut calculé doit être un espace pour indiquer que le contenu de l'attribut doit-être vidé. Si jamais la fonction retourne une chaîne vide ou rien alors le contenu de l'attribut est laissé tel quel.

Vous pouvez retrouver le fichier PHP complété dans les sources.

Ensuite, vous devez enregistrer la fonction dans le fichier __STRUCT.csv, ouvrez ./COGIP_AUDIT/COGIP_AUDIT_AUDIT__STRUCT.csv et modifiez pour l'attribut caa_date_fin les colonnes :

Vous pouvez retrouver le fichier CSV complété dans les sources.

Bravo ! Vous avez terminé la partie pratique de ce chapitre.

5.3.10 Mise en place des modifications

Vous allez maintenant déployer vos modifications :

<devtool> deploy -s . --url http://admin:anakeen@<nomDeDomaine>/dynacase-control/ --port <port> --context dynacase

Vous pouvez ensuite créer quelques formulaires pour voir les modifications que vous avez mises en place.

5.3.11 Conclusion

Ce chapitre de paramétrage vous a permis de rendre votre formulaire plus interactif et d'y intégrer plus de logique métier.

Dans les chapitres suivants, vous allez continuer à améliorer celui-ci notamment

5.3.12 Voir aussi

5.4 Hook

Dans ce chapitre, vous allez utiliser la notion de hook (hameçons).

5.4.1 Objectifs

5.4.2 Théorie

Les hooks sont des méthodes de la classe Doc qui sont appelées à différents moments clefs de la vie du document.

Dynacase propose deux types de hooks :

La liste des hooks standards est dans la documentation.

5.4.3 Cadre

Lors de la phase de spécification, les éléments suivants ont été identifiés. L'application nécessite :

5.4.4 Automatisation du calcul d'un tableau

Vous allez mettre en place la logique permettant de calculer automatiquement le tableau des Fiches de non conformité.

Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_AUDIT__CLASS.php et ajoutez la fonction suivante :

/**
 * Compute the FNC attributes content
 * 
 * @return string
 */
public function computeFNC() {
    $err = "";
    $fncs = array();
    $search = new \SearchDoc('', 'COGIP_AUDIT_FNC');
    $search->setObjectReturn();
    $search->addFilter("%s = '%d'",
        \Dcp\AttributeIdentifiers\COGIP_AUDIT_FNC::caf_audit,
        $this->getPropertyValue("initid")
    );
    foreach($search->getDocumentList() as $currentFNC) {
        /* @var \Dcp\Family\COGIP_AUDIT_FNC $currentFNC */
        $fncs[] = $currentFNC->getPropertyValue("initid");
     }
    $err .= $this->setValue(MyAttributes::caa_fnc_fnc, $fncs);
    if ($err) {
        $err = __FILE__.":".__LINE__.":".__METHOD__." ".$err."\n";
    }
    return $err;
 }

Cette méthode est assez proche de celles écrites dans le chapitre de paramétrage pour les aides à la saisie.

Les point suivants sont intéressants :

Surchargez ensuite la fonction postStore, cette fonction est appelée automatiquement après chaque enregistrement du document :

public function postStore() {
    $err = parent::postStore();
    $err .= $this->computeFNC();
    if ($err) {
        error_log(__FILE__ . ":" . __LINE__ . ":" . __METHOD__ . " " . $err . "\n");
    }
}

Il est conseillé de ne pas mettre le code métier directement dans la fonction postStore. Il est ainsi possible de surcharger dans les familles filles les fonctions appelées dans les hooks plus facilement.

Vous remarquerez que la méthode computeFNC ne sauvegarde pas les modifications qu'elle effectue (elle n'appelle pas store). En effet, les hooks font automatiquement cette sauvegarde lorsque nécessaire. De plus, cela permet d'appeler les méthodes concernées en dehors des hooks, sans surcoût particulier.

Vous pouvez retrouver le fichier PHP complété dans les sources.

5.4.4.1 Problèmes

A ce stade si vous déployez les sources modifiées, le formulaire calcule automatiquement la valeur de l'attribut caa_fnc_fnc, il reste deux points à résoudre :

Pour corriger le premier point, ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_AUDIT__STRUCT.csv et modifiez la visibilité du tableau des Fiches de non-conformité pour le rendre statique. Modifiez la colonne I :

La liste des fiches de non conformité n'est plus modifiable dans les audits en modification.

Vous pouvez retrouver le fichier CSV complété dans les sources.

Pour corriger le second point, vous devez modifier la fiche de non conformité pour que, lors de sa sauvegarde, elle mette à jour l'audit associé. Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_FNC__CLASS.php et ajoutez la fonction suivante :

/**
 -   Refresh the list of the audit
 * 
 * @return string
 */
public function refreshAudit() {
    $err = "";
    $audit = $this->getAttributeValue(MyAttributes::caf_audit);
    $audit = new_Doc("", $audit, true);
    /* @var \Dcp\Family\COGIP_AUDIT_AUDIT $audit */
    $err .= $audit->computeFNC();
    $err .= $audit->store();
    if ($err) {
        $err = __FILE__ . ":" . __LINE__ . ":" . __METHOD__ . " " . $err . "\n";
    }
    return $err;
 }

Ensuite surchargez la fonction postStore :

/**
 * Hook executed after the store
 *
 * @return string|void
 */
public function postStore() {
    $err = parent::postStore();
    $err .= $this->refreshAudit();
    if ($err) {
        error_log(__FILE__ . ":" . __LINE__ . ":" . __METHOD__ . " " . $err . "\n");
    }
}

Attention à bien appeler le parent lors de la surcharge de la fonction de hook, sinon le code des classes parentes ne serait pas appelé.

Vous pouvez retrouver le fichier PHP complété dans les sources.

5.4.5 Duplication

Vous allez mettre en place un traitement après la duplication d'un audit pour supprimer les dates de l'audit dans le nouveau document créé par duplication.

Les liens vers les fiches de non-conformité sont re-calculé automatiquement après la duplication de la page (car ils sont enregistrés au postStore), il est donc inutile de les supprimer après la duplication.

Ouvrez ./COGIP_AUDIT/COGIP_AUDIT_AUDIT__CLASS.php et ajoutez la fonction suivante :

/**
 * Clean constat date
 *
 * @return string
 */
public function cleanDate() {
    $err = "";
    $err .= $this->clearValue(MyAttributes::caa_date_debut);
    $err .= $this->clearValue(MyAttributes::caa_date_fin);
    $err .= $this->clearValue(MyAttributes::caa_duree);
    if ($err) {
        $err = __FILE__ . ":" . __LINE__ . ":" . __METHOD__ . " " . $err . "\n";
    }
    return $err;
}

Cette fonction utilise clearValue qui permet de vider la valeur d'un attribut.

Ajoutez ensuite la fonction suivante :

public function postDuplicate($copyFrom) {
    $err = parent::postDuplicate($copyFrom);
    $err .= $this->cleanDate();
    if ($err) {
        error_log(__FILE__ . ":" . __LINE__ . ":" . __METHOD__ . " " . $err . "\n");
    }
}

Attention à penser à transmettre le paramètre $copyFrom au parent.

Si vous souhaitez tester, vous pouvez générer le paquet <devtool> generateWebinst -s . et le déployer. Vous pouvez ensuite dupliquer le document en utilisant le menu du document Autres > Dupliquer.

Vous pouvez retrouver le fichier PHP complété dans les sources.

5.4.6 Affichage d'un message aux utilisateurs

Vous allez maintenant mettre en place l'affichage conditionnel d'un message aux utilisateurs lorsque la date de fin d'audit est dépassée.

Ouvrez ./COGIP_AUDIT/COGIP_AUDIT_AUDIT__CLASS.php et ajoutez la fonction suivante :

/**
 * Check if the end date is in the past
 *
 * @return string
 */
public function checkEndDate()
{
    $err = "";
    $date = $this->getAttributeValue(MyAttributes::caa_date_fin);
    if (!empty($date) && $this->getAttributeValue(MyAttributes::caa_date_fin) < new \DateTime()) {
        $err = ___("The end date of the audit is in the past", "COGIP_AUDIT:AUDIT");
    }
    return $err;
}

Ajoutez ensuite la fonction suivante :

/**
 * Hook executed after the refresh
 * 
 * @return string
 */
public function postRefresh() {
    $err = parent::postRefresh();
    $err .= $this->checkEndDate();
    return $err;
}

Si vous souhaitez tester, vous pouvez générer le paquet <devtool> generateWebinst -s . et le déployer.

Une fois le code déployé si la date de fin d'audit est dans le passé vous avez le message suivant qui s'affiche :

Message utilisateur

Figure 56. Message utilisateur

Vous pouvez retrouver le fichier PHP complété dans les sources.

5.4.7 Contrôle à la suppression

Vous allez mettre en place un contrôle à la suppression.

Ouvrez ./COGIP_AUDIT/COGIP_AUDIT_REFERENTIEL__CLASS.php et ajoutez la fonction suivante :

/**
 * Check if exist chapter associated to the current referentiel
 * 
 * @return string
 */
public function checkIfAssociatedChapterExist() {
    $return = "";
    $search = new \SearchDoc("", "COGIP_AUDIT_CHAPITRE");
    $search->addFilter("%s = '%d'",
        \Dcp\AttributeIdentifiers\COGIP_AUDIT_CHAPITRE::cac_ref,
        $this->getPropertyValue("initid")
    );
    $search->setSlice(1);
    $nb = $search->onlyCount();
    if ($nb > 0) {
        $return = ___("You have to delete all associated chapter before delete the ref", "COGIP_AUDIT:REFERENTIEL");
    }
    return $return;
}

Cette fonction effectue une recherche et possède les spécificités suivantes :

Ajoutez ensuite la fonction suivante :

public function preDelete() {
    $msg = parent::preDelete();
    $msg .= $this->checkIfAssociatedChapterExist();
    return $msg;
}

Vous pouvez retrouver le fichier PHP complété dans les sources.

5.4.8 Injection de JS ou CSS

Pour finir ce chapitre, le service qualité a jeté un coup d'œil sur vos ajouts et aimerait que le message envoyé aux utilisateurs soit moins anxiogène et donc moins rouge.

Vous allez donc ajouter une CSS pour obtenir ce comportement.

Ajoutez le fichier ./COGIP_AUDIT/Layout/specRefresh.css :

.COREErrorBg {
    color: rgb(255, 173, 0);
}

Ce fichier définit la couleur de background des erreurs en orange.

Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_BASE__CLASS.php et ajoutez la fonction suivante :

/**
 * Inject a CSS
 */
public function addCSS() {
    global $action;
    $action->parent->addCssRef("COGIP_AUDIT:specRefresh.css");
}

Cette méthode fait appel à la fonction addCssRef, elle permet d'ajouter une CSS à un document.

Vous allez maintenant ajouter les fonctions suivantes :

public function preEdition() {
    $err = parent::preEdition();
    $this->addCSS();
    return $err;
}
 
public function preConsultation() {
    $err = parent::preConsultation();
    $this->addCSS();
    return $err;
}

Les deux fonctions ajoutées s’exécutent respectivement avant l'édition et avant la consultation. La CSS définie ci-dessus est ajoutée dans le formulaire.

Vous pouvez retrouver les sources complétées dans les sources.

5.4.9 Mise en place des modifications

Vous allez maintenant déployer vos modifications :

<devtool> deploy -s . --url http://admin:anakeen@<nomDeDomaine>/dynacase-control/ --port <port> --context dynacase

Vous pouvez ensuite consulter les modifications apportées via l'application http://<nomDeDomaine>/dynacase/.

5.4.10 Conclusion

Vous avez abordé les hooks et leurs fonctionnalités. Ils permettent de surcharger le fonctionnement par défaut des documents de Dynacase pour implémenter la logique métier de votre projet.

5.4.11 Voir aussi

5.5 Sécurité

Ce chapitre va vous permettre de mettre en place les notions de sécurité sur vos familles.

5.5.1 Objectifs

5.5.2 Cadre

Lors de la phase de spécification, les droits suivants ont été identifiés. L'application nécessite :

La définition des familles doit pouvoir être mise à jour par les administrateurs fonctionnels.

En outre, il y a une demande particulière, les auditeurs veulent que dans les fiches de non conformité la partie Écart puisse être vue par tous les utilisateurs pouvant voir le document, mais être modifiée uniquement par les auditeurs.

5.5.3 Théorie

La sécurité applicative des documents dans Dynacase repose sur la notion de profil.

Un profil est une matrice de droits. Il permet d'indiquer quel utilisateur/groupe/rôle peut effectuer quelle action. Il existe deux types d'affectations :

On peut compléter la notion de sécurité avec deux autres éléments :

5.5.4 Profil de famille

Vous allez commencer par définir les profils de famille.

Le profil de famille permet de définir :

5.5.4.1 Création

Connectez vous à l'interface d'administration : http://<nomDeDomaine>/dynacase/admin.php.

Sélectionnez l'application Gestion des documents>Explorateur de documents.

Explorateur de document

Figure 57. Explorateur de document

Cette application permet de créer tous les types de documents de votre contexte.

Cliquez ensuite sur Création > Profil dans l'onglet de droite s'ouvre l'interface suivante :

Création document profil

Figure 58. Création document profil

Déroulez la liste et choisissez le type de document Profil de famille. L'interface suivante est présentée :

Création document profil famille

Figure 59. Création document profil famille

Complétez le titre avec Profil de référentiel et cliquez sur Créer. Vous obtenez l'interface suivante :

Profil famille désactivé

Figure 60. Profil famille désactivé

5.5.4.2 Paramétrage

Le profil de famille est créé désactivé. C'est à dire que toutes les familles associées à ce profil sont libres d'accès, donc tous les utilisateurs peuvent effectuer toutes les actions.

Cliquez sur Activer en bas à droite. L'interface se recharge.

Profil famille activé

Figure 61. Profil famille activé

Le profil de famille est maintenant activé. C'est à dire que toutes les familles associées à ce profil sont restreintes donc aucun utilisateur (sauf l'administrateur) ne peut effectuer une action.

Cliquez sur Accessibilités. Une nouvelle fenêtre s'ouvre et présente la matrice de droits.

Profil famille matrice de droits

Figure 62. Profil famille matrice de droits

Cette matrice présente par défaut uniquement les rôles du contexte. La bonne pratique veut que les droits soient associés via les rôles et non pas directement via les groupes.

Vous allez créer le profil pour les familles Chapitres et Référentiels.

Cliquez sur le bouton ∴ devant Auditeur. L'interface devient semblable à :

Profil famille matrice de droits : modification

Figure 63. Profil famille matrice de droits : modification

Cochez ensuite les cases Create et Créer manuellement.

Il existe deux possibilités de création :

Cliquez sur le ∴ devant Administrateur fonctionnel et cochez les cases Voir, Modifier, Voir les droits et Modifier les droits. Ces droits donnent la possibilité aux administrateurs fonctionnels d'agir sur la définition de la famille.

Profil famille matrice de droits : modification

Figure 64. Profil famille matrice de droits : modification

Cliquez sur Modifier les privilèges, l'interface se présente ensuite de cette manière :

Profil famille matrice de droits : consultation

Figure 65. Profil famille matrice de droits : consultation

5.5.4.3 Export

Vous allez ensuite exporter les documents de profil.

Commencez par associer un nom logique au profil, dans l'interface du document profil Autres>Propriétés. Cliquez sur affecter un nom logique et donnez au document le nom logique PFAM_REFERENTIEL.

Ensuite, sélectionnez le document pour pouvoir l'exporter, dans l'interface du document Autres > Ajouter au porte-documents.
Une fois le porte-documents ouvert, pensez à supprimer les documents qui ne vous intéressent pas et cliquez sur Outils > Exportation du dossier.

Vous pouvez remarquer que le nom logique du document est préfixé de manière à rapidement identifier son type : PFAM pour Profil de famille.

L'interface suivante est présentée :

Profil famille : export

Figure 66. Profil famille : export

Étant donné que vous exportez un profil, vous devez dans l'entrée profil choisir avec les profils.

Profil famille : export

Figure 67. Profil famille : export

Cliquez sur Exporter.

Un fichier CSV vous est envoyé. Ouvrez le fichier :

Profil famille : CSV

Figure 68. Profil famille : CSV

Les spécificités du format sont décrites dans la documentation.

5.5.4.4 Ajout des profils de famille dans les fichiers d'import

Vous pouvez remarquer les points suivants :

5.5.4.4.1 Profil de famille de référentiel

Vous allez maintenant intégrer le profil dans les fichiers de paramétrage de la famille. Ouvrez le fichier /COGIP_AUDIT/COGIP_AUDIT_REFERENTIEL__PARAM.csv :

Bien que le profil soit conçu pour une famille donnée (vous avez en effet spécifié avec quelle famille il peut être utilisé lors de sa création), il faut explicitement déclarer ce profil sur la famille. En effet, la famille spécifiée lors de la création du profil indique que ce profil peut être utilisé avec cette famille, ainsi que ses sous-familles, mais n'indique aucunement que ce sera le profil utilisé par ces familles (il peut notamment exister plusieurs profils compatibles, et le profil à appliqué est changé par du code).

Ce qui donne dans votre cas :

Import référentiel

Figure 69. Import référentiel

Vous pouvez retrouver le fichier complété dans les sources.

5.5.4.4.2 Profil de famille de chapitre

Vous allez maintenant valuer le profil de famille Chapitres. Votre spécification indique que celui-ci est similaire à celui du référentiel.

Vous avez deux choix :

Les deux solutions ont toutes les deux des avantages et des défauts. Toutefois il est considéré comme une bonne pratique de dupliquer les profils de deux familles pour pouvoir les faire évoluer de manière distincte.

Ouvrez le fichier /COGIP_AUDIT/COGIP_AUDIT_CHAPITRE__PARAM.csv:

Ce qui donne dans votre cas :

Import chapitre

Figure 70. Import chapitre

Vous pouvez retrouver le fichier complété dans les sources.

5.5.4.4.3 Profil de famille d'audit

Vous allez maintenant valuer le profil de famille Audits. Votre spécification indique que celui-ci est similaire à celui du référentiel avec juste une différence : le compte ayant le droit de création est le rôle Responsable des audits.

Ouvrez le fichier /COGIP_AUDIT/COGIP_AUDIT_AUDIT__PARAM.csv:

Ce qui donne dans votre cas :

Import audit

Figure 71. Import audit

Vous pouvez retrouver le fichier complété dans les sources.

5.5.4.4.4 Profil de famille de Fiche de non-conformité

Vous allez maintenant valuer le profil de famille Fiche de non-conformité. Votre spécification indique que celui-ci est similaire à celui du référentiel avec juste une différence : le compte ayant le droit de création est le rôle Responsable des audits.

Ouvrez le fichier /COGIP_AUDIT/COGIP_AUDIT_FNC__PARAM.csv:

Ce qui donne dans votre cas :

Import fiche de non-conformité

Figure 72. Import fiche de non-conformité

Vous pouvez retrouver le fichier complété dans les sources.

5.5.5 Profil de document

Vous allez maintenant créer les profils de documents. Un profil de document permet de définir qui peut :

un document.

5.5.5.1 Création

Connectez vous à l'interface d'administration : http://<nomDeDomaine>/dynacase/admin.php.

Sélectionnez l'application Gestion des documents>Explorateur de documents.

Cliquez ensuite sur Création > Profil dans l'onglet de gauche s'ouvre l'interface de création, sélectionnez dans cette interface Profil de document.

Rentrez dans le formulaire le titre Profil des documents référentiels et sélectionnez la famille Référentiel qualité, cliquez ensuite sur Créer.

5.5.5.2 Paramétrage

L'interface affiche ensuite le document de profil en consultation. Cliquez sur activer et une fois l'interface rechargée cliquez sur Accessibilités, la matrice des droits s'ouvre.

Donnez les droits suivants :

Techniquement, il n'est pas nécessaire de donner le droit voir au rôle Auditeur, puisque les gens ayant ce rôle sont également censés avoir le rôle Utilisateur COGIP. Cependant, ce paramétrage pourra être amené à évoluer. Afin d'éviter les mauvaises surprises lors de la mise à jour des profils, il est conseillé de donner explicitement le droit voir aux comptes auxquels on donne le droit modifier.

Vous obtenez la matrice suivante :

Import Profil de document

Figure 73. Import Profil de document

5.5.5.3 Export

Ajoutez le nom logique PDOC_REFERENTIEL au document au moyen du menu Autres>Propriétés. Ajoutez le au porte-documents au moyen du menu Autres>Ajouter au porte-documents (pensez à supprimer les éventuels autres documents) et cliquez ensuite sur Outils>exportation du dossier. Vous devez indiquer dans la partie Profil Avec les profils et ensuite cliquer sur Exporter.

Le fichier CSV suivant vous est envoyé :

CSV Profil de document

Figure 74. CSV Profil de document

Le fichier se présente exactement de la même manière que celui de profil de famille et contient le même type d'informations.

Vous pouvez remarquer que le nom logique du document est préfixé de manière à rapidement identifier son type : PDOC pour Profil de document.

5.5.5.4 Ajout des profils de document dans les fichiers d'import

5.5.5.4.1 Profil de document de référentiel

Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_REFERENTIEL__PARAM.csv.

Ajoutez :

Profil de document : import référentiel

Figure 75. Profil de document : import référentiel

Vous pouvez retrouver le fichier complété dans les sources.

5.5.5.4.2 Profil de document de chapitre

Vous allez maintenant valuer le profil de famille Chapitres. Votre spécification indique que celui-ci est similaire à celui du référentiel.

Ouvrez le fichier /COGIP_AUDIT/COGIP_AUDIT_CHAPITRE__PARAM.csv:

Profil de document : import chapitre

Figure 76. Profil de document : import chapitre

Vous pouvez retrouver le fichier complété dans les sources.

5.5.5.4.3 Profil de document d'audit et de fiche de non-conformité

L'audit et les fiches de non conformité ne vont pas avoir pour l'instant de profil de document, car ils ont un cycle de vie et leur profil de document est fixé par leur cycle de vie.

5.5.6 Contrôle de vue

Vous allez maintenant configurer le contrôle de vue.

Le contrôle de vue va vous permettre de définir des masques variant suivant l'utilisateur connecté.

5.5.6.1 Masque

Vous allez commencer par créer le masque.

5.5.6.1.1 Création

Connectez vous à l'interface d'administration : http://<nomDeDomaine>/dynacase/admin.php, sélectionnez l'application Gestion des documents>Explorateur de documents, cliquez sur Création>Documents système et sélectionnez dans la liste déroulante en haut à droite Masque de saisie.

Vous obtenez l'interface ci-dessous :

Masque : Création

Figure 77. Masque : Création

Veuillez compléter les éléments suivants :

Masque : Création

Figure 78. Masque : Création

Mettez l'attribut tab Écarts à la visibilité Statique et l'attribut array Écarts à Tableau statique.

Masque : Création

Figure 79. Masque : Création

Et cliquez sur Sauver.

Masque : Création

Figure 80. Masque : Création

Vous pouvez remarquer qu'en ayant fixé l'attribut encadrant en lecture seule, tous les attributs qu'il contient sont passés en lecture seule.

5.5.6.1.2 Export

Ajoutez un nom logique au document en cliquant sur Autres>Propriétés et fixez le nom logique à MASK_FNC_DEFAULT.

Ajoutez le masque au porte-documents, en cliquant sur Autres>Ajoutez au porte-documents.

Pensez à supprimer les éventuels autres documents du porte-documents.

Le contenu du porte-documents sera exporté avec le contrôle de vue.

Vous pouvez remarquer que le nom logique du document est préfixé de manière à rapidement identifier son type : MASK pour Masque.

5.5.6.2 Contrôle de vue

5.5.6.2.1 Création

Connectez vous à l'interface d'administration : http://<nomDeDomaine>/dynacase/admin.php, sélectionnez l'application Gestion des documents>Explorateur de documents, cliquez sur Création>Documents système et sélectionnez dans la liste déroulante en haut à droite Contrôle de vue.

Vous obtenez l'interface ci-dessous :

Contrôle de vue : Création

Figure 81. Contrôle de vue : Création

L'interface vous permet de :

Vous allez compléter :

Vous devez obtenir un formulaire similaire à :

Contrôle de vue : Création

Figure 82. Contrôle de vue : Création

Ajoutez une vue en cliquant sur le + du tableau vue.

Chaque ligne vous propose les options suivantes :

Id vue
identifiant logique de la vue,
Label
un label pour la vue (utilisé pour les menu et les interfaces d'admin),
Type
le type de vue soit une vue d'édition (modification), soit de consultation,
Zone

indique la zone utilisée pour représenter le document.

Une zone permet de re-définir complètement la représentation d'un document,

Masque

indique le masque associé à cette vue.

le masque permet de définir les visibilités applicable lors de la représentation du document,

Affichable
indique si la vue est accessible via un menu sur le document,
Ordre
parmi toutes les vues utilisables par un utilisateur, c'est la vue ayant l'ordre le plus faible qui est sélectionnée.

Vous allez ajouter deux vues :

Complétez le tableau des vues comme présenté ci-dessous :

Contrôle de vue : Création

Figure 83. Contrôle de vue : Création

Cliquez sur Créer.

5.5.6.2.2 Paramétrage

Vous allez maintenant paramétrer les droits associés au contrôle de vue. Ceci permet d'exprimer quelles vues sont proposées à l'utilisateur en fonction de ses rôles et groupes d'appartenance.

Cliquez sur Autres>Sécurité>Profil dédié. La page se recharge, cliquez maintenant sur Autres>Sécurité>Accessibilités....

L'interface suivante vous est présentée :

Contrôle de vue : Paramétrage

Figure 84. Contrôle de vue : Paramétrage

Veuillez compléter la matrice avec le paramétrage suivant :

Contrôle de vue : Paramétrage

Figure 85. Contrôle de vue : Paramétrage

Les droits que vous avez attribués correspondent à :

Les utilisateurs ayant le rôle auditeurs ont donc accès aux deux vues de modification. Mais la vue dédiée aux auditeurs à un ordre plus faible, elle est donc utilisée prioritairement.

5.5.6.2.3 Export

Vous allez maintenant exporter le contrôle de vue et son masque.

Ajoutez un nom logique CVDOC_FNC au contrôle de vue au moyen du menu Autres>Propriétés. Ajoutez le contrôle de vue au porte-documents, en cliquant sur Autres>Ajoutez au porte-documents.

Vous pouvez remarquer que le nom logique du document est préfixé de manière à rapidement identifier son type : CVDOC pour Contrôle de vue.

Le porte-documents doit présenter le masque et le contrôle de vue.

Porte-documents : contrôle de vue et masque

Figure 86. Porte-documents : contrôle de vue et masque

Cliquez ensuite sur Outils>Exportation du dossier, la fenêtre d'export s'ouvre.

Vous devez indiquer dans la partie Profil Avec les profils et ensuite cliquer sur Exporter.

Vous obtenez le fichier suivant :

Porte-documents : contrôle de vue et masque

Figure 87. Porte-documents : contrôle de vue et masque

Ce fichier contient :

5.5.6.3 Ajout du contrôle de vue dans les fichiers d'import

Vous allez ajouter le contenu de ce fichier dans le fichier de paramétrage de la famille associée. Ouvrez ./COGIP_AUDIT/COGIP_AUDIT_FNC__PARAM.csv :

Vous obtenez le fichier suivant :

Famille paramétrage : Fiche de non-conformité

Figure 88. Famille paramétrage : Fiche de non-conformité

Vous pouvez retrouver le fichier complété dans les sources.

5.5.7 Mise en place des modifications

Vous allez maintenant déployer vos modifications :

<devtool> deploy  -s . --url http://admin:anakeen@<nomDeDomaine>/dynacase-control/ --port <port> --context dynacase

Attention : Les profils ne s'appliquent que sur les nouveaux documents, les documents déjà existant n'étant pas profilés ceux-ci sont accessibles par tous les utilisateurs. En production, il vous faudrait faire un script de migration pour profiler les documents pré-existants.

Vous devez donc créer de nouveaux documents pour tester.

Vous pouvez maintenant vous connecter à l'application et consulter une fiche de non-conformité avec un utilisateur ayant le profil Auditeur (marthe.karine/p@ssw0rd).

FNC profil auditeur

Figure 89. FNC profil auditeur

FNC profil DSI

Figure 90. FNC profil DSI

Vous pouvez remarquer que l'utilisateur ayant le profil auditeur peut ajouter des lignes d'écart alors que celui qui n'a pas ce profil. Le DSI dans l'exemple ci-dessus (arnic.marina/p@ssw0rd), ne le peut pas.

5.5.8 Voir aussi

5.6 Vue

Ce chapitre va vous permettre de modifier la mise en forme des documents en modification et en consultation.

5.6.1 Objectifs

5.6.2 Cadre

Lors de la phase de spécification et des premiers retours les demandes suivantes ont été émises. Certains détails pourraient être améliorés sur les formulaires :

5.6.3 Théorie

La modification des options de génération des formulaires utilise plusieurs techniques différentes :

5.6.4 Les options

Vous allez commencer par la technique la plus simple à mettre en œuvre : la modification des options de mise en forme des attributs.

Vous allez utiliser l'option vlabel, cette option permet d'indiquer où vous souhaitez afficher le libellé des attributs.

Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_AUDIT__STRUCT.csv et modifiez les lignes :

Audit : Structure

Figure 93. Audit : Structure

Ces options indiquent à Dynacase qu'il ne faut pas mettre de label dans la génération du document pour ces attributs.

Une fois le fichier de structure importé ou le module déployé le formulaire devient semblable à :

Audit : Pièces jointes

Figure 94. Audit : Pièces jointes

Vous pouvez remarquer que les deux libellés pièces jointes surnuméraires ne sont plus présents.

Vous pouvez retrouver le fichier mis à jour dans les sources.

5.6.5 Le style

Vous allez créer votre style. Un style est composé d'un fichier de définition et de fichier d'assets (css, js, layout), et permet de définir des règles de mise en forme valables sur un contexte.

5.6.5.1 Création des fichiers

Ajoutez un répertoire COGIP_AUDIT dans le répertoire STYLE. Ensuite, ajoutez un fichier COGIP_AUDIT.sty dans le répertoire COGIP_AUDIT.

Le fichier .sty est un fichier php, ce fichier doit contenir le code suivant :

<?php
//global $sty_desc, $sty_const;
$sty_desc = array(
    "name" => "COGIP_AUDIT", //Name
    "description" => "COGIP_AUDIT", //long description
);
 
$sty_inherit = "STYLE/MODERN/MODERN.sty";

Ce code indique le nom logique du style et son style parent. Dans votre cas, c'est le style par défaut de Dynacase.

5.6.5.2 Ajout des règles spécifiques

Vous allez ajouter des règles spécifiques à votre nouveau style.

Ajoutez un répertoire Layout sous le répertoire STYLE/COGIP_AUDIT et ajoutez-y un fichier style_s_attributes.css.

Le nom du fichier est libre. ; toutefois, puisque vous pouvez être amenés à créer plusieurs fichiers, il ets important de donner des noms explicites.

Vous devez avoir la structure de fichiers suivante :

│STYLE
├── COGIP_AUDIT
│   ├── COGIP_AUDIT.sty
│   └── Layout
│       └── style_s_attributes.css

Le fichier CSS doit contenir :

.document input[visibility="S"],
.document input[visibility="S"]:hover,
.document textarea[visibility="S"],
input[visibility="S"],
input[visibility="S"]:hover,
textarea[visibility="S"],
div.static {
    color: black;
    background: white;
    border: none;
    border-style: none;
    padding: 0;
    margin-bottom: 0;
    text-overflow: ellipsis;
}
 
select[visibility="S"] {
    border: none;
    color: black;
    background: white;
    -webkit-appearance: none;
    -moz-appearance: none;
}
 
input[disabled="disabled"],
input[disabled] {
    cursor: auto;
}
 
.document input[visibility="S"], .document input[visibility="S"]:hover {
    background-color: white;
    background-image: none;
    padding: 3px;
}

Ces règles CSS vont rendre les attributs en S avec un fond blanc et une police noire sur les vues d'édition et sur les navigateurs suffisamment récents (supérieurs à IE7).

Vous allez maintenant enregistrer votre fichier CSS pour que celui-ci soit ajouté aux fichiers CSS produit par Dynacase.

Ouvrez le fichier STYLE/COGIP_AUDIT/COGIP_AUDIT.sty et modifiez le contenu pour qu'il soit semblable à :

<?php
//global $sty_desc, $sty_const;
$sty_desc = array(
    "name" => "COGIP_AUDIT", //Name
    "description" => "COGIP_AUDIT", //long description
);
 
$sty_inherit = "STYLE/MODERN/MODERN.sty";
// global parameters which can be use for other css
$sty_rules = array(
    'css' => array(
        'dcp/document-edit.css' => array(
            "src" => array(
                "ultra" => "STYLE/COGIP_AUDIT/Layout/style_s_attributes.css"
            )
        )
    )
);

Vous pouvez trouver la liste des règles de compositions applicables dans la documentation.

Vous pouvez retrouver le repertoire style initialisé dans les sources.

5.6.5.3 Import du style

Ouvrez le fichier info.xml et ajoutez à la fin de la procédure d'installation et d'upgrade l'instruction suivante :

<process command="./wsh.php --api=setStyle --style=STYLE/COGIP_AUDIT/COGIP_AUDIT.sty"/>

Ce qui donne :

<?xml version="1.0"?>
<module name="COGIP_AUDIT" disabled="no" version="1.0.0" release="0">
 
    <description>Cogip audit application</description>
 
    <requires>
        <module comp='ge' version='3.2' name='dynacase-core'/>
    </requires>
 
    <post-install>
        <process command="programs/record_application COGIP_AUDIT" />
        <process command="./wsh.php --api=importDocuments --file=./COGIP_AUDIT/ROLE_INIT_DATA.csv"/>
        <process command="./wsh.php --api=importDocuments --file=./COGIP_AUDIT/IGROUP_INIT_DATA.csv"/>
        <process command="./wsh.php --api=importDocuments --file=./COGIP_AUDIT/IUSER_INIT_DATA.csv"/>
        <process command="./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_BASE__STRUCT.csv"/>
        <process command="./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_BASE__PARAM.csv"/>
        <process command="./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_REFERENTIEL__STRUCT.csv"/>
        <process command="./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_REFERENTIEL__PARAM.csv"/>
        <process command="./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_CHAPITRE__STRUCT.csv"/>
        <process command="./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_CHAPITRE__PARAM.csv"/>
        <process command="./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_AUDIT__STRUCT.csv"/>
        <process command="./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_AUDIT__PARAM.csv"/>
        <process command="./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_FNC__STRUCT.csv"/>
        <process command="./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_FNC__PARAM.csv"/>
        <process command="programs/update_catalog" />
        <process command="./wsh.php --api=setStyle --style=STYLE/COGIP_AUDIT/COGIP_AUDIT.sty"/>
    </post-install>
 
    <post-upgrade>
        <process command="programs/pre_migration COGIP_AUDIT" />
        <process command="programs/record_application COGIP_AUDIT" />
        <process command="./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_BASE__STRUCT.csv"/>
        <process command="./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_BASE__PARAM.csv"/>
        <process command="./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_REFERENTIEL__STRUCT.csv"/>
        <process command="./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_REFERENTIEL__PARAM.csv"/>
        <process command="./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_CHAPITRE__STRUCT.csv"/>
        <process command="./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_CHAPITRE__PARAM.csv"/>
        <process command="./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_AUDIT__STRUCT.csv"/>
        <process command="./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_AUDIT__PARAM.csv"/>
        <process command="./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_FNC__STRUCT.csv"/>
        <process command="./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_FNC__PARAM.csv"/>
        <process command="programs/post_migration COGIP_AUDIT" />
        <process command="programs/update_catalog" />
        <process command="./wsh.php --api=setStyle --style=STYLE/COGIP_AUDIT/COGIP_AUDIT.sty"/>
    </post-upgrade>
 
</module>

Après déploiement, cela donne pour la date évoquée ci-dessus, en édition :

Audit : Date Statique

Figure 95. Audit : Date Statique

5.6.6 Vue d'attribut

Vous allez utiliser la vue d'attribut. Celle-ci va vous permettre de mettre en forme les différentes dates de l'audit pour qu'elles soient présentées sur la même ligne et pas les unes en dessous des autres.

5.6.6.1 Vue d'attribut : édition

5.6.6.1.1 Création

Vous allez commencer par la vue d'édition.

Ajoutez le fichier audit_dates_edit.xml dans le répertoire ./COGIP_AUDIT/Layout. Ce fichier va contenir la définition de la représentation des attributs en édition.

Veuillez le compléter comme ci-dessous :

<style>
    [attrid=caa_duree] {
        display : none;
    }
    [attrid=caa_date_fin] {
        display : none;
    }
    .date-label {
        box-sizing: border-box;
        display: inline-block;
        width: 30%;
        float: left;
        text-align: right;
        padding: 2px 5px 1px 1px;
    }
    .date-value {
        box-sizing: border-box;
        display: inline-block;
        width: 70%;
        float: right;
        padding: 1px;
    }
    .date-duree {
        padding-left: 10px;
    }
</style>
 
<div class="date-label">
    <span>[L_CAA_DATE_DEBUT]&nbsp;:</span>
</div>
 
<div class="date-value">
    <span>[V_CAA_DATE_DEBUT]</span>
    <span class="date-duree">[L_CAA_DUREE] &nbsp;: [V_CAA_DUREE]</span>
</div>

De plus, vous devez créer une vue d'attribut vide pour cacher les attributs. Ajoutez le fichier audit_void.xml dans le répertoire ./COGIP_AUDIT/Layout. Ce fichier reste vide car il va servir à cacher les attributs de durée et de fin qui sinon seraient représentés deux fois.

Vous pouvez retrouver les fichier complété dans les sources.

5.6.6.1.2 Enregistrement

Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_AUDIT__STRUCT.csv et ajoutez les options suivantes :

Vous pouvez retrouver le fichier mis à jour dans les sources.

Une fois le paquet déployé, vous obtenez en édition sur les documents d'audit le rendu suivant :

Audit : Attributs alignés

Figure 96. Audit : Attributs alignés

Le nom du fichier du fichier doit-être en minuscule et celui dans l'options edittemplate et viewtemplate n'est pas sensible à la casse.

5.6.6.2 Vue d'attribut : consultation

5.6.6.2.1 Création

Vous allez maintenant customiser la vue de consultation.

Ajoutez le fichier audit_dates_view.xml dans le répertoire ./COGIP_AUDIT/Layout/.

Veuillez le compléter comme ci-dessous :

<style>
    #Tcaa_f_desc tr:nth-child(0n+4), #Tcaa_f_desc tr:nth-child(0n+5) {
        display : none;
    }
    .date-label {
        box-sizing: border-box;
        display: inline-block;
        width: 30%;
        float: left;
        text-align: right;
        padding: 2px 5px 1px 1px;
    }
    .date-value {
        box-sizing: border-box;
        display: inline-block;
        float: left;
        padding: 2px;
    }
    .date-fin {
        padding-left: 10px;
    }
    .date-separator {
        float: left;
        padding: 2px;
    }
    .date-separator:before {
        content: ":";
    }
</style>
 
<div class="date-label">
    <span>[L_CAA_DATE_DEBUT]</span>
</div>
 
<div class="date-separator">
</div>
 
<div class="date-value">
    <span>[V_CAA_DATE_DEBUT]</span>
    <span class="date-fin">[L_CAA_DATE_FIN] &nbsp;: [V_CAA_DATE_FIN]</span>
</div>

Vous pouvez retrouver les fichier complété dans les sources.

5.6.6.2.2 Enregistrement

Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_AUDIT__STRUCT.csv et ajoutez les options suivantes :

Une fois le paquet déployé, vous obtenez en consultation sur les documents d'audit le rendu suivant :

Audit : Attributs alignés

Figure 97. Audit : Attributs alignés

Vous pouvez retrouver le fichier mis à jour dans les sources.

Le nom du fichier du fichier doit-être en minuscule et celui dans l'options edittemplate et viewtemplate n'est pas sensible à la casse.

5.6.7 Vue de rangée de tableau

Vous allez maintenant créer une vue de rangée de tableau. Cette vue va vous permettre d'organiser différemment la présentation des lignes d'un tableau. Elle est souvent mise en place sur des tableaux ayant de nombreuses colonnes pour les présenter de manière plus compacte.

Ajoutez un fichier fnc_table.xml dans le répertoire ./COGIP_AUDIT/Layout.

Ce fichier doit contenir :

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE table [
        <!ELEMENT table (table-head*,table-body*)>
 
        <!ELEMENT table-head (cell)*>
        <!ELEMENT table-body (cell)*>
 
        <!ELEMENT cell ANY>
        <!ATTLIST cell
                class CDATA #IMPLIED
                style CDATA #IMPLIED>
        ]>
 
<table>
    <table-body>
        <cell>
            <div class="cogip-fnc-cell" data-attrid="caf_action_desc">
                <div class="cogip-label">[L_CAF_ACTION_DESC] :</div>
                <div class="cogip-value">[V_CAF_ACTION_DESC]</div>
            </div>
            <div class="cogip-fnc-cell" data-attrid="caf_action_resp">
                <div class="cogip-label">[L_CAF_ACTION_RESP] :</div>
                <div class="cogip-value">[V_CAF_ACTION_RESP]</div>
            </div>
            <div class="cogip-fnc-cell" data-attrid="caf_action_date">
                <div class="cogip-label">[L_CAF_ACTION_DATE] :</div>
                <div class="cogip-value">[V_CAF_ACTION_DATE]</div>
            </div>
        </cell>
    </table-body>
</table>

Vous pouvez retrouver le fichier mis à jour dans les sources.

Le fichier ci-dessus décrit un template de table où :

Ensuite ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_FNC__STRUCT.csv et modifiez la colonne P (options) de la ligne caf_a_action pour remplacer la colonne options (vide) par vlabel=up|rowviewzone=COGIP_AUDIT:FNC_TABLE.xml|roweditzone=COGIP_AUDIT:FNC_TABLE.xml.

Le nom du fichier du fichier doit-être en minuscule et celui dans l'options edittemplate et viewtemplate n'est pas sensible à la casse.

Vous pouvez retrouver le fichier mis à jour dans les sources.

Ces nouvelles options indiquent que le template ci-dessus est utilisé en édition et en consultation.

Après le déploiement du paquet, le tableau est présenté de la manière suivante :

FNC : tableau mis en forme

Figure 98. FNC : tableau mis en forme

5.6.8 Vue de document

Vous allez finir ce chapitre en mettant en place une vue de document pour l'édition.

Vous allez mettre en place une vue qui effectue plusieurs actions :

Une vue est composée de deux éléments :

5.6.8.1 Création de la vue

Vous allez commencer par ajouter le fichier de template. Ajoutez un fichier edit_admin.xml dans le répertoire ./COGIP_AUDIT/Layout/.

Ce fichier doit contenir :

[DOCUMENT]

Vous pouvez retrouver le fichier mis à jour dans les sources.

Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_BASE__CLASS.php et ajoutez les fonctions suivantes :

    /** Total edition */
 
    /**
     * Controller of total admin
     *
     * @templateController
     */
    public function edit_admin()
    {
        if ($this->userIsAdmin()) {
            //Choice of the default zone (FDL:EDITBODYCARD)
            $message = _("coa:Admin edition : beware !");
            $css = <<<CSS
.normal::before {
    display: block;
    width: 100%;
    text-align: center;
    content: "$message";
    color: red;
    font-size: 2em;
}
CSS;
            global $action;
            /* @var \Action $action */
            $action->parent->addCssCode($css);
            $zonebodycard = "FDL:EDITBODYCARD";
            $attributes = $this->getAttributes();
            foreach ($attributes as $currentAttribute) {
                /* @var \NormalAttribute $currentAttribute */
                if (is_a($currentAttribute, "NormalAttribute") && $currentAttribute->mvisibility !== "I") {
                    $currentAttribute->setVisibility("W");
                }
            }
            $this->lay->set("DOCUMENT", $this->viewDoc($zonebodycard));
            return;
        }
        $this->lay->set("DOCUMENT", "<h1>You cannot access to this page</h1>");
    }
 
    /**
     * Compute if user have the admin role
     *
     * @return bool
     */
    protected function userIsAdmin()
    {
        global $action;
 
        if ($action->user->id == 1) {
            return true;
        }
        $roles = $action->user->getAllRoles();
        foreach ($roles as $currentRole) {
            if (strtolower($currentRole["login"]) === "role_admin_fonctionnel") {
                return true;
            }
        }
        return false;
    }

Vous pouvez retrouver le fichier mis à jour dans les sources.

Vous pouvez remarquer les points suivants :

5.6.8.2 Ajout du menu

Vous allez maintenant ajouter le menu.

Ouvrez le fichier COGIP_AUDIT/COGIP_AUDIT_BASE__STRUCT.csv et ajoutez la ligne suivante :

Base : définition de menu

Figure 99. Base : définition de menu

Vous pouvez retrouver le fichier mis à jour dans les sources.

Vous allez gérer les visibilités de ce menu. Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_BASE__CLASS.php et ajoutez la fonctions suivante :

/**
 -   Compute menu visibility
 *
 -   @return int
 */
public function visibilityAdminMenu()
{
    if ($this->userIsAdmin()) {
        return MENU_ACTIVE;
    } else {
        return MENU_INVISIBLE;
    }
}

Vous pouvez retrouver le fichier mis à jour dans les sources.

Cette fonction va vous permettre de définir que le menu est visible uniquement pour les utilisateurs ayant le profil administrateur.

Ouvrez le fichier COGIP_AUDIT/COGIP_AUDIT_BASE__STRUCT.csv et modifiez la colonne M (phpfunc) pour l'attribut cab_menu_admin_edit en la complétant avec ::visibilityAdminMenu().

Vous pouvez retrouver le fichier mis à jour dans les sources.

5.6.8.3 Résultat

Une fois le paquet déployé et si l'utilisateur connecté est administrateur, un menu supplémentaire est affiché.

Menu édition admin

Figure 100. Menu édition admin

Après avoir cliqué sur ce menu, la vue suivante s'ouvre :

Édition admin

Figure 101. Édition admin

Vous pouvez remarquer dans cette vue :

5.6.9 Mise en place des modifications

Vous allez maintenant déployer vos modifications :

<devtool> deploy -s . --url http://admin:anakeen@<nomDeDomaine>/dynacase-control/ --port <port> --context dynacase

5.6.10 Conclusion

Dans ce chapitre vous avez expérimenté les principales techniques de modifications d'interface. Vous avez pu constater que le formulaire est facilement modifiable, à la fois dans les détails de mise en forme et dans son fonctionnement.

5.6.11 Voir aussi

5.7 Utilisation de Dynacase Document UIs

Dynacase Document UIs est un module Dynacase permettant de générer une représensation des documents au moyen des technologies HTML5.

Le rendu des documents sans ce module est fait par le serveur, sous la forme d'une page HTML4 monolythique. Dynacase Document UIs permet à la génération de se faire côté client au moyen de Javascript, HTML5 et CSS.

Cela apporte les avantages suivants :

Pour une présentation plus détaillée de Dynacase Document UIs, se reporter au [manuel de référence][ddui-ref:index].

5.7.1 Cadre

Au vu de cette présentation, on vous a demandé d'utiliser Dynacase Document UIs pour rendre le document plus attrayant.

5.7.2 Ajout de la dépendance à Dynacase-Document-uis

comme pour les [dépendances précédentes][dynacase-qs:dependances], il suffit d'ajouter une ligne au fichier info.xml.

VOus allez ajouter la ligne suivante dans la balise <requires/> :

<module name="dynacase-document-uis" comp="ge" version="1.0"/>

puis déployer à nouveau le module :

<devtool> deploy -s . --url http://admin:anakeen@<nomDeDomaine>/dynacase-control/ --port <port> --context dynacase

Vous pouvez ensuite importer les documents d'exemples du fichier COGIP_AUDIT/COGIP_AUDIT_DDUI.csv, puis vous rendre sur la page http://<nomDeDomaine>/dynacase/api/v1/documents/DDUI_AUDIT.html pour consulter le document tel que rendu par Dynacase Document UIs.

pour plus de détails sur les fonctionnalités de Dynacase Document UIS, se reporter au quick start correspondant

[ddui-ref:index] #ddui-ref: [dynacase-qs:dependances] #dynacase-qs:10724c51-b509-4e1b-8fd4-c066e7be55db

Chapitre 6 Cycle de vie

Vous allez maintenant configurer les cycles de vie de votre application.

Le cycle de de vie est un élément de Dynacase qui permet d'encadrer la vie d'un document via un ensemble d'étapes et de transitions. À chaque étape, le développeur peut spécifier :

Les cycles de vie de votre application vous permettent donc de structurer votre application et de définir des parcours guidant les utilisateurs lors de la complétion de leurs documents métiers.

6.1 Structure du cycle de vie

Ce chapitre va vous permettre d'initialiser vos cycles de vie, en créer la structure et les associer à une famille.

6.1.1 Objectifs

6.1.2 Cadre

L'analyse des besoins à mis en évidence le besoin de deux cycles de vie dans votre application.

Deux cycles ont été identifiés :

6.1.3 Théorie

La structure d'un cycle de vie fait appel aux concepts suivants :

Étape

Elles marquent un moment clef dans la vie du document. Une étape est constituée de :

État
c'est le statut du document à un moment donné (par exemple : brouillon, rédigé, validé, historique),
Activité
c'est la tâche en cours de réalisation sur un document donné (par exemple : en rédaction, en validation).
Transition
Elles indiquent la possibilité de passage entre une étape et une autre.

Les cycles de vie sont représentés par deux objets systèmes :

6.1.4 Initialisation des fichiers

6.1.4.1 Cycle des audits

Ouvrez une console et rendez vous dans le répertoire de votre application et lancez la commande suivante :

<devtool> createWorkflow -s . -n COGIP_AUDIT_AUDIT -m COGIP -a COGIP_AUDIT

Deux fichiers sont générés :

./COGIP_AUDIT
...
├── COGIP_AUDIT_AUDIT__WFL.php
├── COGIP_AUDIT_AUDIT__WFL.csv

Le fichier .php contient le code métier et la structure du cycle de vie, le fichier .csv contiendra quelques éléments de paramétrage.

Le fichier est initialisé avec les éléments suivants :

namespace COGIP;
 
class COGIP_AUDIT_AUDIT__WFL extends \Dcp\Family\WDoc
{
    public $attrPrefix = 'FIXME'; //FIXME: set attrPrefix
    public $firstState = 'FIXME'; //FIXME: set FirstState
    public $viewlist = "none";
 
    //region States
    const e_E1 = 'FIXME'; //FIXME: set E1
    //endregion
 
    //region Transitions
    const t_E1__E2 = 'FIXME'; //FIXME: set T1
    //endregion
 
    public $stateactivity = array(
        //FIXME: set stateactivity
    );
 
    public $transitions = array(
        //FIXME: set transitions
    );
 
    public $cycle = array(
        //FIXME: set cycle
    );
 
}

6.1.4.2 Préfixe

L' $attrPrefix est utilisé lors de la génération de la table de stockage du cycle de vie pour éviter des collisions de noms.

Complétez la valeur de $attrPrefix à caaw.

6.1.4.3 États

6.1.4.3.1 Constantes

Vous allez ensuite définir la liste des constantes représentant les états. Pour chaque état, vous allez indiquer un nom logique qui porte sa référence.

//region States
const e_brouillon = 'coa_audit_e1';
const e_annule = 'coa_audit_e2';
const e_redaction = 'coa_audit_e3';
const e_certifie = 'coa_audit_e4';
const e_refus_certif = 'coa_audit_e5';
//endregion

Il est conseillé de mettre les noms des états sous la forme d'un identifiant neutre (id, uuid) pour pouvoir plus simplement gérer le changement de forme du cycle de vie et de paramétrage de celui-ci.

Les commentaires //region States et //endregion sont une convention de certains éditeurs (PhpStorm, etc.) qui permet de replier et retrouver plus facilement cette zone.

6.1.4.4 Activités

L'activité est un deuxième libellé qui est apposé à l'étape. Il décrit l'activité qui doit avoir lieu lors de cette étape.

public $stateactivity = array(
    self::e_brouillon => "coa_planning",
    self::e_redaction => "coa_writing"
);

En théorie, les étapes finales d'un cycle n'ont pas d'activité. Par exemple, une fois l'audit Certifié, Annulé ou Refusé, il n'y a plus de travail à effectuer sur cet audit, et donc pas d'activité.

6.1.4.5 Transitions

6.1.4.5.1 Constantes

Vous allez ensuite définir la liste des constantes représentant les transitions. Pour chaque transition, vous allez indiquer un nom logique qui porte sa référence.

//region Transitions
const t_brouillon__redaction = 'coa_audit_t1';
const t_brouillon__annule = 'coa_audit_t2';
const t_redaction__brouillon = 'coa_audit_t3';
const t_redaction__certif = 'coa_audit_t4';
const t_redaction__refus_certif = 'coa_audit_t5';
//endregion

Il est conseillé de mettre les noms des états sous la forme d'un identifiant neutre (id, uuid) pour pouvoir plus simplement gérer le changement de forme du cycle de vie et de paramétrage de celui-ci.

Il est possible d'utiliser la même transition pour relier deux étapes mais ce fonctionnement est déconseillé car tout le paramétrage de la transition est alors partagé, notamment les droits d'accès ce qui rend le cycle moins facilement paramétrable.

Il est conseillé de nommer les transitions sous la forme t_<etat1>__<etat2> pour en faciliter le paramétrage.

6.1.4.5.2 Paramétrage

Vous allez maintenant enregistrer les constantes dans le tableau des transitions.

public $transitions = array(
    self::t_brouillon__redaction => array("nr" => true),
    self::t_brouillon__annule => array("nr" => true),
    self::t_redaction__brouillon => array("nr" => true),
    self::t_redaction__certif => array("nr" => true),
    self::t_redaction__refus_certif => array("nr" => true),
);

Ce tableau est le seul élément obligatoire, il répertorie l'ensemble des transitions existantes et leur paramétrage.

6.1.4.6 Cycle

Pour terminer, vous allez enregistrer la forme du cycle en utilisant $cycle.

public $cycle = array(
    array("t" => self::t_brouillon__redaction, "e1" => self::e_brouillon, "e2" => self::e_redaction),
    array("t" => self::t_brouillon__annule, "e1" => self::e_brouillon, "e2" => self::e_annule),
    array("t" => self::t_redaction__brouillon, "e1" => self::e_redaction, "e2" => self::e_brouillon),
    array("t" => self::t_redaction__certif, "e1" => self::e_redaction, "e2" => self::e_certifie),
    array("t" => self::t_redaction__refus_certif, "e1" => self::e_redaction, "e2" => self::e_refus_certif),
);

Le tableau de cycle est composé de tableau, chacun de ces tableaux a trois entrées :

6.1.4.7 Premier état

Vous allez maintenant définir le premier état de votre cycle. Passez $firstState = self::e_brouillon.

6.1.4.8 Résultat

Vous avez terminé la déclaration de la structure. Le fichier doit donc contenir :

namespace COGIP;
 
class COGIP_AUDIT_AUDIT__WFL extends \Dcp\Family\WDoc
{
    public $attrPrefix = 'caaw';
    public $firstState = self::e_brouillon;
    public $viewlist = "none";
 
    //region MyAttributes-constants
    //endregion
 
    //region States
    const e_brouillon = 'coa_e1';
    const e_annule = 'coa_e2';
    const e_redaction = 'coa_e3';
    const e_certifie = 'coa_e4';
    const e_refus_certif = 'coa_e5';
    //endregion
 
    //region Transitions
    const t_brouillon__redaction = 'coa_t1';
    const t_brouillon__annule = 'coa_t2';
    const t_redaction__brouillon = 'coa_t3';
    const t_redaction__certif = 'coa_t4';
    const t_redaction__refus_certif = 'coa_t5';
    //endregion
 
    public $stateactivity = array(
        self::e_brouillon => "coa_planning",
        self::e_redaction => "coa_writing"
    );
 
    public $transitions = array(
        self::t_brouillon__redaction => array("nr" => true),
        self::t_brouillon__annule => array("nr" => true),
        self::t_redaction__brouillon => array("nr" => true),
        self::t_redaction__certif => array("nr" => true),
        self::t_redaction__refus_certif => array("nr" => true),
    );
 
    public $cycle = array(
        array("t" => self::t_brouillon__redaction, "e1" => self::e_brouillon, "e2" => self::e_redaction),
        array("t" => self::t_brouillon__annule, "e1" => self::e_brouillon, "e2" => self::e_annule),
        array("t" => self::t_redaction__brouillon, "e1" => self::e_redaction, "e2" => self::e_brouillon),
        array("t" => self::t_redaction__certif, "e1" => self::e_redaction, "e2" => self::e_certifie),
        array("t" => self::t_redaction__refus_certif, "e1" => self::e_redaction, "e2" => self::e_refus_certif),
    );
 
}

6.1.5 Traduction

Vous allez maintenant extraire les clefs permettant de traduire votre cycle de vie.

6.1.5.1 Ajout des clefs

Les clefs s'ajoutent à l'aide de commentaires dans le code. Pour ajouter une clef sur état, il faut ajouter le commentaire :

/* @transitionLabel _("state_name")/

Les annotations ainsi ajoutée permettent à l'outil d'extraction d'identifier les clefs.

En reprenant le fichier ci-dessus on obtient :

namespace COGIP;
 
class COGIP_AUDIT_AUDIT__WFL extends \Dcp\Family\WDoc
{
    public $attrPrefix = 'caaw';
    public $firstState = self::e_brouillon;
    public $viewlist = "none";
 
    //region MyAttributes-constants
    //endregion
 
    //region States
    /* @stateLabel _("coa_e1") */
    const e_brouillon = 'coa_e1';
    /* @stateLabel _("coa_e2") */
    const e_annule = 'coa_e2';
    /* @stateLabel _("coa_e3") */
    const e_redaction = 'coa_e3';
    /* @stateLabel _("coa_e4") */
    const e_certifie = 'coa_e4';
    /* @stateLabel _("coa_e5") */
    const e_refus_certif = 'coa_e5';
    //endregion
 
    //region Transitions
    /* @stateLabel _("coa_t1") */
    const t_brouillon__redaction = 'coa_t1';
    /* @stateLabel _("coa_t2") */
    const t_brouillon__annule = 'coa_t2';
    /* @stateLabel _("coa_t3") */
    const t_redaction__brouillon = 'coa_t3';
    /* @stateLabel _("coa_t4") */
    const t_redaction__certif = 'coa_t4';
    /* @stateLabel _("coa_t5") */
    const t_redaction__refus_certif = 'coa_t5';
    //endregion
 
    public $stateactivity = array(
        /* @stateLabel _("coa_planning") */
        self::e_brouillon => "coa_planning",
        /* @stateLabel _("coa_writing") */
        self::e_redaction => "coa_writing"
    );
 
    public $transitions = array(
        self::t_brouillon__redaction => array("nr" => true),
        self::t_brouillon__annule => array("nr" => true),
        self::t_redaction__brouillon => array("nr" => true),
        self::t_redaction__certif => array("nr" => true),
        self::t_redaction__refus_certif => array("nr" => true),
    );
 
    public $cycle = array(
        array("t" => self::t_brouillon__redaction, "e1" => self::e_brouillon, "e2" => self::e_redaction),
        array("t" => self::t_brouillon__annule, "e1" => self::e_brouillon, "e2" => self::e_annule),
        array("t" => self::t_redaction__brouillon, "e1" => self::e_redaction, "e2" => self::e_brouillon),
        array("t" => self::t_redaction__certif, "e1" => self::e_redaction, "e2" => self::e_certifie),
        array("t" => self::t_redaction__refus_certif, "e1" => self::e_redaction, "e2" => self::e_refus_certif),
    );
 
}

Vous pouvez trouver les fichiers complets dans les sources.

Ouvrez la console dans le répertoire contenant les sources et :

<devtool> extractPo -s .

Les clefs suivantes sont ajoutées dans le fichier locale/fr/LC_MESSAGES/src/COGIP_AUDIT_fr.po

msgid "coa_e1"
msgstr "Brouillon"
 
msgid "coa_e2"
msgstr "Annulé"
 
msgid "coa_e3"
msgstr "Planifié"
 
msgid "coa_e4"
msgstr "Certifié"
 
msgid "coa_e5"
msgstr "Refusé"
 
msgid "coa_planning"
msgstr "En planification"
 
msgid "coa_t1"
msgstr "Démarrer"
 
msgid "coa_t2"
msgstr "Annuler l'audit"
 
msgid "coa_t3"
msgstr "Renvoyer en planification"
 
msgid "coa_t4"
msgstr "Accorder la certification"
 
msgid "coa_t5"
msgstr "Refuser la certification"
 
msgid "coa_writing"
msgstr "En rédaction"

6.1.6 Inscription dans le paquet

Vous allez maintenant inscrire votre cycle de vie dans le paquet pour qu'il soit importé à l'installation et à la mise à jour.

Ajoutez la ligne suivante dans le info.xml à l'installation et à la mise à jour entre les lignes <process command="./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_AUDIT__STRUCT.csv"/> et <process command="./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_AUDIT__PARAM.csv"/>:

<process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_AUDIT__STRUCT.csv --csv-separator=&apos;;&apos; '/>
<process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_AUDIT__WFL.csv --csv-separator=&apos;;&apos; '/>
<process command='./wsh.php --api=importDocuments --file=./COGIP_AUDIT/COGIP_AUDIT_AUDIT__PARAM.csv --csv-separator=&apos;;&apos; '/>

6.1.7 Génération du document

6.1.7.1 Création

Vous allez maintenant générer le document de cycle de vie.

Pour cela générez le webinst et importez le.

Connectez vous à l'interface d'administration : http://<nomDeDomaine>/dynacase/admin.php.

Cliquez sur Gestion des documents > Explorateurs de documents et cliquez sur Création > Documents système en haut dans la partie de droite, l'interface de création de documents s'ouvre sur la partie droite.

Création workflow

Figure 104. Création workflow

Sélectionnez ensuite la famille COGIP_AUDIT_AUDIT__WFL à la place de "Masque de saisie".

Complétez le formulaire présenté avec les éléments suivants :

Création workflow

Figure 105. Création workflow

Cliquez ensuite sur Créer.

Si vous cliquez sur Voir le graphe, vous pouvez consulter une représentation graphique du cycle de vie :

Graphe cycle audit

Figure 106. Graphe cycle audit

6.1.7.2 Paquet webinst

6.1.7.2.1 Nom logique

Ajoutez un nom logique au cycle de vie, cliquez sur Autres > Propriétés et ajoutez le nom WDOC_COGIP_AUDIT_AUDIT__WFL.

6.1.7.2.2 Export

Ajoutez le cycle au porte-documents Autres > Ajouter au porte-documents (pensez à supprimer les éventuels autres documents au porte-documents), cliquez ensuite sur Outils > Exportation du dossier. La fenêtre d'exportation s'ouvre, cliquez sur Exporter.

Un fichier CSV vous est envoyé.

6.1.7.2.3 Enregistrement

Vous allez ajouter ce document dans le fichier de paramétrage de la famille Audit. Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_AUDIT__PARAM.csv ajoutez au début du fichier les trois lignes contenues dans le fichier d'exportation.

Pour finir, vous allez ajouter l'instruction qui associe le cycle de vie des audits à la famille audit.

Ajoutez une ligne juste avant le END les éléments suivant :

L'instruction WID est détaillée dans la documentation.

Le fichier COGIP_AUDIT_AUDIT__PARAM complété est accessible dans les sources.

6.1.8 Mise en place des modifications

Vous allez maintenant déployer vos modifications :

<devtool> deploy -s . --url http://admin:anakeen@<nomDeDomaine>/dynacase-control/ --port <port> --context dynacase

Vous pouvez ensuite consulter les modifications apportées via l'application http://<nomDeDomaine>/dynacase/.

6.1.9 Conclusion

Vous avez initié la structure d'un des cycles de vie et associé celui-ci à sa famille. Dans les prochains chapitres, vous verrez comment paramétrer, ajouter du code métier et profiler vos cycles de vie.

La réalisation de la structure du cycle des non-conformités n'est pas décrite dans ce chapitre, mais vous pouvez trouver les fichiers complet dans la solution du chapitre.

6.1.10 Voir aussi

6.2 Paramétrage du cycle de vie

Ce chapitre aborde le paramétrage du cycle de vie.

6.2.1 Objectifs

6.2.2 Cadre

Lors de la phase d'analyse, les points suivants ont été relevés :

6.2.3 Théorie

Le paramétrage d'un cycle de vie passe par plusieurs éléments distincts :

6.2.4 Paramétrage via le document

L'intégralité du paramétrage du document cycle de vie est détaillé dans la documentation.

6.2.4.1 Couleur

Vous allez commencer par spécifier les couleurs.

Connectez vous à l'interface d'administration : http://<nomDeDomaine>/dynacase/admin.php.

Allez dans l'application Gestion des documents>Explorateur de documents cliquez ensuite sur les cycles et sélectionnez le cycle Audit Audit.

Cycle de vie : Audit

Figure 107. Cycle de vie : Audit

Cliquez ensuite sur Modifier et sélectionnez l'onglet Étapes

Cycle de vie : Audit

Figure 108. Cycle de vie : Audit

Le document cycle de vie contient pour chaque étape et transition une série de champs qui permettent de spécifier son comportement. Vous allez modifier les entrées Couleur de chaque étape.

Même si l'attribution d'une couleur à chaque étape peut sembler accessoire, il reste important et facilite la prise en main par les utilisateurs de l'application que vous produisez.

Il est conseillé de suivre un code couleur cohérent et d'identifier les étapes similaires par des teintes similaires et de choisir des couleurs qui dans la culture des utilisateurs sont en cohérence avec la signification des étapes.

Pour votre cycle, il a été décidé en concertation avec les utilisateurs les couleurs suivantes :

Ce qui donne le cycle suivant :

Cycle de vie : Audit coloré

Figure 109. Cycle de vie : Audit coloré

Les couleurs des étapes se retrouvent dans les interfaces standard de Dynacase.

Interface standard : utilisation des couleurs d'étapes

Figure 110. Interface standard : utilisation des couleurs d'étapes

Attention, il faut exporter le document de cycle de vie et mettre à jour sa définition dans le fichier COGIP_AUDIT/COGIP_AUDIT_AUDIT__PARAM.csv pour que ce paramétrage soit valide en dehors du contexte de développement.

Vous pouvez trouver le document complété dans les sources.

6.2.4.2 Les mails

Ouvrez le document de cycle de vie en modification.

Dans votre spécification, il est indiqué que le mail doit être envoyé lors du démarrage de l'audit.

Sélectionnez l'onglet Transitions et cliquez le + à droite de Modèle de courriel Démarrer.

Ajout de mail : interface

Figure 111. Ajout de mail : interface

Une fenêtre d'édition de mail pré-paramétrée s'ouvre alors :

Ajout de mail : modification

Figure 112. Ajout de mail : modification

Cette fenêtre contient des données provenant de son formulaire de création (Famille et Famille Cycle). Vous pouvez paramétrer vos documents pour avoir le même comportement à l'aide de l'option creation.

Complétez les champs suivants :

Bonjour,
 
L'audit [V_TITLE] va commencer le [V_CAA_DATE_DEBUT] et se terminer le [V_CAA_DATE_FIN].
 
Bien à vous,

Cliquez sur Sauvez.

Cliquez sur Autres > Propriétés et ajoutez le nom logique MAIL_DEMARRAGE.

Vous pouvez fermer la fenêtre de création et cliquez sur le bouton sauver du cycle de vie.

Une fois ce paramétrage fait lors du changement d'état en passant par la transition un mail est envoyé.

Il est aussi possible d'attacher des mails à une étape, dans ce cas le mail est envoyé à chaque passage dans l'étape, quelle que soit la transition utilisée pour parvenir dans cette étape.

Mail : exemple

Figure 113. Mail : exemple

Vous pouvez trouver le modèle de mail complété dans les sources.

6.2.4.3 Relance (timer)

Ouvrez le document de cycle de vie en modification.

Il existe plusieurs manière d'affecter les minuteurs, elles sont décrites dans la documentation.

Vous allez créer un minuteur simple, celui-ci est attaché au document lors du passage de la transition et détaché au prochain changement d'état.

Sélectionnez l'onglet Transitions et cliquez le + à droite de Minuteur Démarrer.

L'interface suivante est ouverte :

Minuteur création

Figure 114. Minuteur création

Remplissez les champs suivants :

6.2.4.3.1 Création du mail associé

Cliquez sur le + dans la colonne Modèle de mail pour initier le modèle de mail.

Remplissez les champs de la manière suivante :

Bonjour,
 
L'audit [V_TITLE] est en rédaction depuis 15 jours.
 
Bien à vous,

Et cliquez sur Créer. Ajoutez ensuite un nom logique Autres > Propriétés : MAIL_REDACTION_RELANCE.

Minuteur mail

Figure 115. Minuteur mail

Fermez ensuite la fenêtre.

Sélectionnez la fenêtre contenant le minuteur en cours de paramétrage.

Cliquez sur les ... dans la colonne Modèle de mail et sélectionnez le mail Relance rédaction..

Cliquez sur Créer, le document se ferme.

Cliquez sur Sauver.

Minuteur

Figure 116. Minuteur

Vous allez utiliser le minuteur pour effectuer une relance par mail, mais celui-ci permet aussi :

Les différentes options pour paramétrer les règles de relance sont décrites dans la documentation.

6.2.4.3.2 Nom logique

Cliquez sur le lien Minuteur démarrer puis sur Autres > Propriétés et donnez le nom suivant MINUTEUR_DEMARRER.

Vous pouvez suivre les différents minuteurs en activité grâce à l'interface de suivi qui est dans l'admin Gestion des documents > Gestion des minuteurs.

6.2.4.4 Export du paramétrage

Vous allez maintenant exporter le paramétrage que vous avez mis en place. Vous avez plusieurs manières de faire cette action, soit :

Vous allez exporter l'ensemble des documents en une seule fois.

Connectez vous à l'interface d'administration : http://<nomDeDomaine>/dynacase/admin.php.

Ouvrez la Gestion des documents > Accès aux documents systèmes, sélectionnez la famille Audit.

Famille Audit

Figure 117. Famille Audit

Cliquez sur Autres > Ajoutez au porte-documents, videz les documents non utiles du porte-documents, puis cliquez sur Outils > Exportation du dossier.

Sélectionnez Profil Avec les profils et cliquez sur Exporter.

Famille Audit

Figure 118. Famille Audit

Le fichier CSV qui vous est envoyé contient une partie du paramétrage de la famille, ce qui inclut le paramétrage du cycle de vie.

Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_AUDIT__PARAM.csv.

Supprimez les documents que vous avez déjà dans le fichier de paramétrage, soit les :

Ajoutez les nouveaux documents au début du fichier __PARAM.csv, soit :

Famille Audit

Figure 119. Famille Audit

Vous pouvez trouver le modèle de mail complété dans les sources.

6.2.5 Paramétrage via le code

L'intégralité du paramétrage du cycle de vie via le code est détaillé dans la documentation.

6.2.5.1 Contrôle au changement d'état

Les contrôle au changement d'état se font lors des transitions, il existe quatre hook de transition utilisés pour :

6.2.5.1.1 m0 (pré-condition)

Vous allez utiliser le m0 pour vérifier que les fiches de non-conformités associées à l'audit sont bien toutes closes avant d'accorder ou de refuser la certification.

6.2.5.1.1.1 Définition de la fonction

Attention : Pour fonctionner cette méthode nécessite la présence du cycle de vie des FNC, que vous pouvez retrouver dans les sources complétées du chapitre précédent.

Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_AUDIT__WFL.php et ajoutez la fonction suivante :

public function checkAssociatedFNC()
{
    //Search in the FNC
    $searchDoc = new \SearchDoc("", \Dcp\Family\Cogip_audit_fnc::familyName);
    //If you find one FNC it's enough (speed the search)
    $searchDoc->setSlice(1);
    $searchDoc->addFilter("%s = '%d'", \Dcp\AttributeIdentifiers\Cogip_audit_fnc::caf_audit, $this->doc->getPropertyValue("initid"));
    $searchDoc->addFilter("state <> '%s'", COGIP_AUDIT_FNC__WFL::e_clos);
    if ($searchDoc->onlyCount() > 0) {
        return _("coa:You have to close all FNC before change state");
    }
    return "";
}

Cette fonction effectue une recherche sur les FNC, elle a les spécificités suivantes :

Vous pouvez trouver le fichier complété dans les sources.

6.2.5.1.1.2 Enregistrement de la fonction

Modifiez le tableau de déclaration des transitions :

public $transitions = array(
    self::t_brouillon__redaction => array("nr" => true),
    self::t_brouillon__annule => array("nr" => true),
    self::t_redaction__brouillon => array("nr" => true),
    self::t_redaction__certif => array("nr" => true, "m0" => "checkAssociatedFNC"),
    self::t_redaction__refus_certif => array("nr" => true, "m0" => "checkAssociatedFNC"),
);

Vous avez déclaré deux hooks de m0 qui seront déclenchés lors de l'affichage de la liste des états.

m0

Figure 120. m0

Dans l'exemple ci-dessus la transition est refusée et au survol un message est affiché à l'utilisateur.

Vous pouvez trouver le fichier complété dans les sources.

6.2.5.2 Question au changement d'état (ask)

Vous allez maintenant mettre en place le mécanisme de ask. Il permet de poser un ensemble de question via un petit formulaire lors d'un changement d'état.

6.2.5.2.1 Déclaration du ask

Les ask se composent de deux éléments :

Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_AUDIT__WFL.csv et ajoutez les lignes suivantes :

Déclaration _ask_

Figure 121. Déclaration _ask_

Vous pouvez trouver le fichier complété dans les sources.

Vous avez déclaré deux paramètres, ceux-ci peuvent être utilisés comme ask. Vous allez mettre à jour la liste des transitions :

    public $transitions = array(
        self::t_brouillon__redaction => array(
            "nr" => true
        ),
        self::t_brouillon__annule => array(
            "nr" => true,
            "ask" => array("caaw_raison")
        ),
        self::t_redaction__brouillon => array(
            "nr" => true
        ),
        self::t_redaction__certif => array(
            "nr" => true,
            "m0" => "checkAssociatedFNC"
        ),
        self::t_redaction__refus_certif => array(
            "nr" => true,
            "m0" => "checkAssociatedFNC"
        )
    );

Vous avez ajouté un array sur la transition self::t_brouillon__annule, celui-ci est référencé par la clef ask et contient la liste des ask qui vont être présentés à l'utilisateur.

Lors du passage de la transition, le ask est présenté sous la forme d'une fenêtre posant la question :

Ask : démonstration

Figure 122. Ask : démonstration

Vous pouvez trouver le fichier complété dans les sources.

6.2.5.2.2 Utilisation du ASK

Les valeurs de retour du ASK peuvent être utilisées au m1, m2 et m3 et dans les modèles de mail.

Dans votre cas, vous allez utiliser le retour du ask pour le stocker dans l'historique du document.

Ajoutez la fonction suivante :

public function handleRaison()
{
    $this->doc->addHistoryEntry($this->getRawValue(\Dcp\AttributeIdentifiers\Cogip_audit_audit__wfl::caaw_raison));
}

et modifiez la liste des transitions :

public $transitions = array(
    self::t_brouillon__redaction => array("nr" => true),
    self::t_brouillon__annule => array("nr" => true,
        "ask" => array(\Dcp\AttributeIdentifiers\Cogip_audit_audit__wfl::caaw_raison),
        "m2" => "handleRaison"
    ),
    self::t_redaction__brouillon => array("nr" => true),
    self::t_redaction__certif => array("nr" => true, "m0" => "checkAssociatedFNC"),
    self::t_redaction__refus_certif => array("nr" => true, "m0" => "checkAssociatedFNC"),
);

Vous avez ajouté une fonction qui utilise et enregistre dans l'historique la valeur du ask et ensuite vous avez enregistré cette fonction au m2 de la transition self::t_brouillon__annule.

Ask : historique

Figure 123. Ask : historique

Une fois la transition de retour franchie, si l'utilisateur clique sur le menu historique, l'interface ci-dessus est présentée.

Vous pouvez trouver le fichier complété dans les sources.

6.2.6 Mise à jour des contrôle de cohérence

Vous allez maintenant modifier le contrôle de cohérence que vous avez mis en place sur les dates pour que le contrôle ne se déclenche que lorsque la fiche est à l'état Brouillon.

Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT_AUDIT__CLASS.php et modifiez la fonction checkDate pour qu'elle soit identique à :

/**
 * Check if the end date is in the past
 *
 * @return string
 */
public function checkEndDate()
{
    $err = "";
    $date = $this->getAttributeValue(MyAttributes::caa_date_fin);
    if (!empty($date)
        && $this->getPropertyValue("state") === COGIP_AUDIT_AUDIT__WFL::e_brouillon
        && $this->getAttributeValue(MyAttributes::caa_date_fin) < new \DateTime()) {
        $err = ___("The end date of the audit is in the past", "COGIP_AUDIT:AUDIT");
    }
    return $err;
}

Vous avez ajouté une condition pour que la contrainte ne se déclenche qu'à l'état Brouillon.

Vous pouvez trouver le fichier complété dans les sources.

6.2.7 Mise en place des modifications

Vous allez maintenant déployer vos modifications :

<devtool> deploy -s . --url http://admin:anakeen@<nomDeDomaine>/dynacase-control/ --port <port> --context dynacase

Vous pouvez ensuite consulter les modifications apportées via l'application http://<nomDeDomaine>/dynacase/.

6.2.8 Conclusion

Vous connaissez les principales manipulations que vous pouvez effectuer avec un cycle de vie, que ça soit à l'aide du document cycle de vie ou de la classe de la famille cycle de vie.

Ces paramétrages permettent de créer simplement des cycles complets et riches et de guider les utilisateurs.

6.2.9 Voir aussi

6.3 Sécurité des cycles de vie

6.3.1 Objectifs

6.3.2 Cadre

Lors de la phase d'analyse, les points suivants ont été relevés :

6.3.3 Théorie

Le paramétrage des droits associés à un cycle de vie sont de deux natures.

6.3.4 Profilage du cycle

Vous allez commencer par profiler le document cycle de vie, ce qui va vous permettre de définir quel type d'utilisateur peut effectuer quelle transition.

Connectez vous à l'interface d'administration : http://<nomDeDomaine>/dynacase/admin.php.

Allez dans l'application Gestion des documents>Explorateur de documents, cliquez ensuite sur les cycles et sélectionnez le cycle Audit Audit.

Cliquez sur Autres>Sécurité>Profil dédié. La page se recharge, cliquez maintenant sur Autres>Sécurité>Accessibilités....

L'interface suivante vous est présentée :

Cycle de vie : Audit : Profil

Figure 124. Cycle de vie : Audit : Profil

Les deux premières et la dernière colonnes sont dédiées aux droits associés au document cycle (qui peut voir, modifier et voir les droits du document cycle).

Le code couleur des types de droits peut être consulté en cliquant sur le bouton Légende.

Les entrées en jaune et en orange sont des champs provenant du document associé au cycle de vie.

L'affectation de droit est décrite dans le chapitre sécurité des documents.

Modifiez la matrice comme ci-dessous :

Cycle de vie : Audit : Profil

Figure 125. Cycle de vie : Audit : Profil

Et cliquez sur Modifier les privilèges.

Votre cycle est maintenant profilé. La liste des transitions présentée sur le document tient compte du profil de la personne connectée.

6.3.5 Profil des étapes

Vous allez maintenant ajouter des profils de document au différentes étapes.

6.3.5.1 Création des profils

Vous allez commencer par créer les profils.

6.3.5.1.1 Profil : Brouillon

Cliquez sur Création > Profil. Remplissez les valeurs suivantes :

Cliquez sur Créer.

Cliquez sur Activer. La page se recharge. Cliquez sur Accessibilités

Remplissez la matrice comme ci-dessous :

Profil Audit : Brouillon

Figure 126. Profil Audit : Brouillon

Cliquez sur Modifier les privilèges.

Ajoutez le nom logique Autres > Propriétés : PDOC_AUDIT_BROUILLON.

6.3.5.1.2 Profil : Planifié

Cliquez sur Création > Profil. Remplissez les valeurs suivantes :

Cliquez sur Créer.

Cliquez sur Activer. La page se recharge. Cliquez sur Accessibilités.

Remplissez la matrice comme ci-dessous :

Profil Audit : Planifié

Figure 127. Profil Audit : Planifié

Cliquez sur Modifier les privilèges.

Ajoutez le nom logique Autres > Propriétés : PDOC_AUDIT_PLANIFIE.

6.3.5.1.3 Profil : Désactivé

Cliquez sur Création > Profil. Remplissez les valeurs suivantes :

Cliquez sur Créer.

Cliquez sur Activer. La page se recharge. Cliquez sur Accessibilités.

Remplissez la matrice comme ci-dessous :

Profil Audit : Désactivé

Figure 128. Profil Audit : Désactivé

Cliquez sur Modifier les privilèges.

Ajoutez le nom logique Autres > Propriétés : PDOC_AUDIT_DISABLED.

Un seul profil est créé et utilisé pour tous les états où le document est désactivé (Annulé, Certifié, Refusé).

6.3.5.2 Affectation des profils

Allez dans l'application Gestion des documents>Explorateur de documents cliquez ensuite sur les cycles et sélectionnez le cycle Audit Audit.

Cliquez sur Modifier, sélectionnez l'onglet Étapes pour chaque onglet d'étape associé le profil :

Vous obtenez le document suivant :

Cycle de vie

Figure 129. Cycle de vie

Attention les profils ne sont affectés au document qu'à l'arrivée dans l'étape. Si des documents sont déjà dans cette étape alors le profil n'est pas affecté.

6.3.6 Exportation

Utilisez la procédure décrite dans le chapitre précédent.

Vous devez obtenir un fichier ./COGIP_AUDIT/COGIP_AUDIT_AUDIT__PARAM.csv semblable à :

Export cycle de vie avec sécurité

Figure 130. Export cycle de vie avec sécurité

Vous pouvez trouver le fichier complété dans les sources.

6.3.7 Mise en place des modifications

Vous allez maintenant déployer vos modifications :

<devtool> deploy -s . --url http://admin:anakeen@<nomDeDomaine>/dynacase-control/ --port <port> --context dynacase

Vous pouvez ensuite consulter les modifications apportées via l'application http://<nomDeDomaine>/dynacase/.

6.3.8 Conclusion

Vous savez maintenant paramétrer les éléments de sécurité associés au cycle de vie. Vous pouvez définir qui peut effectuer quelle transition et qui peut voir/modifier/supprimer les documents suivant l'étape.

6.3.9 Voir aussi

Chapitre 7 Action

Une action permet d'étendre les fonctionnalités de Dynacase. Vous pouvez :

Le système d'action est composé de trois éléments :

Les actions peuvent être appelée :

7.1 Action

Vous allez écrire une série d'action réalisant une nouvelle interface de consultation des documents.

7.1.1 Objectifs

7.1.2 Cadre

Vos utilisateurs sont conquis par les formulaires que vous avez réalisés dans les chapitres précédents. Toutefois, ils trouvent que l'interface d'accès par défaut pourrait être plus design et vous demandent de faire une nouvelle proposition.

La COGIP étant une entreprise moderne votre parc de machine est à jour et tous les utilisateurs ont des navigateurs à jour (IE, chrome et firefox dernière version). Vous allez donc construire une nouvelle interface qui ne supporte que les navigateurs les plus récents, mais qui est plus design.

Vous allez mettre en place deux actions :

Pour vous simplifier la tâche, vous avez décidé d'utiliser deux librairies externes :

7.1.3 Théorie

Les actions impliquent trois concepts :

Une fois l'action déclarée, elle peut être appelée de la manière suivante :

<context>?app=<app_name>&action=<action_name>&param1=value1&....

7.1.4 Ajout des librairies externes

Vous allez ajouter les librairies dans le paquet. Vous pouvez trouver les fichiers ayant servi à la réalisation du tutoriel dans les sources.

Vous devez obtenir une arborescence similaire à :

COGIP_AUDIT/libs
├── css
│   ├── foundation.css
│   └── normalize.css
└── js
    ├── foundation.min.js
    └── jquery.js

7.1.5 Ajout d'une ACL

Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT.app et modifiez le tableau $app_acl pour qu'il contienne les entrées suivantes :

$app_acl = array(
    array(
        "name" => "BASIC",
        "description" => N_("coa:basic access"),
        "group_default" => "Y"
    )
);

L'ACL est composée :

7.1.6 Action : liste de document

Vous allez commencer par l'action liste de document. Cette action affiche une liste d'audits et un entête.

Elle est conçue pour retourner un fragment de HTML qui doit être inclut dans une page entière.

Ce fragment va (une fois intégré dans la page complète) aura le rendu suivant :

Liste documents : rendu final

Figure 131. Liste documents : rendu final

7.1.6.1 Enregistrement de l'action

Ouvrez le fichier ./COGIP_AUDIT/COGIP_AUDIT.app et modifiez le tableau $action_desc pour qu'il contienne les entrées suivantes :

$action_desc = array(
    array(
        "name" => "DOCUMENT_LIST",
        "short_name" => N_("coa:document list"),
        "script" => "action.document_list.php",
        "function" => "document_list",
        "layout" => "document_list.html",
        "acl" => "BASIC"
    )
);

La nouvelle action comporte les éléments suivants :

"name" => "DOCUMENT_LIST"
Le nom logique de l'application. Il est utilisé dans les URL d'appel de l'action.
"short_name" => N_("coa:document list")
la description de l'application. Elle est utilisée dans les interfaces pour faire référence à l'action. Elle est traduite.
"script" => "action.document_list.php"
Le fichier PHP qui va contenir le code de l'action.

"function" => "document_list" - La fonctionphp qui est appelée lors du lancement de l'action. Cette fonction doit être contenue dans le fichier script.

"layout" => "document_list.html"
Le template de l'action.
"acl" => "BASIC"
Le nom d'une ACL que les utilisateurs voulant exécuter l'action doivent avoir.

Toutes les entrées du tableau $action_desc sont décrites dans la documentation.

Vous pouvez trouver le fichier complété dans les sources.

7.1.6.1.1 Ajout des fichiers

Vous allez maintenant ajouter les fichiers que vous avez spécifié dans le chapitre précédent.

7.1.6.1.1.1 Code

Ajoutez le fichier ./COGIP_AUDIT/action.document_list.php, ce fichier doit contenir le code suivant :

 
<?php
 
function document_list(Action &$action) {
 
    $usage = new \ActionUsage($action);
 
    $type = $usage->addOptionalParameter("type", "type", array("ALL", "OPEN", "CLOSE"), "ALL");
    $offset = intval($usage->addOptionalParameter("offset", "offset", array(), 0));
    $slice = intval($usage->addOptionalParameter("slice", "slice", array(), 5));
    $keyWord = $usage->addOptionalParameter("keyword", "keyword", array(), false);
 
    try {
        $usage->verify(true);
 
        $inProgressStates = array(\Cogip\COGIP_AUDIT_AUDIT__WFL::e_brouillon,
            \Cogip\COGIP_AUDIT_AUDIT__WFL::e_redaction
        );
 
        $inProgressStates = array_map(function ($value) {
            return "'$value'";
        }, $inProgressStates);
 
        $inProgressStates = implode(",", $inProgressStates);
 
        $audits = array();
        $searchDoc = new \SearchDoc("", \Dcp\Family\Cogip_audit_audit::familyName);
        $searchDoc->setObjectReturn();
        if ($keyWord) {
            $searchDoc->addFilter("title ~* '%s'", $keyWord);
        }
        if ($type === "OPEN") {
            $searchDoc->addFilter("state in ($inProgressStates)");
        } elseif ($type === "CLOSE") {
            $searchDoc->addFilter("state not in ($inProgressStates)");
        }
        $searchDoc->setStart($offset*$slice);
        $searchDoc->setSlice($slice+1);
        $nbResult = $searchDoc->count();
        foreach ($searchDoc->getDocumentList() as $currentAudit) {
            /* @var \Dcp\Family\Cogip_audit_audit $currentAudit */
            $audits[] = array(
                "TITLE" => $currentAudit->getTitle(),
                "INITID" => $currentAudit->getPropertyValue("initid"),
                "URL" => sprintf(
                    "?app=FDL&action=OPENDOC&id=%d&mode=view&latest=Y",
                    $currentAudit->getPropertyValue("initid")
                ),
                "STATE" => $currentAudit->getStatelabel(),
                "COLOR" => $currentAudit->getStateColor()
            );
        }
        $isLast = ($nbResult < $slice + 1);
        if (!$isLast) {
            array_pop($audits);
        }
 
        $action->lay->eSet("FIRST", ($slice === 0));
        $action->lay->eSet("LAST", $isLast);
        $action->lay->eSet("OFFSET", $offset);
        $action->lay->eSet("KEYWORD", $keyWord);
        $action->lay->eSet("TYPE_ALL", $type === "ALL");
        $action->lay->eSet("TYPE_OPEN", $type === "OPEN");
        $action->lay->eSet("TYPE_CLOSE", $type === "CLOSE");
        $action->lay->eSetBlockData("AUDITS", $audits);
    } catch(Exception $exception) {
        header($exception->getMessage(), true, 500);
    }
 
}

Le code ci-dessus a les spécificités suivantes :

Vous avez pu remarquer que la recherche demande un document de plus que nécessaire, cela permet de savoir si le bouton suivant du tourne-page doit être activé ou pas.

L'affectation du layout au moteur de template et le rendu du template sont automatiques. Si toutefois, vous n'aviez pas de template à associé à l'action, vous devez le préciser avec le code suivant en fin d'action (ici pour du retour en JSON) :

$action->lay->template = json_encode($return);
$action->lay->noparse = true;
header('Content-type: application/json');

Vous pouvez trouver le fichier complété dans les sources.

7.1.6.1.1.2 Template

Ajoutez le fichier ./COGIP_AUDIT/Layout/document_list.html :

<form class="js-list-form">
    <div class="row collapse">
        <div class="small-12 columns">
            <input name="keyword" type="text" placeholder="[TEXT:coa:titre]" value="[KEYWORD]">
        </div>
        <div class="small-2 columns">
 
        </div>
    </div>
    <div class="row collapse">
        <div class="large-12 columns">
            <label class="css-form-label">[TEXT:coa:State]&nbsp;:
                <select class="css-form-select" name="type">
                    <option value="ALL" [IF TYPE_ALL]selected[ENDIF TYPE_ALL]>[TEXT:coa:All]</option>
                    <option value="OPEN" [IF TYPE_OPEN]selected[ENDIF TYPE_OPEN]>[TEXT:coa:In progress]</option>
                    <option value="CLOSE" [IF TYPE_CLOSE]selected[ENDIF TYPE_CLOSE]>[TEXT:coa:Closed]</option>
                </select>
            </label>
        </div>
    </div>
    <input name="offset" type="hidden" value="[OFFSET]"/>
    <input type="submit" value="[TEXT:coa:search]" class="button postfix js-button-list-form">
</form>
<div class="pagination-centered">
    <ul class="pagination">
        <li class="arrow [IFNOT FIRST]unavailable[ENDIF FIRST] js-previous"><a href="#">&laquo;</a></li>
        <li class="current"><a href="">[OFFSET]</a></li>
        <li class="arrow [IFNOT LAST]unavailable[ENDIF LAST] js-next"><a href="#">&raquo;</a></li>
    </ul>
 </div>
<ul class="off-canvas-list js-docs-list">
[BLOCK AUDITS]
<li title="[STATE]">
    <a class="js-doc-link" href="[URL]" data-initid="[INITID]">[TITLE]
        <span class="right" style="background-color : [COLOR];">&nbsp;</span>
    </a>
</li>
[ENDBLOCK AUDITS]
</ul>

Le template fonctionne avec l'action ci-dessus et utilise les mots clefs du moteur de template interne de Dynacase. Vous pouvez trouver la liste des mots clefs sur la documentation.

Le template ci-dessus a les spécificités suivantes :

Vous pouvez trouver le fichier complété dans les sources.

7.1.7 Action : principale

Vous allez maintenant mettre en place l'action principale de votre interface.

Cette action principale présente le layout global de l'application. Elle ne contiendra pas de code PHP et fonctionnera principalement via du code JavaScript.

7.1.7.1 Enregistrement de l'action

Ajoutez cette entrée au tableau $action_desc :

array(
    "name" => "MAIN",
    "short_name" => N_("coa:main interface"),
    "script" => "action.main.php",
    "function" => "main",
    "layout" => "main.html",
    "root" => "Y",
    "acl" => "BASIC"
),

La définition est similaire à l'action DOCUMENT_LIST à une différence près : cette action est root. C'est donc l'action par défaut de l'application et elle peut-être appelée directement avec l'url <context>/?app=COGIP_AUDIT

Vous pouvez trouver le fichier complété dans les sources.

7.1.7.1.1 Ajout des fichiers

Vous allez maintenant ajouter les fichiers que vous avez spécifié dans le chapitre précédent et les assets (js, css).

7.1.7.1.1.1 Code

Ajoutez le fichier ./COGIP_AUDIT/action.main.php, ce fichier doit contenir le code suivant :

<?php
function main(Action &$action) {
 
}

Il n'y a pas de code dans la fonction, car le template associé est statique.

7.1.7.1.1.2 Template

Ajoutez le fichier ./COGIP_AUDIT/Layout/main.html :

<!doctype html>
<!--[if IE 9]><html class="lt-ie10" lang="fr"><![endif]-->
<html lang="fr">
<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>[TEXT:coa:audits]</title>
    <link rel="icon" href="[DYNACASE_FAVICO]"/>
    <link rel="shortcut icon" href="[DYNACASE_FAVICO]"/>
    <link rel="stylesheet" href="COGIP_AUDIT/libs/css/normalize.css"/>
    <link rel="stylesheet" href="COGIP_AUDIT/libs/css/foundation.css"/>
    <link rel="stylesheet" href="COGIP_AUDIT/libs/css/main.css"/>
</head>
<body>
<div class="fixed css-header">
    <nav class="top-bar" data-topbar data-options="sticky_on: large">
        <ul class="title-area">
            <li class="name">
                <h1><a href="#" class="js-audits">[TEXT:coa:audits]</a></h1>
            </li>
        </ul>
        <section class="top-bar-section">
            <ul class="right">
                <li class="has-form show-for-large-up">
                    <a href="#" class="button js-disconnect">
                        [TEXT:coa:disconnect]
                    </a>
                </li>
            </ul>
         </section>
    </nav>
</div>
<div class="css-main js-main">
    <div class="off-canvas-wrap docs-wrap" data-offcanvas="">
        <div class="inner-wrap">
            <nav class="tab-bar css-main-tab-bar">
                <section class="left-small">
                    <a class="left-off-canvas-toggle menu-icon js-document-menu"><span></span></a>
                </section>
 
                <section class="middle tab-bar-section">
                    <h1 class="title js-current-frame-title">[TEXT:coa:Select an audit]</h1>
                </section>
            </nav>
 
            <aside class="left-off-canvas-menu">
                <a href="?app=FDL&action=OPENDOC&famid=COGIP_AUDIT_AUDIT"
                   class="button small css-create-button js-create-button">
                    [TEXT:coa:Create audit]
                </a>
                <span class="js-document-list"></span>
            </aside>
 
            <section class="main-section css-doc-section">
                <iframe id="main-doc" name="main-doc" src="" class="css-main-doc"></iframe>
            </section>
 
            <a class="exit-off-canvas"></a>
 
        </div>
    </div>
</div>
<form style="display:none;" action="?app=AUTHENT&action=LOGOUT" method="POST" name="disconnect"
      id="disconnect">
    <input type="hidden" name="SeenBefore" value="1">
    <input type="hidden" name="logout" value="Y">
</form>
<script type="text/javascript" src="COGIP_AUDIT/libs/js/jquery.js"></script>
<script type="text/javascript" src="COGIP_AUDIT/libs/js/foundation.min.js"></script>
<script type="text/javascript" src="COGIP_AUDIT/libs/js/main.js"></script>
</body>
</html>

Le template ci-dessus contient les spécificités suivantes :

Vous pouvez trouver le fichier complété dans les sources.

7.1.7.1.1.3 Assets

Il y a deux fichiers d'asset (un fichier CSS et un fichier JS).

CSS

Ajoutez le fichier ./COGIP_AUDIT/libs/css/main.css :

.css-main-doc {
    width: 100%;
    border: none;
}
 
.css-doc-section {
    height: 100%;
}
 
.css-create-button {
    width : 100%;
}
 
.css-header {
    border-bottom: 1px solid #000000;
}
 
.css-form-label {
    color : white;
}
 
.css-form-select {
    color: #000000;
}

La CSS ci-dessus reste très simple et apporte principalement de la mise en forme pour l'iframe centrale et pour le formulaire des listes de documents.

Vous pouvez trouver le fichier complété dans les sources.

JavaScript

Ajoutez le fichier ./COGIP_AUDIT/libs/js/main.js :

!function () {
    $(window).ready(function () {
        var $mainDoc = $("#main-doc"),
            $mainSection = $(".css-doc-section"),
            $mainTabBar = $(".css-main-tab-bar"),
            setCurrentDocument, getDocumentList;
        /**********************************************************************************************************/
        /** Utilities                                                                                            **/
        /**********************************************************************************************************/
        /**
         * Set the current document in the main iframe
         * @param hash
         */
        setCurrentDocument = function (hash) {
            var doc = $mainDoc[0].contentDocument || $mainDoc[0].contentWindow.document,
                currentInitid = $(doc).find("[name=document-initid]").attr("content");
            if (hash && currentInitid !== hash) {
                $mainDoc.attr(
                    "src",
                    "?app=FDL&action=OPENDOC&mode=view&latest=Y&id=" + encodeURIComponent(hash)
                );
            }
        };
        /**
         * Get the document list with a post XHR
         */
        getDocumentList = function () {
            var data = {}, $form = $(".js-list-form");
            if ($form.length > 0) {
                data = $form.serialize();
            }
            $.post("?app=COGIP_AUDIT&action=DOCUMENT_LIST", data)
                .done(function (data) {
                    var $data = $(data);
                    $data.find(".js-list-form").on("submit", function (event) {
                        event.preventDefault();
                        getDocumentList();
                    });
                    $(".js-document-list").html($data);
                })
                .fail(function (event) {
                    console.log("Unable to get document list");
                    console.log(event);
                });
        };
        /**********************************************************************************************************/
        /** Events                                                                                               **/
        /**********************************************************************************************************/
        /**
         * Add the create document event
         */
        $(".js-create-button").on("click", function (event) {
            event.preventDefault();
            if (event.currentTarget.href) {
                $("#main-doc").attr("src", event.currentTarget.href);
            }
        });
        /**
         * Listen the load event of the main iframe, update the docTitle
         */
        $mainDoc.on("load", function () {
            var doc = $mainDoc[0].contentDocument || $mainDoc[0].contentWindow.document,
                title = doc.title || "",
                initid = $(doc).find("[name=document-initid]").attr("content");
            $(".js-current-frame-title").text(title);
        });
        /**
         * Add a listener for the upper left audit button
         */
        $(".js-audits").on("click", function (event) {
            event.preventDefault();
            $(".js-document-menu").trigger("click");
        });
        /**
         * Add a listener for the disconnect button
         * Send the hidden disconnect form when there is a click on the button
         */
        $(".js-disconnect").on("click", function (event) {
            event.preventDefault();
            $("#disconnect").submit();
        });
        /**
         * Resize main element to take all the space
         */
        $(function () {
            var timer;
            $(window).resize(function () {
                clearTimeout(timer);
                timer = setTimeout(function () {
                    var offset = $(".js-main").offset(), size = $(window).height() - offset.top;
                    $('.inner-wrap').css("min-height", size + "px");
                    size = size - $mainTabBar.outerHeight();
                    $mainSection.height(size);
                    $mainDoc.height($mainSection.innerHeight() - 5);
                }, 40);
            }).resize();
        });
        /**
         * Handle events on the audit list
         */
        $(".js-document-list").on("click", ".js-doc-link",function (event) {
            event.preventDefault();
            if (event.currentTarget.href) {
                $("#main-doc").attr("src", event.currentTarget.href);
            }
        }).on("click", ".js-button-list-form",function (event) {
            event.preventDefault();
            getDocumentList();
        }).on("click", ".js-previous",function (event) {
            var $previous = $(event.currentTarget), $offset;
            event.preventDefault();
            if (!$previous.hasClass("unavailable")) {
                $offset = $("[name=offset]");
                $offset.val($offset.val() - 1);
                getDocumentList();
            }
        }).on("click", ".js-next", function (event) {
            var $previous = $(event.currentTarget), $offset;
            event.preventDefault();
            if (!$previous.hasClass("unavailable")) {
                $offset = $("[name=offset]");
                $offset.val($offset.val() -   1);
                getDocumentList();
            }
        });
        /**********************************************************************************************************/
        /** Initialisation                                                                                       **/
        /**********************************************************************************************************/
        /**
         * Use the hash to open a selected document
         */
        if (window.location.hash) {
            var hash = window.location.hash.slice(1);
            setCurrentDocument(hash);
        } else {
            $(".js-document-menu").trigger("click");
        }
 
        //Get the initial document list
        getDocumentList();
        //Init the foundation framework
        $(document).foundation();
 
    });
}();

Le code JavaScript est lui aussi assez simple, il est structuré en plusieurs parties :

Une fois l'ensemble des fichiers initiés et le contexte mis à jour. Rendez vous à l'adresse <context>/?app=COGIP_AUDIT, vous obtenez l'interface suivante :

Interface : rendu final

Figure 132. Interface : rendu final

Vous pouvez trouver le fichier complété dans les sources.

7.1.8 Enregistrement de l'interface

Vous allez finir ce chapitre en enregistrant votre nouvelle action principale en tant qu'action par défaut, ce qui permet aux utilisateurs d'arriver directement sur l'action.

Pour ce faire, ouvrez le fichier info.xml et ajoutez la ligne :

<process command="./wsh.php --api=setApplicationParameter --appname=CORE --param=CORE_START_APP --value=COGIP_AUDIT"/>

à la fin du process d'installation et de mise à jour.

Le paramètre CORE_START_APP permet de spécifier l'application qui doit être lancée par défaut.

Le script setApplicationParameter permet de définir la valeur d'un paramètre applicatif lors l'installation d'un paquet.

Vous pouvez trouver le fichier complété dans les sources.

7.1.9 Mise en place des modifications

Vous allez maintenant déployer vos modifications :

<devtool> deploy -s . --url http://admin:anakeen@<nomDeDomaine>/dynacase-control/ --port <port> --context dynacase

Vous pouvez ensuite consulter les modifications apportées via l'application http://<nomDeDomaine>/dynacase/.

7.1.10 Conclusion

Vous avez expérimenté le système d'application/action. Vous pouvez simplement et rapidement étendre les fonctionnalités de la plateforme grâce à ce système et notamment créer des interfaces dédiées aux besoins de vos utilisateurs.

Merci d'avoir complété ce tutoriel jusqu'à cette dernière étape. Nous vous souhaitons bonne chance et bon courage dans le développement de vos applications.

Vous pouvez trouver les sources entièrement complétés sur github.

Chapitre 8 Annexe

Ce chapitre contient différent éléments de références qui sont applicables pour tous les tutoriels.

8.1 CSV

Le format standard de CSV de Dynacase est :

Ce format est valide pour l'import et pour l'export des documents et des familles avec l'action importDocuments.

8.2 Conventions de nommage

Module :

├── API/
├── <APPLICATION>
│   ├── <APPLICATION>.app
│   ├── <APPLICATION>_init.php
│   ├── Familles/
│   ├── Images/
│   ├── Layout/
├── EXTERNALS/
├── locale/
├── STYLE/
├── info.xml

Avec les éléments suivants :

8.3 Script open office

Il existe un ensemble de scripts Libre Office / OpenOffice pour faciliter le développement d'une famille.

Vous pouvez le trouver ici.

Le script s'intègre en passant par le menu Macro sous partie Libre office basic.

Ajout d'un script

Figure 133. Ajout d'un script

Ensuite la fenêtre suivante s'ouvre :

Ajout d'un script

Figure 134. Ajout d'un script

Vous sélectionnez le module1 et le bouton éditer. L'écran suivant est affiché :

Ajout d'un script

Figure 135. Ajout d'un script

Vous copiez le contenu du fichier référencé ci-dessus à la place du script existant.

Vous pouvez ensuite ajouter les scripts en modifiant les menus : faites un clic droit sur la barre d'outils et sélectionnez l'option Personnaliser la barre d'outil.

Ce script intègre plusieurs macros :

setDefaultOption

Permet de remplir automatiquement les valeurs des colonnes - E (utilisé pour composer le titre), par défaut à N ; - F (affiché dans la fiche résumé), par défaut à N ; - I (visibilité), par défaut à W ; - O (options), avec des valeurs par défaut en fonction du type d'attribut : - htmltext : toolbar=Basic|toolbarexpand=no, - enum : bmenu=no|eunset=yes|system=yes, - array : vlabel=up, - longtext : editheight=4em.

Le script n'opère que sur les attributs pour lesquels cette colonne est vide.

autoNum

Permet de remplir automatiquement la colonne H (l'ordre d'affichage) des attributs Le script remplace l'ordre de tous les attributs, y compris ceux pour lesquels cette valeur est déjà définie. Il sépare

  • les attributs non structurants d'un pas de 10,
  • les tableaux d'un pas de 10,
  • les cadres d'un pas de 100,
  • les onglets d'un pas de 1000.

Dans certains cas, il peut être nécessaire de forcer l'ordre d'un attribut (par exemple, dans le cas d'un héritage, pour positionner un attribut entre 2 attributs de la famille parente). Cela peut se faire en indiquant la valeur souhaitée dans la colonne R. La numérotation automatique poursuivra alors à partir de cette nouvelle valeur.

setParent
Permet de remplir automatiquement la colonne C (l'attribut encadrant) des attributs. Le script n'opère que sur les attributs pour lesquels cette colonne est vide. Le script se base sur l'ordre des attributs pour effectuer cette opération (il utilise le dernier encadrant rencontré comme parent).

Vous pouvez voir ci-dessous un exemple d'utilisation de ces scripts :

Exemple de construction

Figure 136. Exemple de construction

8.4 Développement rapide

Vous avez sûrement remarqué que le déploiement systématique des sources via le webinst est une action consommatrice en temps. Vous pouvez lors des phases de développement passer outre pour déployer de manière unitaire les différents fichiers :

Attention, ce mode de fonctionnement est strictement à prohiber en production et à réserver uniquement au développement de votre application.

Liste des illustrations

Licence

Ce document est publié sous licence CC http://creativecommons.org/licenses/by-nc-sa/2.0/fr/

Vous êtes libres :

Selon les conditions suivantes :

Édition

Quick Start
© Anakeen, Anakeen Labs <labs@anakeen.com>
Module Dynacase Platform, version 3.2
Édition 6
Publié le 03/08/2018

Ce livre a été produit avec easybook 4.8, logiciel libre et open source développé par Javier Eguiluz à l'aide de différents composants Symfony.

Anakeen

Créé en 1998, Anakeen est un éditeur expert dans l'amélioration de la gestion des processus et de l'information avec pour objectif principal : valoriser les fonctions support en les libérant des tâches à faible valeur ajoutée. Le résultat opérationnel a toujours été recherché par toutes les entreprises et particulièrement aujourd'hui où le moindre détail peut faire la différence afin d'être ou de rester compétitif sur son marché. Pour chaque fonction support, être en situation de valoriser sa contribution au résultat global de l’entreprise est plus que jamais devenu une nécessité.

Impliqué depuis 1998 dans le logiciel libre, Anakeen est un acteur majeur de la gestion de l'information. Nos contributions pour l'utilisation des standards ouverts, la garantie de l'accès au code source et la grande diversité de nos partenaires vous assure pérennité et réversibilité.

L'ensemble du code PHP de Dynacase Platform est disponible sous licence Open Source, le modèle de données est documenté et public. Mais plus que ça, le code source est commenté dans l'objectif de faciliter sa compréhension pour la réutilisation ou la modification. Aussi toute la documentation concernant le produit est mise en ligne sur www.dynacase.org.

En choisissant un logiciel Open Source, vous faites le choix de la sécurité, car vous avez l'assurance de vérifier le fonctionnement du logiciel et la qualité du code.

Nos offres et services, nous permettent d'assurer le financement du développement produit mais aussi de contribuer chaque jour à l'adoption du business model Open Source.