FM = family maker

Cette interface se décompose en plusieurs parties qui peuvent être utilisées séparément.

FM permet la création d'un famille peut être réalisé à partir de : - rien - d'un héritage : la famille crée hérite de la famille mère; - d'une copie : la famille mère est simplement utilisée comme copie; par la suite les 2 familles (modèle et créée) sont indépendantes.

FM permet d'initialiser et gérer les éléments de définition de la famille :

• icone
• titre de la famille (multi-langue)
• choix des langues supportées
• révision : sans, manuel, automatique
• balises (tags applicatifs) : utilisées pour repérer certains sous-ensembles de familles
• domaine de la famille : sans, système, autres… “autre” permettant de définir son propre domaine). Les domaines permettent de classifier les familles (exemple : famille du domaine commercial pour une application de CRM, famille système non présentée aux utilisateurs).
• nom logique
• activation forum

FM permet de définir et gérer les paramètres de la famille. Un paramètre est constitué d'un identifiant, d'un libellé et d'une description localisée ainsi que d'un type et d'une liste optionnelle de valeur possibles. Ce paramètre peut être déclaré comme une préférence utilisateur.

L'interface permet déclarer les méthodes (ajout et surcharges) des familles. Les codes PHP fournis sont validés d'un point de vue syntaxique et les erreurs signalées à l'utilisateur.

FM permet de créer, modifier, supprimer des attributs. Ils sont représentés sous forme d'un arbre montrant la structure. Les feuilles étant des attributs non structurants (qui peuvent avoir une valeur), les noeuds les attributs structurants (tab, frame par exemple).

Lorsque l'utilisateur veut modifier un attribut il clique sur celui-ci, une interface présente alors l'ensemble des paramètres possibles. Suivant le type d'attribut les options de paramétrage changent directement.

Les libellés d'attributs étant soumis à la langue ainsi que certaines options, l'interface proposera de saisir les différentes traductions. Les langues supportés sont définies dans la partie configuration (“settings”).

Pour les attributs calculés, un éditeur PHP permet de fournir le code s'il n'existe pas déjà.

En cas de famille dérivée, l'arborescence mère est représentée au sein de la structure avec une mise en évidence particulière. Si l'administrateur clique sur un attribut père, celui peut être modifié (passage en MODATTR) : les attributs hérités modifiés sont mis en évidence.

La valeur par défaut est indiqué lors de définition de l'attribut

L'ordre des attributs suit l'ordre donnée par l'arborescence, un attribut peut être déplacé par un glissé/déposé dans l'arbre.

Lors de la sélection d'un attribut, un bouton permet de supprimer l'attribut. Le changement de type est possible (le noyau évoluera pour supporter cette possibilité).

La présentation des paramètres est identique à celle des attributs. Ce sont les attributs qui servent aux paramétrages de la famille

FM permet de définir des représentations particulières. Les vues sont classées selon les catégories Edition et Consultation.

Il est possible d'ajouter, de modifier des spécifications de vue ou supprimer des vues.

les vues par défaut sont sélectionnables et mises en évidence. Les éléments de spécifcation des vues sont :

• identifiant
• libellé
• modèle
• masque
• style
• ordre d'application
• affichable (case à cocher)
• affichage conditionnel : choix d'une méthode qui indique la visibilité (avec éditeur PHP si nouvelle méthode) ou s'il y a un cycle choix des états où la vue est disponible
• création (case à cocher - radio) pour partie édition seulement
• défaut (case à cocher -radio)

FM propose pour chaque vue les zones

• modèle : html / exts / odt / pdf / texte
• masque
• style
• prévisualisation

Les informations de ces zones sont facultatives.

La choix d'un modèle existant et sa modification impacte les autres vues l'utilisant. Il est possible de dupliquer une modèle.

modèle html L'interface de présentation propose de télécharger un fichier ou permet l'édition en ligne du modèle via un éditeur HTML. Cet éditeur permet d'insérer les attributs sous leur forme ”[V_MY_ATTR]”. L'éditeur permet aussi d'insérer des images que peut télécharger. Les images se retrouve dans le répertoire “media” . Il peut aussi récupérer une image provenant de ce répertoire.

modèle extjs L'interface de présentation propose de télécharger un fichier ou ouvre un éditeur JS. Un champ permet d'indiquer le nom du widget à utiliser. Un champs importer une image permet d'ajouter des images dans le répertoire “media” de la famille.

