• identifier sa distribution :

Ce wiki vous guide dans l'installation de dynacase sous Fedora Core, PDL, Debian ETCH, Ubuntu 7.04 et 8.04, Centos et LFS.
dynacase peut être utilisé depuis n'importe quel ordinateur disposant d'un navigateur web.

• APACHE, PHP et POSTGRE :

Installer dynacase requiert des notions sur APACHE, PHP et POSTGRE. De nombreux sites sur internet pour permettront d'approfondir vos connaissances sur ces sujets.
Les pages de ce wiki dédiées à l'installation de dynacase vous guideront dans l'installation, la configuration, le paramétrage et la sauvegarde de ces composants.

• créer un répertoire de travail et envoyer les fichiers depuis ce répertoire :

Nous allons gérer des fichiers. Cette page supposera que le terminal se trouve dans le répertoire de travail. Ainsi, les commandes (“cp” par exemple) seront exécutées depuis ce répertoire de travail.

• éditer un fichier :

Nous allons éditer des fichiers de type php, ods, … Selon votre distribution, vous utiliserez vi, vim, gedit ou kedit. Concernant les fichiers ods, nous les éditerons avec Tableur OpenOffice.org.

• divers :

Les commandes commençant par le caractère # sont à exécuter en super utilisateur (sudo). Celles commençant par $ sont à exécuter en tant qu'utilisateur normal.

• le fichier ODS

dynacase permet de gérer des familles de documents (et leurs cycles de vie) et de spécifier quelles zones du documents sont accessibles (en lecture et écriture) aux utilisateurs de DYNACASE. L'import d'un tableur (fichier openoffice en ”.ods”) respectant une certaine structure (que nous allons découvrir dans ce quickstart) permet de paramétrer instantanément :

• des utilisateurs,
• des groupes d'utilisateurs,
• la famille de document,
• le cycle de vie du document,
• les masques et les contrôles de vue du document.

Pour aller plus loin dans … l'import/export de document.

• le fichier méthode

Lors de la description d'une famille dans le tableur, nous serons amenés à indiquer le nom d'un fichier méthode nommé “Method.nom_de_la_famille.php”. Ce fichier permet de surcharger les méthodes par défaut de la class Doc (PostCreated, PostDelete, SpecRefresh, PostModify,..), de créer des attributs calculés, d'ajouter des contraintes sur des attributs et de définir des vues particulières.

• le fichier external

Le fichier External est un fichier contenant des fonctions PHP permettant de définir des aides à la saisie. Les fonctions d'aide à la saisie permettent de compléter ou de remplir des zones de saisie lors de l'édition des documents dynacase. Un fichier External peut contenir plusieurs fonctions d'aides à la saisie. Une famille de documents peut utiliser des fichiers External différents pour chaque aide à la saisie. Un fichier External peut-être utilisé par plusieurs familles.

Pour aller plus loin dans … les fonctionnalités d'une famille.

La page de ce wiki dédiée à l'installation vous guidera en prenant en compte votre distribution.

Sous dynacase, la gestion des informations et des processus documentaires peut être assurée de façon native et simple grâce à l'interface “OneFam”. Celle-ci propose des fonctionnalités de création et recherche de documents, dans le respect des profils de la famille de document et du document lui même), assez complètes pour une application telle que la “demande de congé”. L'étape suivante dans la création d'application consiste à créer l'interface, ajouter des menus, …
Au cours de ce tutoriel, de nombreux liens vous permettrons de consulter la page Créer une nouvelle application Freedom de ce wiki qui explique, en détails, la création d'application. Cette page en est un résumé, appliqué à notre application “demande de congé”.
De plus, d'autres liens vous permettront d'aller plus loin. Enfin, nous vous inviterons à consulter la documentation de l'API dynacase, sur http://www.dynacase.org/freedom-api/. En choisissant “packages : FREEDOM” puis en cliquant sur “index of elements”, nous aurons accès à toutes les fonctions de l'API dynacase.

L'application que nous vous proposons de développer est la demande de congé.
Un salarié, utilisateur dynacase, disposera d'une interface qui lui permettra de rédiger, sauvegarder puis soumettre une demande de congé à son responsable. Celui-ci aura accès à la demande (seulement lorsqu'elle lui aura été soumise). Il pourra alors la traiter et en cas d'acceptation, le service comptabilité / RH aura accès à cette information, pour ensuite la passer en état “consommé”..
Le responsable et le service compta / RH pourront saisir un champ texte réservé qui ne sera pas visible pour le salarié.
Le “nom logique” de l'application sera “DEMANDECONGE”. Le choix de ce nom est important car il sera repris pour nommer de nombreux fichiers.

Une demande de congé est constituée des informations suivantes :

• identification du demandeur (nom, …),
• type de congé (payé, parental, maladie, …),
• dates (début, fin),
• durée (nombre de jours pris).
• des commentaires libres de chacun des intervenants du cycle de demande de congé.

Nous allons créer un document de type tableur (“Demande_de_Conge.ods”) avec openoffice pour ensuite l'importer sous dynacase. Dans un but pédagogique et afin d'éviter toute difficulté due à une simple erreur de saisie, nous allons récupérer demande_de_conge.ods ce fichier.

Le tableur de description commence par une ligne BEGIN et se termine par une ligne END.

Colonne B : vide car cette famille n'hérite pas d'une autre.
Colonne C : titre de la famille.
Colonne F : nom logique de la famille.

'C' signifie famille de document.

Nom de l'icône qui représente la famille.

Le document “demande de congé” sera révisable car le passage de transition dans le cycle de vie de la “demande de congé” créera une transition. Pour aller plus loin dans … la notion de révision.

Un dossier sera créé automatiquement afin de contenir tous les nouveaux documents de la famille.

Le fichier “Method.DemandeConge.php” contient les méthodes de la famille. Nous allons éditer ce fichier php, certes vide au départ, dans un sous répertoire “Class” de notre répertoire de travail.

<?php
//
?>

Copions ce fichier dans le répertoire d'installation de dynacase/FDL/ :

# cp Class/Method.DemandeConge.php /usr/share/what/FDL/

Pour des raisons de rédaction sur dokuwiki :

• les colonnes K et L n'ont pas été affichées,
• l'expression “double slash” (sans espace) représente le début d'une ligne de commentaires,
• nous remplacerons ”!” par “|” dans le détail des attributs de type énumérés (colonne M).

Le document “demande de congé” sera composé trois cadres (frame) : DC_DESC_F, DC_CONGE_F et DC_TRT_F. Pour aller plus loin dans … l'importation de documents.

L'application “demande de congé” sera accessible pour différents groupes d'utilisateurs, qui ont des droits différents :

• le groupe des salariés (ceux qui demanderont des congés),
• le groupe des responsables (ceux qui accorderont ou refuseront les congés demandés),
• le groupe “compta / RH (ceux qui consulteront les congés pris),
• et le groupe “administrateur” (ceux qui définiront les droits de chacun).