modèle odt L'interface propose un accès au fichier ODT modèle. Ce fichier peut être modifié par DAV (si configuré) ou modifier de manière classique par téléchargement.

modèle texte L'interface de présentation propose de télécharger un fichier ou offre un éditeur texte (fonctionnement identique à l'éditeur HTML). Un champ indiquant le type mime et l'extension peut être renseigné. Ceci permet par exemple de construire des csv ou des xml.

code du modèle Pour chacun des type de modèle une méthode de document peu y être associée. L'utilisateur peut choisir une méthode existante (liste proposée), importer un fichier contenant le code de la méthode ou créer une nouvelle méthode vai l'éditeur PHP intégré. Il a alors accès à l'objet $this et $this→lay pour utiliser des clefs supplémentaires.

Style L'interface des styles présente l'arborescence des attributs comme pour la structure mais elle n'est pas modifiable. Elle sert juste à la sélection. Lorsqu'un utilisateur clique sur un attribut les options de styles lui sont présentés suivant le type d'attribut. Ces styles impactent la mise en forme exemple 'display-label' ou 'color'. Sur chacun des styles possibles des noms compréhensibles sont affichés et des liste à choix sont affichés si le nombre de choix est limité. Certaine options de présentations ne sont pas supportés suivant le type de modèle. Seule les options valides sont présentés. Les modèles odt et texte ne supportent aucun paramètre de style.

Masques L'interface des masques présente l'arborescence des attributs et pour chacun d'un sa visibilité. Les visibilités d'attributs modifiées sont mises en évidences, les attributs modifiés par propagation sont aussi mis en évidences (mais différemment). Par exemple si on met un cadre en lecture ses attributs sont au minimum en lecture. Pour modifier une visibilité ou une obligation on clique sur la visibilité de l'attribut alors une liste de choix apparait et on choisi la nouvelle visibilité. Le masque est ré-affiché pour prendre en compte les conséquences. Il en est de même pour l'obligation.

Menu L'interface présente la liste des menus sous forme d'arborescence (menus/sous-menus). L'interface permet d'ajouter, modifier et supprimer des menus. Les spécifications d'un menu sont :

• identifiant
• libellé (multi-lingue)
• icone
• identifiant menu père (liste proposé)
• type : item ou sous-menu
• visibilité : statique (visible, invisible, inactif) ou dynamique. La visibilité dynamique est calculée par une méthode PHP. Cette méthode est choisie parmis celles existantes, peut être importée via un fichier ou écrite via l'éditeur PHP.
• confirmation : boite à cocher. Si coché, l'utilisateur doit rentrer la question (multi-lingue) de la confirmation
• affichage : barre de menu / menu contextuel / les deux (par défaut)
• url : url à activer lors du clic
• js : fonction javascript à activer lors du clic
• target : endroit (en terme d'interface) ou doit être affiché le résultat ('_self indiquant “sur place”)

L'ensemble des méthodes surchargeables sont présentés (specRefresh, postCreated, …). Celle qui sont déjà surchargés sont mises en évidence. Pour surcharger une méthode il suffit de cliquer dessus. Un éditeur PHP est proposé. La liste des autres méthodes est aussi affichée et cela permet d'accéder au code de chacune de ces méthodes. Pour chacune des méthodes un ensemble de caractérisques sont positionnable :

• api : permet d'indiquer si cette méthode peut être appelé depuis l'API client. Si ce champ est activé, un droit doit être spécifié pour autorisé l'accès (par défaut c'est le droit 'voir').
• externe : précise si la méthode est utilisable hors du code de la classe
• finale : précise si la méthode peut être ou non surchargée par des familles dérivées

La création d'un méthode est faite par import d'un fichier PHP ou édition via l'éditeur PHP.

L'import d'un fichier comportant plusieurs méthodes (actuel fichiers Method…..php) crée ou surcharge autant de méthodes que nécessaire.

FM permet une édition globale du code des méthodes au travers de l'éditeur PHP.

La modification de méthode entraine une passe de contrôles sur le code.

Les formulaires permettent de proposer des interfaces de saisie d'information. L'objectif de ces interfaces est de guider et d'assister l'utilisateur lors des saisies. La conception du formulaire est assisté par un outil graphique. ou plusieurs documents freedom.

Un formulaire peut être composée de plusieurs étapes.

L'ordre de ces étapes est établi lors de la conception du formulaire.

Un élément visuel permet à l'utilisateur de connaitre les étapes du processus de saisie, les étapes réalisées et l'étape en cours.

Selon les choix de conception du formulaire, le changement d'étape se fait linéairement (pas à pas : passage à l'étape suivante ou précédente seulement), ou alors de manière libre : l'utilisateur sélectionne l'étape à laquelle il peut accéder. Ce mode de fonctionnement peut être mixte : le processus de saisie est initialement linéaire (pas à pas) puis il est possible d'accéder directement aux étapes déjà complétées. L'étape suivante à celle dont la saisie est terminée peut dépendre des informations fournies. Les zones de saisies proposées à une étape peuvent aussi dépendre des informations données aux précédentes étapes.

A chaque changement d'étape les informations saisies sont stockées. Lors de l'accès à une étape les informations précédemment saisies sont renseignées.

A chacune des étapes, l'écran propose des zones de saisie qui peuvent être obligatoires ou optionnelles. Les zones obligatoires sont mises en évidence et lors du changement d'étape leur saisie est contrôlée. De même lors du changement d'étape, les valeurs saisies sont contrôlés en fonction des attentes spécifiée par le concepteur du formulaire.

Une aide spécifique peut être proposée au regard de chacune des zones de saisie. Plus globalement, une aide concernant l'étape entière peut être mise à disposition de l'utilisateur.

Une interface WEB matérialise le formulaire sous forme de page : chacune des pages représente un étape.

En mode déconnectée (pas de connexion au serveur freedom), les formulaires sont disponibles pour l'utilisateur qui peut les pré-renseigner. Lorsque le serveur est joignable, l'utilisateur peut demander le stockage des informations. Dans ce mode, il est évident que les zones de saisies faisant appel dynamiquement au serveur ne sont pas accessibles. Les formulaires gérés sont ceux possédant une seule étape.

L'utilisateur demande la génération d'un formulaire Offline. Un document OpenOffice est produit. Il peut être complété offline. Il est ensuite importé dans freedom, qui récupère les informations saisies.

Une interface d'administration des formulaires est disponible. Un droit permet d'y accéder.

Une interface permet de décrire chacune des étapes : - ordonner les zones de saisie - préciser :

• le libellé des zones
• l'aide relative à la zone
• optionnelle | obligatoire
• modifiable ou non
• type : chaine, entier, date, etc… et l'expression de contrôle (pattern pour une chaine,
• 

L'interface permet de préciser l'enchaînement des étapes.

Le formulaire permet de :

• stocker les informations caractérisant le formulaire : mapping sur le document;
• paramétrer les vues et structures en fonction des étapes
• des données propres au seul formulaire : exemple boolean d'aiguillage dans la suite de la saisie;
• éventuellement le code permettant de gérer des mappages formulaire / document complexe (conditionnel, calcul, etc…)

Le formulaire est un document système (non accessible aux utilisateurs).

Pour le mode offline, freedom sait importé un formulaire OpenOffice ou XForm contenant l'ensemble des saisies pour la formulaire dans sa globalité (toutes étapes).

FM permet d'utiliser un cycles compatibles (associé à la famille) ou de créer un nouveau cycle. Le graphe du cycle est présenté (avec en création un seul état initial). Les états et transitions peuvent être ajoutés, modifiés ou supprimés : Etats :