Nous allons effectuer le paramétrage de ces groupes (création, affectation d'utilisateurs) par importation d'un tableur.C'est pour cela que le tableur “Demande_de_Conge.ods” contient une 2ème feuille. Les premières lignes décrivent les groupes :

Les lignes suivantes décrivent les utilisateurs :

Ainis, nous pourrons donc paramétrer l'application “demande de congé” pour que :

• Paul, Joe et Eric demandent des congés,
• Jean traite les demandes,
• Céline tiennent compte des congés pris dans le cadre de procédures administratives.

Enregistrons le tableur et conservons le pour la suite. Pour aller plus loin dans … la gestion des utilisateurs.

Pour gérer le processus de demande de congé, nous allons successivement :

1. créer un cycle de vie, avec un profil de type “contrôle dédié”, afin d'en définir les “accessibilités”, c'est à dire qui peut faire passer le document “demande de congé” d'un état vers un autre,
2. créer un profil de famille “demande de congé” (pour indiquer ce que peuvent faire les utilisateurs, sur la demande de congé, en fonction de leur groupe d'appartenance),
3. créer un profil de document pour chaque états successifs,
4. créer un contrôle de vues avec divers masques (édition et consultation selon les droits des utilisateurs) pour chaques états successifs,
5. affecter un profil “contrôle dédié” à chaque contrôle de vue pour indiquer, dans les “accessibilités”, qui a accès à quel masque de ce contrôle.

Le cycle de vie dans dynacase est défini dans une classe de document héritant de WDoc (workflow document). Cette classe décrit les états, les transitions, les conditions de transition ainsi que les pré et post-actions. Pour aller plus loin sur le … cycle de vie.

Le cycle de vie de la demande de congé est le suivant.

Une demande de congé est “enregistrée” par un salarié. Ensuite, lorsqu'il la transmet à son supérieur, elle devient “soumise”. Puis elle est traitée par un responsable pour être soit “refusée”, soit “acceptée”, soit à “reformuler”. Si elle est acceptée, alors elle est transmise au service compta / RH pour ensuite devenir “consommée”.
Pour mettre en place ce cycle de vie, nous allons :

• éditer le fichier "Class.WDocDemandeConge.php" qui en définit le fonctionnement,
• créer la famille de cycle de vie de la demande de congé utilisant ce fichier PHP,
• créer un document cycle de vie basé sur cette famille.
• affecter ce cycle de vie à la famille “demande de congé”,
• pour chaque état, éditer un contrôle de vue, lequel contiendra un ou plusieurs masques avec des accessibilités, selon le profil des utilisateurs.

Nous allons éditer un fichier php, nommé “Class.WDocDemandeConge.php” et que nous placerons dans un sous répertoire ”/Class” de notre répertoire de travail.

<?php
include_once("FDL/Class.WDoc.php");
  
Class WDocDemandeConge extends WDoc {
public $viewlist="button"; 
var $attrPrefix="IWT";
var $firstState="Recorded";

var $transitions = array("Submission"=>array("nr"=>true),
		   "Acceptation"=>array("nr"=>true),
		   "Refusal"=>array("nr"=>true),
		   "TryAgain"=>array("nr"=>true),
                   "Consumation"=>array("nr"=>true));

 var $cycle = array(	array("e1"=>"Recorded",
      	 	      "e2"=>"Submitted",
		      "t"=>"Submission"),
		array("e1"=>"Submitted",
      	 	      "e2"=>"Accepted",
		      "t"=>"Acceptation"),
		array("e1"=>"Submitted",
      	 	      "e2"=>"Refused",
		      "t"=>"Refusal"),
		array("e1"=>"Submitted",
      	 	      "e2"=>"Recorded",
		      "t"=>"TryAgain"),
		array("e1"=>"Accepted",
      	 	      "e2"=>"Consumed",
		      "t"=>"Consumation"));
}
?>

Lors du passage de transition, c'est à dire lorsqu'un utilisateur change l'état d'un document, une pop up s'affiche et propose de saisir un texte justifiant le changement d'état.L'option “nr”⇒true permet de ne pas afficher cette pop up. Dans le chapitre développement, nous utiliserons cette pop up et gèrerons l'envoi d'un e-mail lors d'une transition.
Copions ce fichier dans /usr/share/what/FDL/.

# cp Class/Class.WDocDemandeConge.php /usr/share/what/FDL/

Reprenons le tableur “Demande_de_Conge.ods” et observons la feuille intitulée “cycle” :

Le plus important est de mettre dans la colonne E, la même chose que dans le fichier php.
Consulter la documentation sur les cycles de vie pour aller plus loin.

Nous allons donc importer dans dynacase ce tableur :

# . /etc/freedom.conf //à faire avant la 1ère utilisation de wsh
# wsh --api=freedom_import --file=Demande_de_Conge.ods

• la création de la table “doc1082” par exemple, qui est celle de la famille,
• plusieurs ajouts (Demande de congé, les groupes, les utilisateurs, …),
• la création de la table “doc1093” par exemple, qui est celle du cycle de vie.

# wsh --api=freedom_import --file=Demande_de_Conge.ods 
10/12/2008 16:23:56 LOG::[I] What:DbObj:application  : Default Master [1] - Create table doc1082
10/12/2008 16:23:56 LOG::[I] What:DbObj:application  : Default Master [1] - Ajout Demande de cong� dans dossier import
10/12/2008 16:23:56 LOG::[I] What:DbObj:application  : Default Master [1] - Ajout Salarie dans dossier carnet d'adresses
10/12/2008 16:23:56 LOG::[I] What:DbObj:application  : Default Master [1] - Ajout Salarie dans dossier import
10/12/2008 16:23:56 LOG::[I] What:DbObj:application  : Default Master [1] - Ajout Responsable de DC dans dossier carnet d'adresses
10/12/2008 16:23:57 LOG::[I] What:DbObj:application  : Default Master [1] - Ajout Responsable de DC dans dossier Salarie

10/12/2008 16:23:58 LOG::[I] What:DbObj:application  : Default Master [1] - Ajout Administrateur de DC dans dossier carnet d'adresses
10/12/2008 16:23:58 LOG::[I] What:DbObj:application  : Default Master [1] - Ajout Administrateur de DC dans dossier Responsable de DC
10/12/2008 16:23:59 LOG::[I] What:DbObj:application  : Default Master [1] - Ajout Compta RH dans dossier carnet d'adresses
10/12/2008 16:23:59 LOG::[I] What:DbObj:application  : Default Master [1] - Ajout Compta RH dans dossier Salarie
10/12/2008 16:24:00 LOG::[I] What:DbObj:application  : Default Master [1] - Ajout celine compta dans dossier Utilisateurs
10/12/2008 16:24:00 LOG::[I] What:DbObj:application  : Default Master [1] - Ajout celine compta dans dossier Compta RH
10/12/2008 16:24:00 LOG::[I] What:DbObj:application  : Default Master [1] - Ajout jean responsable dans dossier Utilisateurs
10/12/2008 16:24:00 LOG::[I] What:DbObj:application  : Default Master [1] - Ajout jean responsable dans dossier Responsable de DC
10/12/2008 16:24:01 LOG::[I] What:DbObj:application  : Default Master [1] - Ajout paul salarie dans dossier Utilisateurs
10/12/2008 16:24:01 LOG::[I] What:DbObj:application  : Default Master [1] - Ajout paul salarie dans dossier Salarie
10/12/2008 16:24:02 LOG::[I] What:DbObj:application  : Default Master [1] - Ajout joe salarie dans dossier Utilisateurs
10/12/2008 16:24:02 LOG::[I] What:DbObj:application  : Default Master [1] - Ajout joe salarie dans dossier Salarie
10/12/2008 16:24:02 LOG::[I] What:DbObj:application  : Default Master [1] - Ajout eric salarie dans dossier Utilisateurs
10/12/2008 16:24:03 LOG::[I] What:DbObj:application  : Default Master [1] - Ajout eric salarie dans dossier Salarie
10/12/2008 16:24:03 LOG::[I] What:DbObj:application  : Default Master [1] - Create table doc1093
10/12/2008 16:24:03 LOG::[I] What:DbObj:application  : Default Master [1] - Ajout Cycle de la demande de cong� dans dossier import
# 

Vérification :
Sous dynacase, nous constatons :

• en allant dans le menu “Utilisateurs”, la présence des utilisateurs et des groupes :

et

• dans le menu “gestion documentaire”/“les familles”, la présence des familles “Demande de congé” et “Cycle de la demande de congé”.

La demande de congé nécessite le paramétrage des profils de famille et de document de la famille.

Le profil de famille permet de spécifier qui a le droit, parmi les groupes utilisateurs de dynacase, de créer et voir les documents ainsi que de voir et modifier les droits.
Pour cela, sur l'interface web, allons dans le menu “Gestion documentaire” → “Création” → “Profil”. L'interface nous propose de sélectionner un type de profil. Sélectionnons “profil de famille”. Donnons lui un titre “Profil de famille Demande de congé” et éventuellement une description. Cliquons sur le menu “Créer”.

Le profil de documents permet d'aller plus loin. Pour chaque état du cycle de vie du document “demande de congé”(“recorded”, “submitted”, “accepted”, “refused” et “consumed”), nous allons éditer un “profil de document”. Suivons la même procédure que ci-dessus pour créer un “profil de documents”. Donnons lui un titre “Profil de documents demande de congé … nom de l'état” et sélectionnons la famille “Demande de congé” par le biais de l'aide à la saisie, pour remplir le champ “Famille”. Enfin, cliquons sur le menu “Créer”. Attention, cette opération n'a pas affecté ce nouveau profil de document à la famille. Cela permettra de récupérer certains champs de la famille pour paramétrer le profil par la suite. ici.

Dans l'arborescence de la gestion documentaire, allons voir “les familles” puis sélectionnons la famille “Demande de congé”. Cliquons sur le menu “Sécurité” puis le menu contextuel “Changer le profil du document famille”. Un menu déroulant propose le profil de famille que nous venons de créer, sélectionnons-le puis cliquons sur le bouton “Valider”.
Répétons la même opération en sélectionnant le menu contextuel “Changer le profil pour les nouveaux documents”. Dans la fenêtre qui apparaît, affectons le 1er profil de la “demande de congé” (“recorded” en l'occurrence), que nous venons de créer et validons. Dans l'arborescence de la gestion documentaire, allons voir “les profils”.

• pour le profil de notre famille, cliquons sur le bouton “Activer” puis sur le bouton “Accessibilités”. Une fenêtre proche de celle ci-dessous apparaît, affectons les boules comme indiqué ci-dessous.
  

• pour chacun des profils de document de la famille “demande de congé”, cliquons aussi sur le bouton “Activer” puis sur le bouton “Accessibilités”. Une fenêtre proche de celle ci-dessous apparaît, affectons les “boules” selon les droits que nous voulons donner aux utilisateurs. Un exemple :
  

Nous remarquons la ligne “Demandeur” (de type id ou docid), ceci étant dû au fait qu'on ait indiqué la famille “Demande de congé” lors de la création de ce profil de document.
Désormais, tout nouveau document de demande de congé respectera les conditions définies par ces profils. Les salariés (y compris les responsables et le service compta / RH) pourront créer des “demandes de congé”, voir leur(s) propre(s) demande(s) de congé (et pas celles des autres salariés).

Sur dynacase, allons dans le menu “gestion documentaire”/“les familles”, cliquons sur la famille “Cycle de la demande de congé”. Ensuite, cliquons sur le menu “Créer Cycle de la demande de congé”.
Nommons ce cycle “Cycle de demande de congé” et cliquons sur “Créer”. Nous pouvons visualiser le graphe en cliquant sur le bouton . Cliquons sur le menu “Initialisation”. Une fenêtre pop-up indique que le cycle est initialisé. Désormais, lorsqu'on éditera le cycle, la vue d'édition ressemblera à ceci :
Nous allons donc, pour chaque état du cycle de vie, indiquer les profils de documents successifs (que nous venons de créer) et éditer des contrôles de vue (qui eux-même contiennent des masques).
Astuce : nous allons créer une recherche pour chaque type de document système que nous allons créer, afin de tous les retrouver rapidement. Pour cela, cliquons, dans le menu “gestion documentaire”, sur le menu “Recherche … simple”. Choisissons, tour à tour “Masque de saisie”, “Contrôle de vues” et nomons ces recherches “Masque de saisie”, “Contrôle de vues” et enregistrons les. Elles seront accessibles, toujours dans la gestion documentaire, sous le dossier de l'utilisateur avec lequel vous avez créé cette recherche (surement “Default Master”).

Le cycle de “demande de congé” nécessite la création des masques suivants :

• masque d'édition pour le demandeur au cours de l'état “recorded”,
• masque de consultation pour le demandeur au cours de l'état “recorded” et “submitted”,
• masque d'édition pour le responsable au cours de l'état “submitted”,
• masque de consultation pour le demandeur au cours de l'état “accepted”, “refused” et “consumed”,
• masque de consultation pour le responsable au cours de l'état “accepted” et refused” et consumed,
• masque d'édition pour le service compta / RH au cours de l'état “accepted”,
• masque de consultation pour le demandeur au cours de l'état “consumed”,
• masque de consultation pour le service compta / RH au cours de l'état “consumed”,

Ce qui donne :

Avec :

• “Edit1” = un masque que nous nommerons “Masque recorded demandeur”,
• “Consult2 = un masque que nous nommerons ”“Masque submitted demandeur”,
• “Edit3” = un masque que nous nommerons “Masque submitted responsable”,
• “Consult4” = un masque que nous nommerons “Masque traited responsable”,
• “Edit5” = un masque que nous nommerons “Masque accepted compta RH”,
• “Consult6” = un masque que nous nommerons “Masque consumed compta RH”.

Pour créer un masque, allons dans la “gestion documentaire”, cliquons sur “Création … Documents système” et sélectionnons “Masque de saisie”. Sélectionnons ensuite la famille “Demande de congé”, les attributs de cette famille sont alors listés afin que nous puissions indiquer les paramètres “visibilité” et “obligatoire”.
Il serait lourd d'éditer tour à tour chacun des masques. Dans un but pédagogique, nous vous proposons de récupérer le fichier ods qui décrit ces masques et de l'importer dans dynacase.

Les contrôles de vue sont constitués de masques et respectent des accessibilités, à paramétrer pour chaque état du cycle :

• état “recorded” : seul le demandeur peut voir, éditer et changer d'état le document.
• état “submitted” : le demandeur peut voir sa demande. Le responsable peut voir toutes les demandes de congé, les éditer et les changer d'état.
• état “accepted” : le demandeur peut voir sa demande (mais pas le champ texte “Note du responsable”. Le responsable peut voir toutes les demandes de congé (dont le champ texte “xxx de compta / RH”). Le service compta / RH peut voir toutes les demandes de congé, les éditer (dont un champ texte “xxx de compta / RH”) et les changer d'état.
• état “refused” : le demandeur peut voir sa demande (mais pas le champ texte “Note du responsable”. Le responsable peut voir toutes les demandes de congé.
• état “consumed” : : le demandeur peut voir sa demande (mais pas le champ texte “Note du responsable” ni le champ “xxx compta / RH”). Le responsable et le service compta / RH peuvent voir toutes les demandes de congé.
  

Tout comme pour les masques, l'import du tableur assurera le paramétrage des contrôles de vues.

Voici donc le fichier tant attendu, qui importera directement les masques, les contrôles de vues, les profils, … en accord avec le cycle attendu pour notre application.Enregistrons-le dans notre espace de travail.
Puis importons le avec la commande :

# wsh --api=freedom_import --file=Famille_Demande_de_conge.ods

Ensuite, dans la gestion documentaire, cliquons sur “les cycles”, puis sur le cycle de demande de congé pour avoir accès au menu “Initialisation”. Cliquons sur ce menu et réalisons à nouveau l'import :

# wsh --api=freedom_import --file=Famille_Demande_de_conge.ods

En parcourant dynacase, nous pouvons désormais visualiser les masques, les contrôles de vues, les profils, …
… et nous pouvons utiliser l'application “demande de congé”.

Nous allons ajouter une contrainte sur les dates. La date de fin de demande de congé doit bien évidemment être supérieure à celle de début.
Pour cela, nous allons ajouter l'apper à une fonction pour l'attribut de date de fin. Editons le tableur “Demande_de_conge.ods”, attribut “DC_END” et à la colonne “O”, ajoutons :

::checkDatesConstraint(DC_END,DC_BEGIN)

Ensuite, éditons le fichier “Method.DemandeConge.php” et ajoutons la fonction suivante :

function checkDatesConstraint($enddate,$begindate) {
  $sugg = array();
  $err = "";
  if ($enddate != "") {
    if ( frenchDateToUnixTs($enddate) < frenchDateToUnixTs($begindate) ) {
      $err = "La date de fin est avant la date de debut";
      $sugg[] = strftime("%d/%m/%G",strtotime('+ 1 days',frenchDateToUnixTs($begindate)));
      $sugg[] = strftime("%d/%m/%G",strtotime('+ 2 days',frenchDateToUnixTs($begindate)));
      $sugg[] = strftime("%d/%m/%G",strtotime('+ 3 days',frenchDateToUnixTs($begindate)));
      $sugg[] = strftime("%d/%m/%G",strtotime('+ 4 days',frenchDateToUnixTs($begindate)));
      $sugg[] = strftime("%d/%m/%G",strtotime('+ 5 days',frenchDateToUnixTs($begindate)));
      $sugg[] = strftime("%d/%m/%G",strtotime('+ 6 days',frenchDateToUnixTs($begindate)));
    }
    return array("err" => $err,
          "sug" => $sugg
          );
  }
}

Ensuite, importons de nouveau le tableur, copions le fichier méthode et regénérons la classe documentaire :

# wsh --api=freedom_import --file=Demande_de_Conge.ods
# cp Class/Method.DemandeConge.php /usr/share/what/FDL/
# wsh --api=fdl_adoc

A cette dernière commande, le terminal liste toutes les classes documentaires. A l'avenir, nous pouvons limiter la regénération en complétant la commande avec le docid. Exemple :

# wsh --api=fdl_adoc --docid=1082

Nous pouvons désormais tester la contrainte.

dynacase permet de paramétrer une application avec des fonctionnalités très avancées (contrôle de vue, workflow, …). L'exemple que nous avons suivi au cours des chapitres précédents est là pour l'illustrer. Cependant, nous pourrions être en attente de fonctionnalités plus complexes, exemple :

• maintenance, déploiement, migration des évolutions des applications, … grâce à la création de packages
• des actions spécifiques avec un affichage particulier,
• … to be completed …

Le répertoire “DEMANDECONGE” doit contenir les répertoires suivants :

• Class, (qui contiendra les fichiers “Method.xxx.php” et “Class.yyy.php”)
• Images,
• External,
• Action,

et les fichiers suivants :

• “Demande_de_conge.ods”,
• “configure.in”
• “makefile.in”
• “dynacase-DemandeConge.spec.in”
• “pubrule”.

Créons-nous, si ce n'est déjà fait, un répertoire de travail, ainsi que les sous répertoires.

$ mkdir DemandeConge
$ cd DemandeConge
$ mkdir Class
$ mkdir Images
$ mkdir External
$ mkdir Action

Le fichier “configure.in” permet de générer, par le biais de la commande “autoconf”, le fichier configure. Celui-ci, lorsqu'on le lance, génère des fichiers à partir de fichiers modèles d'extension .in. Ainsi, ce script transforme les fichiers Makefile.in en fichiers Makefile.
Dans le “configure.in”, nous allons :

• indiquer le nom du package (dynacase-DemandeConge) :

PACKAGE=dynacase-DEMANDECONGE

• spécifier le nom de l'application :

APPNAME=DEMANDECONGE

• localiser le Pubrule :

PUBRULEDIR=`pwd`

• et paramétrer la macro AC_OUTPUT qui indique le ou les fichiers Makefile à générer et qui génère le fichier “config.status”.

AC_OUTPUT(Makefile dynacase-DemandeConge.spec DemandeConge_init.php)

Nous allons indiquer, dans le fichier “makefile.in” de notre répertoire de travail, la liste des sous répertoires :

SUBDIR = Class Images Zone

ainsi que le nom du tableur si nous souhaitons traduire en différentes langues, les textes affichés :

TRANSODS = Demande_de_Conge.ods

L'exécution de la commande

$ ./configure --with-pubrule=`pwd` --with-httpuser=www-data --with-apacheconfdir=/etc/apache2/sites-enabled/ --prefix=/usr/share/what/

génèrera les fichiers “makefile” à partir des divers fichiers ”.in”, dont les “makefile.in”. Chacun des sous répertoires de travail (listés dans SUBDIR = …) devront contenir eux aussi un “makefile”.
Le contenu du makefile du répertoire Class est :

include $(utildir)/PubRule

pages_fdl = $(patsubst %.php,$(pubdir)/$(applib)/%.php,$(wildcard Method*.php))
pages_fdl += $(patsubst %.php,$(pubdir)/$(applib)/%.php,$(wildcard Class*.php))

$(pubdir)/$(applib):
	mkdir $@

$(pubdir)/$(applib)/%.php: %.php $(pubdir)/$(applib)
	cd $(pubdir)/$(applib); \
	ln -sf ../$(appname)/$< .

publish: $(pubdir)/$(applib) $(pages_fdl)

Le contenu des makefile des répertoires Images et Zone est :

include $(utildir)/PubRule

Le contenu du makefile du répertoire External est :

include $(utildir)/PubRule

pages_fdl = $(patsubst %.php,$(pubdir)/$(applib)/%.php,$(wildcard *.php))

$(pubdir)/EXTERNALS :
	mkdir -p $@

$(pubdir)/$(applib)/%.php: %.php $(pubdir)/EXTERNALS
	cd $(pubdir)/$(style)/EXTERNALS; \
	ln -sf ../$(appname)/$< .

publish: $(pubdir)/EXTERNALS $(pages_fdl) 

# make publish

enverra, sur le serveur (dans le répertoire spécifié auparavant par l'option ”–prefix” de la commande ”./configure”), tous les fichiers nécessaires au fonctionnement de notre application.

Ce fichier génèrera le fichier “dynacase-DemandeConge.spec” qui sera utile pour générer les paquets RPM. Modifiez les lignes suivantes :

...
Summary: Application DEMANDECONGE
...
Application DEMANDECONGE
...
%dir %{destdir}/DEMANDECONGE
%{destdir}/DEMANDECONGE/*
...

Le fichier pupbrule décrit les règles de publication des fichiers. Nous allons l'enregistrer dans notre répertoire de travail.

L'application “demande de congé” nous amènera à éditer les fichiers :

• “DemandeConge.app”,
• “DemandeConge_init.php.in” et
• “DemandeConge_post”.
  

Afin de paramétrer à la fois, la famille, les utilisateurs, les groupes d'utilisateurs et les profils, nous travaillerons sur un tableur sous openoffice, pour lequel il n'y a aucune exigeance sur le nom : “Demande_de_Conge.ods”. Enfin, nous éditerons aussi les fichiers suivants : “RELEASE”, “VERSION” et “pubrule”.

Ce fichier PHP décrit l'application (présentation, ses actions et les acl). Nous allons donc ouvrir un éditeur de fichier (geany par exemple), rédiger les lignes suivantes et sauvegarder le fichier avec le nom “DemandeConge.app”.

<?php
$app_desc = array (
	"name"          =>"DEMANDECONGE",             
	"short_name"    =>"Application de demande de conge",            
	"description"   =>_("Pour assurer les traitements des demandes de conge"),      
	"access_free"   =>"Y",                    
	"displayable"   =>"Y",                    
	"with_frame"    =>"Y",                   
	"childof"       =>"ONEFAM"                      
);
?>

Cliquez ici pour obtenir une description plus détaillée des paramètres de ce fichier et ici pour “aller plus loin” dans la traduction.

Ce fichier PHP contient les variables déclarées par l'application (globales, applicatives, utilisateurs). Il contient au moins la version de l'application.
@VERSION@-@RELEASE@ seront remplacés par la valeur de la version (contenue dans le fichier "VERSION") et de la release (contenue dans le fichier "RELEASE") de l'application lorsque vous exécuterez la commande "configure".

<?php
global $app_const;

$app_const= array(
      "INIT" => "yes",
      "VERSION" => "@VERSION@-@RELEASE@",
      "ONEFAM_FAMOPEN" => "DEMANDECONGE",
      "ONEFAM_MIDS" => "DEMANDECONGE"
          );
?>

Cliquez ici pour obtenir une description plus détaillée des paramètres de ce fichier. Sachez tout de même que :

• le paramètre ONEFAM_FAMOPEN permet de définir la famille affichée par défaut lorsqu'on se connecte à l'application,
• le paramètre ONEFAM_MIDS permet de définir la liste des familles affichées dans l'application (ex : ⇒ “FAM_1,FAM_2,FAM_3”).

Ce fichier s'exécute lors de l'installation (I), de la mise à jour (U) ou de la suppression de l'application (D).

#!/bin/bash
if [ "$dbpsql" == "" ]; then
    #load environement variable for freedom
  . /etc/freedom.conf
   wchoose -b
fi

#------------------------------
#post installation
#------------------------------
if [ "$1" = "I" ] ; then
  $wpub/wsh.php --api=freedom_import --file=$wpub/DemandeConge/Demande_de_Conge.ods
  $wpub/wsh.php --api=set_param --param=WDK_DEFAPP --appname=WEBDESK --value=DEMANDECONGE
fi
#------------------------------
#post update
#------------------------------
if [ "$1" = "U" ] ; then
  $wpub/wsh.php --api=freedom_import --file=$wpub/DemandeConge/Demande_de_Conge.ods
fi
#------------------------------
#post uninstallation
#------------------------------
if [ "$1" = "D" ] ; then
  echo
fi

Cliquez ici pour obtenir une description plus détaillée des paramètres de ce fichier. Sachez cependant que le paramètre WDK_DEFAPP indique que l'application au démarrage de dynacase est DEMANDECONGE.

Rien de plus simple, ce fichier ne contient qu'une ligne.

1.0.0

Encore plus simple, ce fichier ne contient qu'un caractère

1

Les textes affichables (notamment les caractères accentués en français) peuvent être traduits en diverses langues. Pour cela, dynacase utilise le système le plus répandu dans le monde des logiciels libres à savoir Gettext.
La marche à suivre, pour rendre accessible dynacase en français et anglais, est :

• récupérons le fichier fam2po.php et enregistrons-le dans notre répertoire de travail,
• dans nos fichiers php, remplaçons “texte a traduire” par _(“texte a traduire”),
• dans nos fichiers app, remplaçons “texte a traduire” par N_(“texte a traduire”), (“N_” est une fonction dynacase qui traduit le texte qui sera stocké en base de données)
• dans nos fichiers de description des classes “cycle de vie” (Class.xxx.php), rajoutons quelques lignes au début du fichier

define ("i18n","i18n"); # N_("chaine_a_traduire") N_("autre_chaine_a_traduire") 

• dans nos fichiers xml, remplaçons “texte a traduire” par [TEXT:dc_cle_du_texte_a_traduire],
• lançons la commande

  # make po

  qui enverra les clés non traduites dans chacun des fichiers ”.po” (! ne marche pas s'il n'y a pas de fichier xml). La commande “po” est définie dans le pubrule, qui est inclu dans le makefile. Il faut donc avoir au moins une fois construit le makefile par la commande ”./configure”.

• traduisons ensuite nos nouvelles entrées (clés) dans chacun des fichiers (avec le logiciel emacs par exemple).
• publions nos fichiers sur le serveur,

  # make publish

• lançons la commande

  # wtext

  sur le serveur (veillons à avoir auparavant lancé la commande ”. /etc/freedom.conf”).
  

Il est conseillé de composer la clé avec les initiales du nom de la famille puis “_” pour éviter les clés doubles (ici “DEMANDECONGE” ⇒ “dc”).
Aussi, depuis la version 2.11, on peut traduire le texte issu des tableurs (libellés d'attribut, titre de la famille, énuméré, elabel, …). Pour cela, on rajoute

TRANSODS = Demande_de_Conge.ods

dans le fichier “makefile.in” après la ligne

include $(utildir)/PubRule

Pour aller plus loin dans … la traduction.

Lors des transitions, nous disposons de méthodes :

• de pré condition (“m1”)
• d'action (“m2”).

Les méthodes “m1” vérifient les conditions de passage de transition. Pour outre passer des droits, nous utiliserons les fonctions disableEditControl() et enableEditControl().
Les méthodes “m2” ne seront exécutées que si les pré conditions ainsi que celles du profil utilisateur sont vérifiées.

Chacun des intervenants dispose d'un champ libre pour ajouter un commentaire. Pour cela, il doit éditer le document de demande de congé. Nous allons proposer cette édition lors du passage de transition. L'exemple portera sur le refus. Pour cela, nous allons modifier le fichier “Class.WDocDemandeConge.php” au niveau de la description des transitions :

var $transitions = array("Submission"=>array("nr"=>true),
                         "Acceptation"=>array("nr"=>true),
                         "Refusal"=>array("m1"=>"notifyReject",
                                          "m2"=>"RmailToDemandeur",
                                          "nr"=>true,
                                          "ask"=>array("wad_refus")
                                          ),
                         "TryAgain"=>array("nr"=>true),
                         "Consumation"=>array("nr"=>true));

Lors du changement d'état du document vers l'état “Refused”, le responsable devra indiquer une raison. Ceci est dû au paramètre ask. La valeur choisie sera récupérée en tant que paramètre du cycle, ce qui explique les lignes suivantes dans le tableur “Demande_de_Conge.ods” :

Avec détail des énumérés = “sci|Solde de conge insuffisant,pi|projet trop important prevu sur cette periode,dtl|duree trop longue,ti|type de conge incorrect”

Nous allons aussi ajouter la fonction notifyReject :

  function notifyReject() {
    $reason=$this->getValue("wad_refus");

    $this->doc->disableEditControl(); // no control here
    $this->doc->setValue("dc_comment_r2d",$reason);
    $this->doc->modify();;
    $this->doc->enableEditControl();
  }

Lorsqu'une demande de congé d'un salarié rencontre le refus du responsable, le salarié demandeur recevra un e-mail contenant les raisons de ce refus. Pour cela, nous allons :

• Dans “Administration” > “Gestion des applications” → “Paramètres applicatifs” → “bibliothèque dynacase” → “nom du serveur SMTP” ⇒ indiquons le nom de notre serveur smtp (ex : “smtp.orange.fr”),
• créons un layout,
• éditons le fichier “Class.WDocAlerte.php” et y ajouter une fonction sur l'action m2 de la transition “Refusal”.

Le layout : Editons, dans le répertoire “Zone”, un fichier xml nommé “dc_mail_refusal.xml”,dont le code est le suivant :

<html>
<h1>[TEXT:DC_Bonjour] [V_DC_NAME_ID]</h1>
<h1>Votre demande de [TEXT:DC_conge] [TEXT:DC_a_ete_refuse], avec le commentaire suivant :</h1>
<h1>[V_DC_COMMENT_R2D]</h1>
<h1>[TEXT:DC_Signe] : [sender]</h1>
</html>

Le fichier “Class” :

<?php
include_once("FDL/Class.WDoc.php");

Class WDocDemandeConge extends WDoc {
//...
function RmailToDemandeur() {
  include_once("FDL/mailcard.php");

  $to = $this->doc->getDocValue(($this->doc->getValue("dc_name_id")),"us_mail") ;
  $subject = N_("Refus de conge !");
  if (($subject !="") && ($to!="")) {
    $err=sendCard($action, $this->doc->id, $to, $cc, $subject,"DEMANDECONGE:DC_MAIL_REFUSAL");
    if ($err) addWarningMsg($err);
  }
  return;
}
}
?>

Toute référence à une zone (ici : la fonction sendCard) doit être faite en indiquant :

• en majuscules le nom de l'application (“DEMANDECONGE”),
• puis ”:”,
• puis le nom du fichier xml sans l'extension (“DC_MAIL_REFUSAL”).

Pour aller plus loin avec la fonction sendCard, consultons l'API. Remarque : lorsqu'on invite un autre utilisateur à consulter un fichier, en lui fournissant le lien, pensons à utiliser l'option “latestid” pour que l'utilisateur accède à la dernière révision du document.

• ajoutons une image (de préférence : au format png, de dimension 48*48, avec fond transparent) dans le répertoire “Images”,
• éditons le makefile.in de l'application et ajoutons le répertoire “Images” à la ligne “SUBDIR = …”,
• éditons le fichier “DEMANDECONGE.app” et ajoutons :

  $app_desc = array (
  ...            
  	"icon"          =>"conge.png",                    
  ...
  );
  

• exécutons la commande ./configure en tant qu'utilisateur local (pas en sudo!),

$ ./configure --with-pubrule=`pwd` --with-httpuser=www-data   --with-apacheconfdir=/etc/apache2/sites-available   --prefix=/usr/share/what/

• exécutons la commande make publish,

# make publish

• exécutons la commande wstart, sur le serveur :

# /usr/share/what/wstart

Les paramètres de transition Pour aller plus loin