• identificateur
• libellé (multi-lingue)
• activité (multi-lingue)
• couleur
• masque (choix d'un masque existant et possibilité de créer un nouveau)
• modèles de courriel (choix d'un modèle existant et possibilité de créer un nouveau)
• minuteur (choix d'un modèle existant et possibilité de créer un nouveau)
• accord (choix d'un accord existant et possibilité de créer un nouveau)
• utilisateur affecté responsable (choix fixe ou dynamique suivant les attributs - comme maintenant)
• utilisateurs /groupes affectés (plusieurs - évolution noyau)
• notification auto pour les affectés
• verrouillage affecté responsable
• …

Les interfaces pour les courriels, minuteurs,accords et masque sont affichées lors de leur modification.

Transitions

• type de transition
• courriels
• minuteurs : pré-traitement, condition, post-traitement. Ces méthodes sont écrites à l'aide de l'éditeur PHP.
• …

La construction du graphe est réalisée en spécifiant l'état de départ, celui d'arrivée et la transition. La relation peut être supprimée. Le graphe est actualisée dynamiquement lors des modifications d'états, de transitions ou de relations.

Trois onglets “Famille”, “Document”, “Cycles” permettent de spécifier les accès. Une interface de modification de droit est utilisée dans chacun des onglets. Cette interface affiche l'arborescence des groupes (dépliable construite au fur et à mesure). Si l'utilisateur déplie un groupe il peut voir aussi les utilisateurs finaux. S'il y a beaucoup d'utilisateurs dans un groupe (exemple 7000) il n'est pas possible d'afficher cette liste. Pour combler ce problème, il est possible de filtrer les groupes ou les personnes. Pour cela l'utilisateur à un champ texte qui permet de filtrer sur les nom, prénom, email et login d'un groupe ou d'un utilisateur. Le filtre “droit déjà coché” permet aussi de filtrer et de ne présenter que les groupes et utilisateurs qui ont un droit (hors droits hérités). Les droits sont présentés (comme actuellement) à l'aide de puces vertes, grise ou rouge.

Pour modifier, un droit l'utilisateur clique sur le groupe/utilisateur, il peut alors pour chacun des droits activer ou désactiver ce droit. Un bouton “Mettre à jour les droits” permet d'acquitter l'ensemble des changements. Un bouton “droit dynamique” permet d'accéder à la partie dynamique. S'il clique dessus, sous la liste des groupes est affiché la liste des attributs représentant les groupes ou utilisateur. Si aucune case dans la partie dynamique n'est coché, le profil sera considéré non dynamique. Pour être réutilisé, un champ titre et un champ description sont présents dans l'entête.

L'utilisateur peut choisir un profil de famille existant (liste proposée) ou cliquer sur “nouveau profil”. S'il clique sur nouveau profil l'interface des droits s'affiche avec les droits suivants :

• voir
• structure
• configuration
• paramètres
• vues
• comportement
• menu
• cycle
• sécurité
• supprimer (la famille)
• modifier les droits
• voir les droits

Ces droits contrôlent l'accès aux interfaces du maker. Cette interface n'a pas le bouton “droit dynamique”.

Un bouton “ajouter un droit” permet d'ajouter un droit spécifique à la famille. Ce droit pourra être utilisé dans le code spécifique à cette famille ou pour donner accès aux méthodes pour l'api. L'interface d'ajout de droits comprend les champs : identificateur du droit, libellé (multi-lingue) du droit

L'utilisateur peut choisir un profil de document existant (liste proposée) ou cliquer sur “nouveau profil”. S'il clique sur nouveau profil l'interface des droits s'affiche avec les droits classiques du document. S'il choisi un profil existant l'interface de droit pour ce profil est affiché. Il peut aussi cliquer sur le bouton “pas de profil” pour donner un accès libre; dans ce cas l'interface de droit est remplacé par un texte indiquant que tous le monde à accès. En plus est affiché le droit “créer”. Ce droit bien que techniquement n'appartenant pas au droit du document est intellectuellement lié au profil de document. S'il coche créé, l'utilisateur voir apparaitre un petit bouton à côté permettant d'indiquer “interdire la création directe par l'interface”.

L'interface présente un onglet par état et un onglet “transitions”. Lorsque l'utilisateur sélectionne un onglet “état”, la même interface que pour les droits par défaut est affiché mais sans le droit “créer”. Dans l'onglet transition, l'interface de droit est affiché (pas de possibilité de lier à un profil de transition). Le bouton “pas de profil” est quand même affiché. La liste des droits est liée aux types de transitions.

L'interface de droit est affiché, un droit par vue.

Cette interface permet de créer des documents qui seront utilisés pour le bon fonctionnement de la famille. Cela peut être des groupes d'utilisateurs, des modèle de courriel, des documents de références, etc. Cette interface présente l'ensemble des données initiales dans un tableaux triable. Les colonnes présentées sont la famille, le titre, la référence logique (name). Le nom logique et le titre peuvent être modifié directement dans le tableau.

L'interface est composé en deux parties : la partie tableau une partie à onglet avec un onglet par document (ne s'affiche que si l'utilisateur clique sur un document du tableau). Pour ajouter un nouveau document il clique “ajouter un document”, la liste des famille est alors proposée et il saisi ensuite son document dans l'onglet “nouveau truc” (truc est le nom de la famille choisie). Lorsqu'il a appuyé sur “créer” il est ajouté au tableau.